确认慢查询需检查slow_query_log是否开启及long_query_time设置是否合理，默认10秒，线上建议调至0.5~1秒；可通过show variables查看，set global动态开启，并注意日志输出方式与权限。
如何确认慢查询真的存在
mysql 的慢查询不是靠感觉判断的，得看 slow_query_log 是否开启，以及 long_query_time 设置是否合理。默认是 10 秒，线上环境通常要调到 1 秒甚至 0.5 秒——很多业务接口超时才 2 秒，查 1 秒还没出结果已经算慢了。
- 检查当前状态：
SHOW VARIABLES LIKE 'slow_query_log';和SHOW VARIABLES LIKE 'long_query_time'; - 动态开启（无需重启）：
SET GLOBAL slow_query_log = ON;，但要注意日志文件路径权限问题 - 日志默认写入服务器磁盘，高并发下可能成为 I/O 瓶颈，可考虑用
log_output = 'table'写进mysql.slow_log表，方便 SQL 分析
EXPLAIN 看懂执行计划的关键字段
EXPLAIN 输出里真正决定性能的是 type、key、rows、Extra 这四列，其他列容易干扰判断。
-
type值从好到坏：const≈eq_ref>ref>range>index>ALL；出现ALL基本等于全表扫描 -
key为空？说明没走索引，要么没建、要么隐式类型转换（比如WHERE user_id = '123'对 int 字段）或函数包裹（WHERE date(create_time) = '2024-01-01'） -
rows是 MySQL 预估扫描行数，比实际数据量大一个数量级？大概率索引失效或统计信息过期，可运行ANALYZE TABLE t_name; -
Extra出现using filesort或Using temporary要警惕，尤其是二者同时出现，意味着排序 + 中间临时表，IO 和内存压力都大
常见却容易被忽略的优化动作
有些“小改动”影响远超预期，但常被跳过：
-
ORDER BY字段必须包含在联合索引最右位，且顺序一致；例如ORDER BY status, created_at DESC，索引要建为(status, created_at)，而不是(created_at, status) -
LIMIT不是万能的，select * FROM t WHERE a=1 ORDER BY b LIMIT 10如果没索引覆盖a和b，仍会先扫所有a=1的行再排序取前 10 -
IN列表超过 500 项时，MySQL 可能放弃使用索引，改用range或全表扫描；可拆成多个语句，或改用临时表 JOIN - 字符串字段用
LIKE 'abc%'能走索引，但LIKE '%abc'或LIKE '%abc%'不能，除非用全文索引或generated column + index
线上直接分析慢日志的实用命令
别急着导出整个慢日志文件，先用系统工具快速定位瓶颈点：
- 统计最耗时的前 10 条：
mysqldumpslow -s at -t 10 /var/lib/mysql/slow.log - 找访问频次最高的 SQL：
mysqldumpslow -s c -t 10 /var/lib/mysql/slow.log - 注意：如果启用了
log_output = 'TABLE'，直接查表更准：SELECT sql_text, query_time, lock_time, rows_sent FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10; - 查出具体 SQL 后，一定要在从库或低峰期复现并
EXPLAIN format=TREE（8.0+）看完整执行树，避免只看主键等简单场景下的假象
索引不是建得越多越好，WHERE 条件字段、JOIN 字段、ORDER BY 和 GROUP BY 字段之间怎么组合，往往比单字段索引重要得多；而最麻烦的，通常是那些“看起来走了索引，但实际效果极差”的查询——它们不会报错，也不会触发慢日志阈值，却悄悄拖垮整条链路。