mysql数据库响应缓慢如何排查_使用EXPLAIN分析执行计划

type为ALL表示全表扫描，说明MySQL未使用索引；若rows接近总行数且Extra含Using where但无Using index，则索引失效。应检查WHERE字段是否建索引、遵循联合索引最左匹配、确保类型一致、避免索引列上函数操作。EXPLAIN 显示 type 是 ALL，说明在全表扫描这是最常见也最危险的信号：MySQL 没走索引，每查一次就扫一遍整张表。尤其当 rows 值接近表总行数，且 Extra 里出现 Using where（但没 Using index），基本可以断定索引失效。实操建议：检查 WHERE 条件字段是否建了索引，注意联合索引的最左匹配原则——INDEX(a, b, c) 能用上 a = ? 或 a = ? AND b = ?，但对 b = ? 无效确认字段类型和查询值类型一致，比如 user_id 是 BIGINT，但写成 WHERE user_id = '123'（字符串）会触发隐式转换，索引失效避免在索引列上做函数操作，WHERE YEAR(create_time) = 2024 不会走 create_time 索引；改用 create_time >= '2024-01-01' AND create_time EXPLAIN 的 key 为空，但明明建了索引索引存在 ≠ 查询会用。MySQL 优化器可能认为走索引比全表扫描更慢（比如返回结果占表 20% 以上），于是主动放弃索引。实操建议：用 ANALYZE TABLE table_name 更新统计信息，让优化器重估成本加 FORCE INDEX 强制走某索引（慎用）：SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123 AND status = 'paid'检查索引选择性：如果 status 只有 'paid'/'pending'/'failed' 三个值，这个字段单独建索引意义极小；更适合放在联合索引后位EXPLAIN 中 Extra 出现 Using filesort 或 Using temporary这不是错误，但意味着排序或分组没走索引，MySQL 得额外分配内存或磁盘临时表，性能损耗明显。尤其是 ORDER BY 和 GROUP BY 字段没被索引覆盖时高频出现。 MacsMind 电商AI超级智能客服