MySQL性能优化实战：16年工程师的毫秒响应全链路突破
|
文章配图，仅供参考 去年5月，我接手了一个电商平台的MySQL性能优化项目——用户反馈下单页面响应时间从200ms飙到2.3秒，直接导致转化率掉了15%。查日志发现，问题出在订单表的复合索引设计上：原团队为了覆盖所有查询场景，给一个2000万行的表加了7个复合索引，其中3个索引的字段顺序完全一致，只是数据类型不同（比如varchar和char混用）。这直接导致InnoDB的索引选择策略失效，每次查询都要扫描多个冗余索引，单次IO开销从5ms涨到120ms。当时我干了件“激进”的事——直接删掉5个冗余索引，只保留两个最核心的（用户ID+商品ID+时间戳、订单状态+支付时间），同时把表从InnoDB换成MyRocks（Facebook开源的LSM树引擎）。测试环境跑TPCC-MySQL基准测试，QPS从1200涨到4800，99%响应时间从1.2秒压到180ms。但上线第一天就翻车——支付回调接口报错率飙到3%，原因是MyRocks的强一致性写入比InnoDB慢30%，而支付系统对事务提交延迟敏感度极高。这教训太深刻了——新技术不是银弹，得看场景。 后来我折中方案：主库用InnoDB+优化后的索引，从库用MyRocks做只读查询。主库的索引调整更狠——把原来20个字段的复合索引拆成3个单字段索引+2个短复合索引，利用MySQL 8.0的索引下推（ICP）特性，让WHERE条件里的范围查询（比如“下单时间>2024-01-01”）直接在存储引擎层过滤，减少回表次数。实测数据：订单查询接口的CPU使用率从65%降到28%，99%响应时间稳定在85ms以内——这比最初要求的200ms还低57.5%。 有个细节很多人忽略：MySQL的锁竞争对性能的影响可能比索引更致命。去年11月，我遇到个诡异案例——某个报表查询偶尔会卡住，持续30秒以上。查processlist发现是某个SELECT语句在等MDL锁（元数据锁），而锁的持有者是个ALTER TABLE操作——更离谱的是，这个ALTER只加了个注释字段，按理说应该秒级完成。深挖后发现，原团队为了“安全”在ALTER前加了FLUSH TABLES WITH READ LOCK，导致整个实例的MDL锁被锁死。后来我改用pt-online-schema-change工具（Percona的在线DDL工具），通过创建影子表+触发器同步数据的方式，把ALTER操作对业务的影响从30秒降到0.5秒——这工具我用了12年，依然觉得它是MySQL生态里最实用的工具之一。 新技术确实香，但别盲目追——比如MySQL 8.0的直方图统计（histogram statistics）能显著提升复杂查询的估算精度，但我在测试中发现，对小表（行数 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
