云联信息：慢查询不治理，加机器也没用

一、先开慢查询日志

没有日志就没有依据。设置一个合理的阈值，比如超过一秒记录，跑一天看看有多少条。数量往往比想象的多，尤其是没有索引的模糊查询。

二、按耗时排序而不是按次数

出现次数多的慢查询未必最影响性能，单次耗时十秒的查询只要并发几个就能拖垮数据库。先按总耗时排序，处理排名前十的，通常能解决大半问题。

三、看执行计划找问题

用explain看是否走索引、扫描行数多少、有没有临时表。全表扫描是最常见的问题，加一个合适的索引往往立竿见影。索引不是越多越好，写多的表索引过多会拖慢写入。

四、避免在索引列上做运算

where里对字段做函数运算、类型隐式转换、前导通配符模糊匹配，都会导致索引失效。改写查询语句，把这些运算移到常量侧，索引才能用上。

五、分页查询要优化

limit偏移量很大时，数据库要扫描并丢弃前面的行，越翻越慢。改成基于上次最大ID的游标分页，性能稳定，不会随页码增加而恶化。

六、连接池参数要对齐

应用连接池开得太大，数据库连接数被打满，所有查询都变慢。连接池大小要跟数据库的最大连接数和实际并发匹配，不是越大越好。

七、把慢查询治理做成常态

每周看一次慢查询排行，新增的慢查询及时处理。等到业务反馈卡顿才查，往往已经积累了几十条。日常治理的成本远低于救火。

索引不是万能药

加索引能加快查询，但会拖慢写入并占用空间。写多读少的表要谨慎。索引建完观察一段时间，没有明显收益的就删掉。

缓存要防击穿

热点数据缓存失效的瞬间，大量请求同时打到数据库，会造成瞬时雪崩。加互斥锁或者错峰过期，能避免这类问题。

慢查询和业务逻辑有关

有些慢查询是代码里循环查库导致的，一条SQL只查一行，但执行了几百次。看数据库的同时也要看应用日志，两边一起分析才能找到根因。

索引要定期清理

业务迭代之后，早期建的索引可能已经没人用，却仍在拖慢写入。查一下索引使用统计，长期零命中的删掉，写入性能会有改善。

大表要分区或者归档

单表过亿之后，即使有索引，查询和备份都会变慢。按时间分区，把历史数据归档到冷表，是成本较低的做法。

读写分离要评估一致性

主从延迟存在时，刚写入的数据从库读不到，用户会觉得数据丢了。对一致性敏感的读操作走主库，其余走从库。

慢查询治理要看趋势

每周记录慢查询数量和总耗时，做成趋势图。数量突然上升往往是新上线功能引入的，早发现早处理。

云联信息【资深云服务专家微信：cloud7591】一般会先梳理现有架构图，把公网入口、数据流向和依赖关系画清楚，再谈优化。