由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或业务逻辑阻塞。
AI生成3D模型，仅供参考
定位真实慢SQL，依赖MySQL的慢查询日志（slow_query_log）与long_query_time参数。建议将阈值设为200ms，并开启log_queries_not_using_indexes，辅以pt-query-digest工具聚合分析，快速锁定TOP5消耗90%资源的语句。
索引失效是高频原因。WHERE中对字段使用函数（如YEAR(create_time) = 2024）、隐式类型转换（字符串ID用数字比较）、或LIKE以通配符开头（'%abc'），都会绕过索引。改写为范围查询、添加函数索引（MySQL 8.0+），或重构条件结构可立竿见影。
联表查询易成性能黑洞。避免SELECT ，只取必需字段；JOIN字段必须有索引且类型严格一致；小表驱动大表原则下，用STRAIGHT_JOIN强制关联顺序。单次查询超过5张表时，考虑在应用层分步查+内存组装，反而更快。
数据量激增后，单表超千万行？垂直拆分（用户属性/行为分离）、水平分片（按user_id取模）或归档冷数据（如event_log保留180天）比硬扛更有效。归档可借助pt-archiver工具，在低峰期无锁迁移，业务零感知。
最后一步常被忽视：缓存穿透与雪崩防护。对高频固定查询（如配置表），用Redis做二级缓存，并设置随机过期时间；对热点key加本地缓存（Caffeine）+互斥锁，避免数据库被突发请求压垮。
优化不是一次性工程。建立SQL准入卡点：上线前必须通过审核脚本（检测索引覆盖、执行计划稳定性、影响行数预警）；结合监控告警（QPS突降、InnoDB row lock time飙升），让性能治理融入开发闭环。毫秒级响应，来自持续观察与克制设计。