slow sql/long query
影响执行效率的主要因素
- 数据量
SQL 执行后返回给客户端的数据量的大小；
数据量越大需要扫描的 I/O 次数越多，数据库服务器的 IO 更容易成为瓶颈。
- 取数据的方式
数据在缓存中还是在磁盘上；
是否能够通过全局索引快速寻址；
是否结合谓词条件命中全局索引加速扫描。
- 数据加工的方式
排序、子查询、聚合、关联等，一般需要先把数据取到临时表中，再对数据进行加工；
对于数据量比较多的计算，会消耗大量计算节点的 CPU 资源，让数据加工变得更加缓慢；
是否选择了合适的 join 方式
优化思路
- 减少数据扫描（减少磁盘访问）
尽量在查询中加入一些可以提前过滤数据的谓词条件，比如按照时间过滤数据等，可以减少数据的扫描量，对查询更友好；
在扫描大表数据时是否可以命中索引，减少回表代价，避免全表扫描。
- 返回更少数据（减少网络传输或磁盘访问）
- 减少交互次数（减少网络传输）
将数据存放在更快的地方
某条查询涉及到大表，无法进一步优化，如果返回的数据量不大且变化频率不高但访问频率很高，此时应该考虑将返回的数据放在应用端的缓存当中或者 Redis 这样的缓存当中，以提高存取速度。
- 减少服务器 CPU 开销（减少 CPU 及内存开销）
- 避免大事务操作
- 利用更多资源（增加资源）
案例
深翻页
limit offset
分页优化
limit
group by
group by having带的一般条件如type=”s”可以改为where条件加到group by之前减少group by数据量
order by
MySQL使不使用索引与所查列无关，只与索引本身，where条件，order by 字段，group by 字段有关。
索引的作用一个是查找，一个是排序。
范围查询
索引下推
索引下推的目的是为了减少回表次数，也就是要减少 IO 操作。
对于的聚簇索引来说，数据和索引是在一起的，不存在回表这一说。
条件
- 只能用于range、 ref、 eq_ref、ref_or_null访问方法
- 只能用于InnoDB和 MyISAM存储引擎及其分区表
- 对存储引擎来说，索引下推只适用于二级索引（也叫辅助索引）
references