如何确认慢查询真的存在
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字段之间怎么组合，往往比单字段索引重要得多；而最麻烦的，通常是那些“看起来走了索引，但实际效果极差”的查询——它们不会报错，也不会触发慢日志阈值，却悄悄拖垮整条链路。
