QPS提升10倍的sql优化
💡
原文中文，约3700字，阅读约需9分钟。
📝
内容提要
本文讲述了一次针对4c16g单实例mysql的慢SQL优化过程，通过分析应用请求、日志和MySQL连接数指标，发现问题出在索引字段传参类型不一致上。经过修复，成功解决了CPU利用率过高的问题，并节约了实例升级的成本。总结了优化经历，强调了SQL的重要性和表结构设计的合理性。
🎯
关键要点
- 本文讲述了4c16g单实例mysql的慢SQL优化过程。
- 在大促准备期间，发现数据库在流量高峰时CPU利用率达到100%。
- 通过分析应用请求、日志和MySQL连接数指标，发现问题出在索引字段传参类型不一致上。
- 优化过程中尝试提高缓存命中率和调整连接池配置，但未能解决问题。
- 最终通过修复SQL，将siteId传参类型改为字符串，成功降低CPU利用率。
- 优化后数据库支持QPS从437提升至4610，节约了实例升级成本。
- 总结强调了SQL的重要性和表结构设计的合理性。
❓
延伸问答
如何优化MySQL的慢SQL以提升QPS？
通过分析应用请求、日志和MySQL连接数指标，发现索引字段传参类型不一致是导致慢SQL的原因，修复后成功将QPS从437提升至4610。
在高流量情况下，MySQL数据库CPU利用率过高的原因是什么？
CPU利用率过高的原因是查询语句的索引字段传参类型不一致，导致索引失效。
优化过程中尝试了哪些方法来降低CPU利用率？
尝试提高缓存命中率和调整连接池配置，但这些方法未能解决CPU利用率过高的问题。
如何确认SQL查询是否使用了索引？
可以通过分析SQL的执行计划来确认查询是否使用了索引，查看Extra信息是否显示使用了索引条件。
修复SQL时需要注意哪些细节？
需要确保索引字段的传参类型与表中字段类型一致，以避免索引失效。
优化SQL后对数据库性能的影响是什么？
优化后数据库的QPS从437提升至4610，CPU利用率降低到20%以下，显著提升了性能并节约了升级成本。
➡️
