一条sql语句为何执行这么慢

Myth丶恋晨 2021-12-12 23:19 355阅读 0赞

mysql是大多数场景下都可以使用的数据库，大厂阿里很多都有用到，大家有没有遇到一条sql语句执行速度很慢的情况呢，下面就我自己掌握的技能未大家分析分析，不足请补充指教。
        ![启动mysql](https://img-blog.csdnimg.cn/20190712223258397.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU=,size_16,color_FFFFFF,t_70)

# 执行速度一直都慢 #

### （1）、字段没有索引 ###

![没有用索引][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU_size_16_color_FFFFFF_t_70]  
select \* from users where id>2 (\*星号为了书写方便）  
刚好你的 id 字段上没有索引，只能走全表扫描了，所以，这回导致这条查询语句很慢。

### （2）、字段有索引，但却没有用索引 ###

![索引][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU_size_16_color_FFFFFF_t_70 1]  
select \* from users where id-1>2 (\*星号为了书写方便）  
在大于表达式左边进行运算操作，导致id有索引也不会走索引，在表达式右边不会造成这种情况 where id > 2+1

### （3）、函数操作导致没有用上索引 ###

这种情况和第二种比较类似，在表达式左边进行运算操作；

### （4）、数据库自己选错索引了 ###

这个是有存在主键索引和非主键索引的情况，主键索引存的的是整个主键字段数据，非主键索引存的是主键字段的值，当where表达式后面的条件使用非主键字段时，有可能造成不走索引时根据非主键索引字段采样基数决定的，这一块不是很懂，请大家自行查找资料

### （5）、只是有时很慢，大多数正常 ###

1，这样的情况有可能是刷新脏页造成的，在插入修改数据时，mysql会首先修改内存中的数据，然后记录redo log 日志，空闲时才会通过redo log 日志把数据写到磁盘。  
2，遇到数据库锁，行锁之类的，show processlist命令查看状态情况

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU_size_16_color_FFFFFF_t_70 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU_size_16_color_FFFFFF_t_70]: /images/20211210/646614b07c024e25b12386edeeff5e0a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU_size_16_color_FFFFFF_t_70 1]: /images/20211210/51795debf6cf4de8ae2d48dcfd099a30.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0OTI2NjU_size_16_color_FFFFFF_t_70 2]: /images/20211210/14c15a7d2ddb452fa71b0739738dbc10.png