为什么 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 在提醒你语句可能主从不一致 分批删的边界判断、索引覆盖是否完整、以及 binlog 格式对语句重放的影响，这三点最容易被跳过，但恰恰决定一次删除操作到底稳不稳。
