SQL语句执行很慢的原因

database

大多数情况是正常的,只是偶尔会出现很慢的情况

  • 网络问题

  • 数据库在刷新脏页

  • 获取锁失败,我们可以用 show processlist这个命令来查看当前的状态

刷脏页有下面4种场景(后两种不用太关注“性能”问题):

  • redolog写满了:redo log 里的容量是有限的,如果数据库一直很忙,更新又很频繁,这个时候 redo log 很快就会被写满了,这个时候就没办法等到空闲的时候再把数据同步到磁盘的,只能暂停其他操作,全身心来把数据同步到磁盘中去的,而这个时候,就会导致我们平时正常的SQL语句突然执行的很慢,alter table 可能造成脏页过多。所以说,数据库在在同步数据到磁盘的时候,就有可能导致我们的SQL语句执行的很慢了。

  • 内存不够用了:如果一次查询较多的数据,恰好碰到所查数据页不在内存中时,需要申请内存,而此时恰好内存不足的时候就需要淘汰一部分内存数据页,如果是干净页,就直接释放,如果恰好是脏页就需要刷脏页。

  • MySQL 认为系统“空闲”的时候/ Master Thread:这时系统IO压力不大,每秒或每十秒的异步刷新操作

  • MySQL 正常关闭的时候:这时候,MySQL 会把内存的脏页都 flush 到磁盘上,这样下次 MySQL 启动的时候,就可以直接从磁盘上读数据,启动速度会很快。

在数据量不变的情况下,这条SQL语句一直以来都执行的很慢

  • 没有用上索引:例如该字段没有索引;由于对字段进行运算、函数操作导致无法用索引。
  • 数据库选错了索引

有索引但是最终却选择全表扫描的原因:

例如以下SQL:

select * from t where 100 < c and c < 100000;

索引的选择判断来源于系统的预测,也就是说,如果要走 c 字段索引的话,系统会预测走 c 字段索引大概需要扫描多少行。如果预测到要扫描的行数很多(大概接近于20%),它可能就不走索引而直接扫描全表了。因为索引c将标识多一次的辅助索引的查询,造成IO的增多。

系统判断是否走索引,扫描行数的预测其实只是原因之一,这条查询语句是否需要使用使用临时表、是否需要排序等也是会影响系统的选择的。

以上是 SQL语句执行很慢的原因 的全部内容, 来源链接: utcz.com/z/533197.html

回到顶部