由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或业务逻辑阻塞。
定位真实慢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+），或重构条件结构可立竿见影。
创意图AI设计，仅供参考
联表查询需警惕驱动表选择。EXPLAIN结果中，type为ALL或rows远超预期时，优先检查ON条件字段是否有联合索引，且顺序需匹配关联顺序。例如JOIN users ON u.id = o.user_id，应在orders表上建立(user_id, id)覆盖索引，避免回表。
数据量激增时，单表千万级仍可优化，但亿级需策略升级。冷热分离——将历史订单归档至按月分表；读写分离——主库只写，从库承载报表类复杂查询；必要时引入缓存，但避免缓存穿透：空结果也应缓存短时间（如60秒），并用布隆过滤器前置拦截非法ID请求。
性能提升常来自“小改动大收益”。批量替换UPDATE比循环单条快10倍以上；COUNT()在无WHERE时直接查information_schema.TABLES；JSON字段慎用——全文搜索需求改用Elasticsearch更可靠。每一次优化后，用sys.schema_table_statistics_with_buffer验证I/O与内存真实改善。
优化不是终点。建立持续观测机制：设置Query Response Time Histogram监控P95延迟波动，配置阈值告警；定期执行pt-online-schema-change对大表加索引，确保变更零感知。毫秒响应的背后，是精准诊断、克制修改与系统化防御共同达成的稳态。