由 dawei 
AI提供的信息图，仅供参考
慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或前端渲染。
定位慢SQL最有效方式是开启慢查询日志（slow_query_log），配合long_query_time=0.5捕获亚秒级隐患。用pt-query-digest分析日志，可快速识别TOP 10高耗资源SQL及其调用频次、锁等待、全表扫描占比等关键维度。
索引失效是高频根因。避免在WHERE字段上使用函数（如YEAR(create_time) = 2024）、隐式类型转换（字符串ID与数字比较）或前置模糊匹配（'%abc'）。联合索引需遵循最左前缀原则，且将筛选性高、区分度大的列放在前面。用SELECT COUNT(DISTINCT column)/COUNT()评估选择性，低于5%谨慎建索引。
单表数据超千万时，单靠索引常难救场。可引入覆盖索引消除回表，用SELECT id, name FROM t WHERE status=1 AND create_time > '2024-01-01'替代SELECT ；对高频大结果集分页，改用游标分页（WHERE id > last_id LIMIT 20）替代OFFSET；冷热数据分离，将历史订单归档至按月分区表。
配置不当会放大SQL缺陷。适当调高innodb_buffer_pool_size（建议设为物理内存的70%~80%），确保热数据常驻内存；关闭query_cache_type（MySQL 8.0已移除），避免缓存失效开销；监控Threads_running和Innodb_row_lock_waits，及时发现锁争用。
优化不是一锤子买卖。上线后必须做压测对比：用相同并发量跑优化前后SQL，记录QPS、平均延迟、95线及CPU/IO变化。同时在业务低峰期灰度发布，结合错误日志与慢日志二次验证——真正的毫秒响应，是可量化、可持续、可回滚的链路成果。