DELETE语句执行慢是因为WHERE条件未走索引导致全表扫描；需确保WHERE列有匹配的单列或联合索引，避免隐式转换、函数操作及错误的最左前缀使用。
DELETE 语句没走索引，为什么执行特别慢？
因为 MySQL 在执行 DELETE 前，如果 WHERE 条件列没有可用索引，就会触发全表扫描——哪怕只删一行，也要读完整张表。尤其是大表（千万级+），I/O 和锁等待会直接卡住业务。
常见错误现象：EXPLAIN DELETE FROM t WHERE status = 'pending'; 显示 type: ALL，key: NULL；或者执行时 SHOW PROCESSLIST 长时间卡在 Updating 状态。
- 先确认 WHERE 字段是否建了索引：
SHOW INDEX FROM t WHERE Column_name = 'status'; - 单列索引不够？比如条件是
WHERE status = 'pending' AND created_at > '2024-01-01'，那就得建联合索引，且顺序要匹配：优先等值查询列（status）放前面，范围列（created_at）放后面 - 注意隐式类型转换：如果
status是VARCHAR，但写成WHERE status = 0，MySQL 会放弃索引——务必保持类型一致
覆盖索引对 DELETE 有用吗？
没用。覆盖索引（即 SELECT 只查索引字段时不用回表）对 DELETE 不生效。因为 DELETE 必须定位并修改聚簇索引记录，只要能快速定位行，靠的是「WHERE 条件走索引」，不是“覆盖”。
所以别为了“覆盖”去加冗余字段到索引里。重点只有一个：WHERE 中的列必须被某个索引的最左前缀完全覆盖。
- 错误示例：
INDEX (a, b)，但查询是WHERE b = 1→ 不走索引 - 正确示例：
INDEX (b, a)或INDEX (b)才能用于WHERE b = 1 - 复合条件建议用
EXPLAIN FORMAT=TREE（MySQL 8.0+）看实际访问路径，比传统EXPLAIN更直观
WHERE 条件含函数或表达式，索引还有效吗？
基本失效。比如 WHERE DATE(created_at) = '2024-01-01' 或 WHERE id + 1 = 100，MySQL 无法用索引做等值/范围查找，只能全表扫。
真正能走索引的写法，是把计算移到右边，让左边保持原始列名：
- ❌
WHERE YEAR(created_at) = 2024→ 不走索引 - ✅
WHERE created_at >= '2024-01-01' AND created_at → 走索引 - ✅
WHERE id = 99（而不是id + 1 = 100） - 如果业务真需要函数查询，考虑生成列 + 函数索引（MySQL 5.7+ 支持）：
ALTER TABLE t ADD COLUMN created_date DATE AS (DATE(created_at)) STORED;，再给created_date建索引
删除大量数据时，即使有索引也卡，怎么办？
索引能加速定位，但不解决高并发下的锁竞争和 binlog/undo 日志压力。删 100 万行，哪怕每行都命中索引，也可能锁表几十秒。
这时候核心不是“怎么更快定位”，而是“怎么减少单次操作影响”：
- 分批删：
DELETE FROM t WHERE status = 'old' ORDER BY id LIMIT 1000;，循环执行直到影响行为 0 - 避免
ORDER BY无索引字段，否则每次 limit 都可能触发文件排序；确保ORDER BY字段也在索引中（比如已有INDEX (status, id)） - 不要用
DELETE ... JOIN或子查询删大表——执行计划容易失准，且可能锁更多行 - 如果允许短时不可用，考虑
CREATE TABLE ... SELECT留下有效数据，再重命名，比逐行删快得多，也更少锁
最常被忽略的一点：即便 WHERE 条件用了索引，如果该索引区分度极低（比如只有 3 个值的 status 字段），优化器可能主动放弃走索引，改用全表扫描——这时得看 EXPLAIN 的 rows 和 filtered 值，不能只信 key 列。
