软删除

软删行还占着唯一键：把 deleted_at 塞进唯一索引的三个反直觉陷阱与一套正确姿势 «栈：MySQL 8.0.32（InnoDB，"innodb_default_row_format=dynamic"）、Java 17、一套 SaaS

背景： 带团队做表设计这 15 年，被业务方和开发问得最多、也最容易当场吵起来的一个问题，就是「这张表要不要加个 deleted 字段做软删除？」。我的体感是：几乎每个团队都有软删除，但很少有人能清楚说出「为什么加、加在哪些表、索引怎么配套

背景 做了 10 年 DBA，被业务方问得最多的第二个问题（第一个是"表要爆了怎么办"）就是："这条数据能不能删？" 每次回答"能删"，对方都要追问一句："那万一以后要查呢？"——于是 "is_deleted" 字段就这么诞生了。然后三年后

«结论先行：软删除（"deleted_at" 列 + "WHERE deleted_at IS NULL"）用得越久，二级索引里「同一个 customer_id 下挂着一串已删除行」的簇就越大，优化器从「覆盖索引直接出结果」退化成「索引扫描