MySQL删除数据必须带WHERE且字段有索引，优先用ORDER BY + LIMIT分批删除并用last_id递进，避免id BETWEEN引发死锁；删后空间不释放属正常，需ALTER TABLE重建表回收。
DELETE语句里必须带WHERE，否则ERROR 1175会拦住你
MySQL默认开启SQL_SAFE_UPDATES模式，直接执行DELETE FROM logs会报错：ERROR 1175 You are using safe update mode。这不是语法错误，而是客户端级防护——它强制你确认删除范围。
绕过方式是SET SQL_SAFE_UPDATES = 0，但这是自拆护栏。真正该做的是：所有DELETE必须显式写WHERE条件，且该条件字段要有索引支撑。没索引的WHERE status = 'old'照样可能扫全表、锁全表。
ORDER BY + LIMIT在DELETE中不是可选项，而是安全底线
只写WHERE create_time 是错的。MySQL不保证每次扫描顺序一致，会导致重复删或漏删——尤其在并发写入时，同一批数据可能被两个事务各自删一次，也可能某几行永远没被扫到。
正确姿势是强制加ORDER BY id（主键或有索引的单调字段）：
DELETE FROM logs WHERE create_time < '2023-01-01' ORDER BY id LIMIT 1000;
-
id必须有索引（通常是主键），否则ORDER BY触发filesort，IO爆炸 - 别用
LIMIT 10000, 1000——偏移越大越慢，还容易跳过新插入的行 - 批量大小建议1000–5000：太小增加解析开销，太大易触发长事务告警
用WHERE id > last_id比WHERE id BETWEEN更抗死锁
id BETWEEN 10000 AND 20000看似直观，但在InnoDB里会锁定整个区间及其间隙，如果并发删重叠范围（比如A删10000–20000，B删19999–29999），极易形成循环等待。
换成递进式推进，锁范围可控：
DELETE FROM logs WHERE create_time < '2023-01-01' AND id > 123456 ORDER BY id LIMIT 1000;
-
last_id必须来自上一批实际删除的最大id值，不能靠SELECT MAX(id)查全表——那条语句本身可能被锁住 - 每批删完必须
COMMIT，否则undo log和行锁不释放 - 应用层加
sleep(0.1)缓冲压力，别用SELECT SLEEP(0.1)塞在SQL里——它延长事务时间
删完数据磁盘空间不释放？这和ORDER BY LIMIT无关，但常被误归因
InnoDB删除只是标记数据页为“可复用”，物理空间不会立刻还给操作系统。所以即使你用最规范的ORDER BY id LIMIT分批删完，du -sh看到的数据目录大小也不会变。
要真正回收空间，得重建表：
ALTER TABLE logs ENGINE=InnoDB;
或者用mysqldump导出再导入。但注意：这个操作本身会锁表，必须安排在低峰期。日常运维中，与其盯着磁盘大小，不如监控innodb_data_free和innodb_page_size的利用率——它们才反映真实可复用空间。
