delete未走索引主因是where条件未命中有效索引，如无索引、用函数、隐式类型转换等，导致全表扫描；应通过explain验证执行计划，确保最左前缀匹配，并分批删除防锁表与性能崩溃。
为什么 DELETE 没走索引，反而变全表扫描？
MySQL 的 DELETE 语句是否走索引，完全取决于 WHERE 条件能否命中有效索引。如果条件字段没索引、用了函数（如 WHERE YEAR(create_time) = 2023）、或存在隐式类型转换（比如 id 是 BIGINT 但传了字符串 '123'），优化器就会放弃索引，触发全表扫描+逐行锁，性能断崖式下跌。
实操建议：
- 用
EXPLAIN DELETE FROM t WHERE ...（5.6+ 支持）或先改写为SELECT查看执行计划 - 确保
WHERE中所有过滤字段都落在联合索引的最左前缀上，例如索引是(status, created_at)，则WHERE status = 1 AND created_at > '2024-01-01'可用，但WHERE created_at > '2024-01-01'不可用 - 避免在索引列上使用
!=、NOT IN、OR（多个条件未共用同一索引时），这些容易导致索引失效
大表删数据卡死？试试 LIMIT + 循环分批删
单次删除百万级行会持有大量行锁、撑爆 undo log、阻塞 DML，还可能触发 long transaction 报警。直接 DELETE FROM t WHERE ... 风险极高，必须分批。
实操建议：
- 用
DELETE FROM t WHERE ... ORDER BY id LIMIT 1000，每次删固定条数，配合循环脚本执行 - 务必加
ORDER BY（推荐主键），否则LIMIT行为不确定，可能漏删或重复删 - 两次删除之间加短暂停顿（如
SLEEP(0.1)），缓解主从延迟和 I/O 压力 - 注意：不要用
DELETE ... JOIN或子查询带IN (SELECT ...)分批，这类写法在旧版本中可能全表扫描子查询，性能更差
DELETE FROM t 为什么比 TRUNCATE 慢那么多？
DELETE FROM t（无 WHERE）仍是逐行删除：记录 binlog、生成 undo、触发触发器、受事务控制；而 TRUNCATE TABLE t 是 DDL 操作，直接重建空表，不走事务、不记完整 binlog（仅记 drop+create）、不触发触发器，快一个数量级。
但要注意限制：
-
TRUNCATE无法回滚（即使在事务里执行，提交前也会隐式提交） - 不能用于有外键引用的表（除非禁用
foreign_key_checks，但不推荐） - 会重置
AUTO_INCREMENT计数器，DELETE不会 - 权限要求更高：
TRUNCATE需要DROP权限，DELETE只需DELETE权限
binlog_format = STATEMENT 下 DELETE 要特别小心
如果 MySQL 使用 STATEMENT 格式写 binlog，且 DELETE 语句含非确定性函数（如 NOW()、RAND()、@user_var），主从数据可能不一致——因为从库重放时函数值不同。
实操建议：
- 生产环境强烈建议设为
binlog_format = ROW，它记录每行变更，安全可靠 - 若必须用
STATEMENT，禁止在WHERE中使用任何非确定性表达式 - 检查慢日志里是否有
Unsafe statement警告，这是 MySQL 在提醒你语句可能主从不一致
