SQL删除时避免全表扫描_确保WHERE条件使用覆盖索引-SQL-PHP中文网

DELETE语句执行慢是因为WHERE条件未走索引导致全表扫描；需确保WHERE列有匹配的单列或联合索引，避免隐式转换、函数操作及错误的最左前缀使用。

sql删除时避免全表扫描_确保where条件使用覆盖索引

因为 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 会放弃索引——务必保持类型一致

没用。覆盖索引（即 SELECT 只查索引字段时不用回表）对 DELETE 不生效。因为 DELETE 必须定位并修改聚簇索引记录，只要能快速定位行，靠的是「WHERE 条件走索引」，不是“覆盖”。

所以别为了“覆盖”去加冗余字段到索引里。重点只有一个：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 列。