Skip to content

Latest commit

 

History

History
64 lines (44 loc) · 2.73 KB

long_query.md

File metadata and controls

64 lines (44 loc) · 2.73 KB

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