当遇到SQL查询慢的问题时，需要区分是偶发还是持续。偶发慢可能由于数据库其他操作、刷新脏页、备份任务等原因。持续慢则多关注SQL本身，如数据量、请求数据量、索引使用、关联查询和子查询等。可以通过explain分析执行计划，优化SQL或调整索引。数据量大且buffer pool小会导致内存与磁盘交换频繁，影响性能。实际案例中，buffer pool设置错误可能导致性能问题。
可能是经常处理业务，最近总是听到开发的同学说SQL的查询慢。然后问我为什么，让我在数据库层面找原因。这样的需求接的多了，对于这类需求，我已经有了一套比较官方的回答思路，我来说，大家看，看看还有什么没有考虑到的地方，欢迎指正。
首先，当有业务方对我说SQL查询慢的时候，一般我会先问几个问题：
1、这个SQL是偶尔比较慢还是一直这么慢？
如果是偶尔比较慢，那大概率说明不是SQL层面的问题，应该是在某个时间点遇到了数据库的其他动作，导致产生了影响，例如：
第一、该条语句要扫描的表被加锁了，所以导致拿不到数据，查询很慢。
第二、查询的时间点，恰好数据库在刷新脏页，我们知道数据库进行了更新操作之后，不会立刻将这些数据进行落盘，而是刷新到redo log中去，等到空闲的时候，通过redo log里面的日志将数据同步到磁盘中去。
第三、当前时间点正在进行一个大的备份任务，导致磁盘的IO突然增高，内存和磁盘的交互速度变慢，自然而然，查询的速度也就降下来了。
第四、其他未知的神秘力量，例如大表操作、大事务、网络带宽被占用等等
如果是一直这么慢，一般情况下，SQL层面的问题可能比较大，而SQL层面，首先要考虑这几个要素：
1、表的数据量有多大？上亿条还是只有几万条？如果是上亿条，那还说得过去，如果是几万条但是速度很慢，大概率是SQL质量太差。
2、是否向数据库请求了不必要的数据，
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
