标记删除是应用层通过添加is_deleted等字段实现的软删除策略，用UPDATE替代DELETE并默认过滤已删数据；而InnoDB的DELETE是逻辑删除，仅打删除标记，空间需OPTIMIZE TABLE等操作主动回收。
SQL数据库本身不提供原生的“标记删除”功能，所谓标记删除是应用层实现的软删除策略；而延迟清理是存储引擎（如InnoDB）在执行物理DELETE时的底层行为——它把记录打上删除标记、暂不回收空间，后续由后台线程或显式命令触发真正清理。
什么是标记删除（软删除）
这是业务逻辑层面的设计，不是数据库自带机制。核心是在表中增加一个字段（如is_deleted、deleted_at），用UPDATE代替DELETE：
- UPDATE user SET is_deleted = 1 WHERE id = 123;
- 所有查询需默认加上 WHERE is_deleted = 0，或用视图/ORM作用域封装过滤逻辑
- 优点：数据可恢复、审计友好、避免外键级联误删
- 缺点：查询变慢（索引失效风险）、统计需额外处理、长期积累影响维护成本
为什么DELETE后磁盘空间不释放
InnoDB对DELETE的处理是“逻辑删除”：
- 记录被标记为“已删除”，所在页仍保留在B+树中，只是不再对SELECT可见
- 空闲空间会被后续INSERT复用（例如ID在300–700之间的新行可能填入刚删掉的R4位置）
- 表文件大小（.ibd）不会自动缩小，除非执行OPTIMIZE TABLE或ALTER TABLE ... ENGINE=InnoDB
- 该机制减少I/O压力、避免碎片，但会掩盖真实空间占用
如何主动触发延迟清理
有三类常用方式，按场景选择：
- 单表整理：运行 OPTIMIZE TABLE t; —— 重建表、整理碎片、回收已删空间（会锁表，建议低峰期）
- 批量归档后清理：先将保留数据导出到新表，再原子替换（RENAME TABLE），旧表直接DROP，空间立即释放
- 分区表高效清理：按时间分区的表，用 ALTER TABLE t DROP PARTITION p202301; —— 元数据操作，秒级完成，空间立刻返还
安全删除的必备习惯
无论用硬删还是软删，以下动作不能跳过：
- 执行前用SELECT COUNT(*)验证WHERE条件是否准确
- 大表操作加事务包裹，删完检查再COMMIT
- 生产环境禁用无WHERE的DELETE，MySQL可设sql_safe_updates=1强制约束
- 记录操作日志：谁、何时、删了什么条件、影响多少行
- 定期用SHOW TABLE STATUS对比Data_free和Data_length，判断是否需要优化
