mysql不能直接用explain分析delete语句的索引执行计划，需改写为等价select语句（如explain select 1 from users where ...），重点观察type是否为range/ref、key是否命中预期索引、rows是否合理，并规避函数包裹字段、隐式类型转换及复合索引顺序错位等问题。
delete语句的explain结果怎么看
mysql 不允许直接对 delete 语句执行 explain（navicat 点“解释”会报错或静默失败），但你可以把它等价转换成 select 来分析执行计划。关键不是看语法，而是看 where 条件是否能命中索引。
实操建议：
- 把你的
DELETE FROM users WHERE status = 'inactive' AND created_at 改写为 <code>SELECT * FROM users WHERE status = 'inactive' AND created_at ，再右键 → “解释” - 重点盯
type和key：如果type是ALL或index、key为空，那 DELETE 实际也会全表扫描 - 别信
rows数值太小就以为没问题——哪怕只删 1 行，若没索引，MySQL 仍要扫完整张表找匹配项
为什么DELETE明明写了WHERE却还是慢
常见原因不是语法错，而是索引根本没被用上。DELETE 和 SELECT 共享同一套优化器逻辑，但更容易暴露隐性问题。
容易踩的坑：
-
WHERE create_time > DATE_SUB(NOW(), INTERVAL 30 DAY)—— 函数包裹字段，索引失效；应改写为create_time > '2026-06-27 22:59:00'（手动算好时间点） - 字段类型不一致：
user_id是BIGINT，但条件写成WHERE user_id = '12345'，触发隐式转换，possible_keys可能有值，key却为空 - 复合索引顺序错位：建了
INDEX(status, created_at)，但条件是WHERE created_at ，最左前缀不匹配，索引不可用
如何确认索引真的存在且结构正确
Navicat 的“设计表 → 索引”界面看着直观，但容易漏细节。真正决定 DELETE 能不能快的，是索引定义本身是否生效。
必须验证的三件事：
- 运行
SHOW INDEX FROM users，确认输出里有你依赖的索引名，并且Seq_in_index显示字段顺序和 WHERE 条件顺序一致 - 检查
Cardinality值：如果某列Cardinality接近 0 或远小于表总行数，说明统计信息过期，执行ANALYZE TABLE users更新 - 留意索引类型：
FULLTEXT或SPATIAL索引对普通 WHERE 无效；UNIQUE和BTREE才是 DELETE 能用的主力
DELETE卡住时，怎么快速判断是不是索引问题
别只盯着 Navicat 界面的“正在执行…”转圈。真正的瓶颈往往藏在服务器端状态里。
立即查的命令：
- 在 Navicat 新建查询窗口，运行
SHOW PROCESSLIST，找State为Updating或Searching rows for update的线程，Info列会显示实际执行的 DELETE 语句 - 如果该语句的
Time持续增长且远大于 1 秒，基本可断定扫描范围过大；此时立刻去查对应表的EXPLAIN SELECT计划 - 注意
Extra出现Using where; Using index condition是好信号；若只有Using where，大概率没走索引下推（ICP），性能打折
真正卡住的地方，往往不是“有没有索引”，而是“WHERE 条件写法让索引成了摆设”，或者“索引存在但统计信息不准导致优化器主动绕开”。动手前，先看 EXPLAIN SELECT，再核 SHOW INDEX，最后动 ANALYZE TABLE —— 这三步比反复重试 DELETE 更省时间。
