MySQL性能优化实战：18年经验铸就毫秒响应

　　去年十一月份那波优化，现在想起来还后怕——告警响的那一刻，我盯着监控屏上跳红的QPS，手里泡面汤洒在键盘上都没察觉。开发在群里喊“数据库又卡了”，运维群同时炸了锅，三台机器的CPU全飙到98%，慢查询日志里那几个SQL跟复制粘贴似的，全是没走索引的全表扫描。我原以为只是索引没建好，结果连着跑了三天explain plan，发现是某个历史表的主键自增策略被改成了UUID，索引碎片率直接炸了。

文章配图，仅供参考

　　但真正要命的不是索引，是锁。慢查询里有个update语句，锁了整张表三分钟，导致所有插入操作排队堵成狗。我翻历史命令记录，发现是某个开发为了“保证数据一致性”，给单条更新加了for update——他可能不知道，在百万级表上加行锁，跟用牙签撬保险柜差不多。我冲进开发办公室，把监控截图甩他桌上：“你这行代码，让整个业务线卡了二十分钟！”他挠头：“我原以为for update是原子操作，不会影响性能…”我差点把键盘砸他脸上：“原子操作？你知不知道InnoDB的锁升级机制？表锁、间隙锁、意向锁，你当是过家家呢？”

　　其实那会儿我最烦的不是技术问题，是“明明知道该怎么优化，却没人听”。比如有个查询条件永远带time_range，可索引偏偏建在id上；比如有个join操作明明能用覆盖索引，非要回表查全字段；比如有个事务开了autocommit=0，却从来不显式提交，导致连接池里全是长事务。我跟开发吵了无数架，他们总说“现在没时间改，先上线再说”——可上线后卡顿了，又反过来怪我们数据库不行。我后来学乖了，直接在慢查询日志里截取执行时间最长的十条SQL，贴到周会PPT首页，标题写“本周TOP10杀人凶手”，效果比吵架管用多了。

　　不过说到底，这波优化能做到毫秒响应，靠的还真不是技术——是“优胜劣汰”。我把所有慢查询的SQL都抓出来，按执行时间排序，前20%的语句占了80%的耗时。然后我做了三件事：第一，给这些SQL加索引，或者改写查询条件；第二，把超过100ms的查询直接kill掉，让开发自己优化；第三，把优化后的SQL和原始SQL的执行计划对比，贴到内部wiki上，标题写“看看人家怎么写的”。结果你猜怎么着？两周后，慢查询日志里的记录少了90%，QPS涨了3倍，CPU负载稳定在15%以下——开发们终于意识到，写SQL不是写代码，是写“性能契约”。

　　但最讽刺的是，我后来查日志，发现最初导致CPU飙高的那个UUID主键表，其实是某个“资深架构师”设计的——他三年前就离职了，留下的烂摊子，我们花了三个月才收拾干净。我盯着那个表的创建语句，里面还有他写的注释：“用UUID避免主键冲突，更安全”——安全个鬼！自增ID的冲突概率是0.000001%，UUID的索引碎片率是90%，这账他算过吗？

　　现在回头看，那波优化能成，核心就一句话：别跟烂代码讲道理，直接用数据打脸。你跟开发说“这个SQL要优化”，他们可能当耳旁风；但你把执行计划截图、耗时统计、影响范围甩过去，再补一句“这个查询卡了十分钟，导致XX业务线损失了XX单”，他们立马就怂了——毕竟，谁也不想背“因为写烂SQL导致公司亏钱”的锅。

　　窗外天快亮了，我揉着眼睛看监控屏，QPS稳定在5000+，响应时间全部绿色。同事小李凑过来：“哥，你这波优化太猛了，教教我？”我指了指屏幕上的慢查询日志：“先把这200条SQL看懂，再看explain plan，最后记住——在MySQL里，没有‘差不多就行’，只有‘毫秒还是秒’。”他点头，我转身去泡第二包面——今晚应该不用加班了，但明天，谁知道呢？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!