由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或业务逻辑阻塞。
定位慢查询必须依赖真实生产数据。启用slow_query_log（long_query_time设为0.5秒），结合pt-query-digest分析Top SQL，重点关注Rows_examined远大于Rows_sent的语句——这往往意味着缺失索引或索引失效。切忌仅看执行时间排序，而忽略扫描行数与QPS权重。
AI生成的示意图，仅供参考
索引优化不是堆砌索引，而是理解B+树结构与最左前缀原则。对WHERE a=1 AND b>10 ORDER BY c，(a,b,c)联合索引可覆盖过滤与排序；若ORDER BY c DESC与WHERE中范围条件共存，需评估是否将c前置以避免filesort。务必用FORCE INDEX验证执行计划，警惕隐式类型转换导致索引失效。
大表分页（如LIMIT 1000000,20）本质是性能黑洞。改用游标分页：记录上一页最大ID，查询WHERE id > ? ORDER BY id LIMIT 20。对复杂统计场景，用汇总表或TTL缓存替代实时COUNT()；高频更新的聚合字段可借触发器或应用层异步写入。
连接与配置常被忽视。max_connections过低引发排队，过高则耗尽内存；innodb_buffer_pool_size应设为物理内存的70%–80%，确保热数据常驻内存。禁用query_cache（MySQL 8.0已移除），启用innodb_adaptive_hash_index提升热点键查询效率。
优化闭环在于验证与沉淀。每次变更后对比Percona Toolkit的pt-stalk捕获的指标波动，并将生效的索引策略、SQL重写范式固化为团队SQL审核清单。性能不是单点调优，而是查询、索引、配置、架构四层联动的持续过程——当95%的查询稳定在50ms内，系统才真正具备弹性基础。