物理删除用delete/truncate/drop直接删数据，逻辑删除靠is_deleted字段标记并过滤查询；选哪种取决于数据可丢性、可查性及外键关联。
物理删除直接删行，逻辑删除只改标记——选哪种，取决于数据能不能丢、要不要查、有没有外键关联。
MySQL里怎么写物理删除语句
物理删除就是用 DELETE 或 TRUNCATE TABLE 真删数据，不可逆：
-
DELETE FROM users WHERE id = 123：按条件删，走事务，可回滚，会触发触发器和外键级联 -
TRUNCATE TABLE users：清空整表，不走事务，不能回滚，重置自增ID，速度更快但更粗暴 -
DROP TABLE users：连表结构一起删，慎用
常见错误现象：DELETE FROM orders WHERE user_id = 456 执行后，关联的 order_items 表没设 ON DELETE CASCADE，导致孤儿记录残留；或者误删没加 WHERE 条件，整表清空。
逻辑删除必须加字段且改查询条件
逻辑删除不是“少写个 DELETE”，而是靠字段 + 显式过滤。核心动作只有三步：
- 加字段：
ALTER TABLE users ADD COLUMN is_deleted TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '0=未删除,1=已删除' - 删操作变更新：
UPDATE users SET is_deleted = 1, delete_time = NOW() WHERE id = 123 AND is_deleted = 0 - 所有读操作必须加条件：
SELECT * FROM users WHERE is_deleted = 0 AND status = 'active'
容易踩的坑：
- 漏加
AND is_deleted = 0—— 导致“查不到数据”却以为是业务问题，其实是逻辑删除漏过滤 - 字段类型用
TINYINT(1)或BOOLEAN—— MySQL 没布尔类型，TINYINT(1)容易被 ORM 当成 true/false 解析出错；必须用TINYINT UNSIGNED NOT NULL DEFAULT 0 - 唯一索引没适配 —— 比如
username原有唯一索引，删掉一个root用户后，再插入同名用户会冲突；得改成联合索引：ALTER TABLE users DROP INDEX idx_username, ADD UNIQUE INDEX idx_username_deleted (username, is_deleted)
MyBatis-Plus 自动处理逻辑删除的配置要点
用 MyBatis-Plus 时，@TableLogic 注解只是表层，真正起效靠的是全局配置和字段语义对齐：
- application.yml 中必须配全：
mybatis-plus.global-config.db-config.logic-delete-field: is_deleted、logic-delete-value: 1、logic-not-delete-value: 0 - 实体类字段类型必须是
Integer或Boolean（MP 内部转成 0/1），不能是Byte或Short，否则自动 SQL 改写失效 - MP 的自动改写只对它生成的 SQL 生效（比如
selectById、removeById）；手写@Select("SELECT * FROM users")的 XML 或注解 SQL 不会自动加is_deleted = 0，必须手动补 - 恢复数据不能只写
UPDATE users SET is_deleted = 0 WHERE id = 123，得先校验原记录是否存在且当前is_deleted = 1，否则可能覆盖刚插入的新数据
什么时候该用物理删除，什么时候必须逻辑删除
没有银弹，关键看数据价值和系统约束：
- 物理删除适用场景：
log表、tmp_*临时表、调试用测试数据——这些数据无业务意义，占空间，且无需审计 - 逻辑删除强制场景：订单、用户、合同、审批流节点——涉及财务对账、监管审计、运营复盘，删了就得能还原
- 中间态方案：物理删除 + 归档到历史表（如
orders_archive），既释放主表空间，又保留原始记录；但归档需额外开发，且跨表查询变复杂
最常被忽略的一点：逻辑删除后，COUNT(*) 和 COUNT(is_deleted) 含义完全不同，统计“有效数据量”必须写 COUNT(*) WHERE is_deleted = 0，而不是依赖视图或默认聚合。
