标记删除是应用层通过添加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的处理是“逻辑删除”：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 记录被标记为“已删除”，所在页仍保留在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，判断是否需要优化