QPS提升10倍的sql优化
内容提要
本文讲述了一次针对4c16g单实例mysql的慢SQL优化过程，通过分析应用请求、日志和MySQL连接数指标，发现问题出在索引字段传参类型不一致上。经过修复，成功解决了CPU利用率过高的问题，并节约了实例升级的成本。总结了优化经历，强调了SQL的重要性和表结构设计的合理性。
延伸解读
索引失效的隐蔽性
文章指出，即使查询字段“走了索引”，也可能因传参类型不一致导致索引未完全生效。这种失效不会触发慢SQL日志，但会显著增加CPU消耗。读者需注意，索引使用情况不能仅凭执行计划中的“Using index”判断，还需确认参数类型与字段定义是否匹配。
连接池调整的局限性
作者尝试通过提高缓存命中率和调整连接池配置来解决问题，但均未奏效。这表明，当问题根源在于SQL本身时，外围优化往往徒劳。读者在排查性能问题时，应优先检查SQL语句与表结构，避免在非关键路径上浪费精力。
表结构设计的历史遗留影响
文章提到，site_id字段在表中定义为字符串类型，但业务含义上可能更适合整型。这种不一致导致开发人员容易在传参时犯错。表结构设计应与业务含义保持一致，以减少SQL编写错误，降低后期维护成本。
优化收益与成本节约
通过修复SQL，数据库QPS从437提升至4610，CPU利用率大幅下降，避免了升级实例的机器成本。这体现了SQL优化在降本增效方面的直接价值。读者应重视SQL质量，将其作为性能优化的首要切入点。
Q&A
如何优化MySQL的慢SQL以提升QPS？
通过分析应用请求、日志和MySQL连接数指标，发现索引字段传参类型不一致是导致慢SQL的原因，修复后成功将QPS从437提升至4610。
在高流量情况下，MySQL数据库CPU利用率过高的原因是什么？
CPU利用率过高的原因是查询语句的索引字段传参类型不一致，导致索引失效。
优化过程中尝试了哪些方法来降低CPU利用率？
尝试提高缓存命中率和调整连接池配置，但这些方法未能解决CPU利用率过高的问题。
如何确认SQL查询是否使用了索引？
可以通过分析SQL的执行计划来确认查询是否使用了索引，查看Extra信息是否显示使用了索引条件。
修复SQL时需要注意哪些细节？
需要确保索引字段的传参类型与表中字段类型一致，以避免索引失效。
优化SQL后对数据库性能的影响是什么？
优化后数据库的QPS从437提升至4610，CPU利用率降低到20%以下，显著提升了性能并节约了升级成本。
