补充点，排序最好不要用order by created_at desc,改用自增主键排序order by id desc,效果一样，性能差多

单表千万级数据，是需要开始考虑分表的问题了！

就目前形式快速解决提供我的几个思路：

• 所有表关联用到 join 的地方不要用 join （我们都知道多张表使用join是做笛卡尔积的，想象下多恐怖）所以不要用join，换成单表查
• 用到其他表的数据取范围查询所需字段对应的值（如分页50/页，该50条数据的某个ID和其他表的值做表驱动查询）
• 注意索引，是否有不合适的索引和一些必要索引的建立（利用expain查看性能分析）
• 数据归档，历史数据（比如将2016年前的数据独立出去）的拆分
• 分页需要考虑总数不要查sql，写个固定的常量值（根据你业务场景）
• 其他的有些人都回答了可以参考思路

千万级数据 30多秒查询

提供一下几个观点：

• 硬件层优化：SSD

• 数据层优化：

  • 分表：可以考虑以某个关键值为 hash 进行分表，来降低单个表的数据量；
  • 索引：join 关联的条件，所建索引是否合适；
  • SQL 优化：现有的 SQL 是否存在优化空间？是否能用到索引的，没有用索引？是否只查必要的字段值？
  • 字段冗余：因为某个字段而引起的大表联结，可以考虑新增字段，适当冗余；
  • 读写分离；
  • 是否可以将联表的 SQL 在业务层优化为多条 SELECT

• 结构层优化：

  • 是否可以将查询的数据做缓存，比如以 SQL hash 结果为 key，以查询结果为 value，存入 redis

有模糊搜索吧？
sphinx
阿里云的话走开放搜索

1. 把常用的查询字段做成多字段索引
2. 只查询需要的列
3. 查询的时候把限制范围最长的字段放在最前面

我也面临过这种环境，会员优惠券单表达到快千万级，像like之类的业务，速度慢就不用说了。常用字段添加索引的方式，起到很大作用；并发使用的业务，最好能够减少对数据表的频繁使用。最好能根据业务分离一下数据。当然，服务器配置的强大，是根本。

1.读写分离2.建立相关的索引字段3.常用列表页和搜索项建立缓存机制