由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或前端渲染。
定位慢SQL最有效方式是开启慢查询日志（slow_query_log），配合long_query_time=0.5捕获亚秒级隐患。用pt-query-digest分析日志，可快速识别TOP 10高耗资源SQL及其调用频次、锁等待、全表扫描等关键特征。
索引不是越多越好，而是精准匹配查询模式。对WHERE、ORDER BY、GROUP BY涉及的字段组合建索引时，遵循“最左前缀”与“选择性优先”原则。例如WHERE status=? AND created_at>? ORDER BY updated_at DESC，应建(status, created_at, updated_at)复合索引，而非单列索引堆叠。
避免隐式类型转换和函数包裹字段。如WHERE CAST(phone AS CHAR) = ‘138xxx’ 或 WHERE DATE(create_time) = ‘2024-01-01’，会导致索引失效。改写为phone = ‘138xxx’ 和 create_time BETWEEN ‘2024-01-01 00:00:00’ AND ‘2024-01-01 23:59:59’，即可命中索引。
AI生成图像，仅供参考
大表分页慎用OFFSET。LIMIT 1000000, 20会强制扫描前百万行。改用“游标分页”：记录上一页最后ID，用WHERE id > ? ORDER BY id LIMIT 20，响应时间从秒级降至毫秒级。
连接池配置常被忽视。max_connections过高易引发内存溢出，过低则请求排队。建议设置为应用并发数×1.5，并启用wait_timeout与interactive_timeout防止空闲连接堆积。搭配连接复用与预编译（useServerPrepStmts=true），减少解析开销。
优化不是单点修补，而是闭环行动：监控→定位→改造→压测→上线→对比。每次变更后用sysbench或真实流量对比QPS与P95延迟。多数场景下，一条索引+一句SQL重写，就能将3秒查询压缩至80ms以内——真正的突破，永远始于对执行计划背后逻辑的清醒认知。