由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或业务逻辑阻塞。
定位真实慢SQL，依赖MySQL的慢查询日志（slow_query_log）与long_query_time参数。建议将阈值设为200ms，并开启log_queries_not_using_indexes，辅以pt-query-digest分析高频、高成本语句。注意关闭performance_schema对日志采集的干扰，避免误判。
AI模拟效果图，仅供参考
索引失效是头号元凶。常见场景包括：在WHERE子句对字段做函数操作（如YEAR(create_time) = 2024）、隐式类型转换（字符串ID被当作数字比较）、LIKE以%开头。用SHOW INDEX和EXPLAIN EXTENDED交叉验证索引实际使用情况，重点关注type（避免ALL）、key_len（越长越精准）、rows（越小越好）。
单表索引非万能。多表JOIN时，驱动表应选择结果集最小者，关联字段必须有高效索引；大分页（LIMIT 1000000,20）应改用游标分页：记录上一页最大id，WHERE id > ? ORDER BY id LIMIT 20。同时警惕SELECT ——只取必要字段，减少网络传输与临时表开销。
连接与配置同样关键。合理设置max_connections避免连接等待，但过高会加剧内存竞争；query_cache_type应禁用（MySQL 8.0已移除），因写入频繁时缓存失效代价远超收益。InnoDB buffer pool size建议设为物理内存的70%–80%，确保热数据常驻内存。
优化不是一次性的调参，而是闭环实践：每次变更后对比QPS、平均延迟、CPU/IO负载三指标；用sys schema视图（如statement_analysis）持续监控Top SQL；对核心接口建立SQL白名单与自动化审核流程。毫秒级响应，源于对数据访问路径的精准控制，而非盲目堆砌硬件。