由 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对日志采集的干扰，避免误判。
索引失效是头号元凶。IN子句含超300个值、WHERE中对字段做函数操作（如YEAR(create_time) = 2024）、隐式类型转换（字符串ID用数字比较），都会绕过索引。用SHOW INDEX和EXPLAIN Extended交叉验证索引实际使用情况，重点关注key_len、rows和Extra中的“Using filesort”或“Using temporary”。
单表索引不是越多越好。联合索引需严格遵循最左前缀原则；删除长期未被使用的索引（通过sys.schema_unused_indexes视图识别），减少写入开销与内存占用。对大表分页，避免OFFSET过大，改用游标式查询：WHERE id > last_seen_id ORDER BY id LIMIT 20。
2026AI生成内容，仅供参考
查询瘦身同样关键。禁用SELECT ，只取必要字段；拆分复杂JOIN，将非实时关联移至应用层缓存组装；用COUNT()替代COUNT(列名)提升统计效率。对于高频聚合，预计算结果写入汇总表，配合触发器或业务层双写维护一致性。
参数调优要谨慎。innodb_buffer_pool_size建议设为物理内存的70%~80%，但必须保留足够系统资源；query_cache_type在8.0已移除，切勿在新版本配置。所有变更需在压测环境验证，单次只调整一个变量。
性能优化是持续过程，不是单次手术。建立SQL准入规范，开发阶段引入审核插件（如Soar）；上线后用Prometheus+Grafana监控QPS、InnoDB行锁等待、Buffer Pool命中率等核心指标，让毫秒响应成为常态，而非偶然。