软删除字段设计是通过添加deleted标志位（0为正常、1为逻辑删除）实现数据标记而非物理删除，需建索引、默认值设为0、所有查询/关联/更新操作显式过滤deleted=0，视图或ORM可封装但无法替代手动条件。

什么是软删除字段设计 软删除不是真正删掉数据，而是用一个标志位标记“已删除”状态。最常见做法是加一个 deleted 字段（类型通常为 TINYINT(1) 或 BOOLEAN），值为 0 表示正常，1 表示逻辑删除。

• 字段名不建议叫 is_deleted 或 deleted_at（除非业务明确需要记录时间）；统一用 deleted 更利于后续自动过滤逻辑复用
• 必须为该字段加索引，否则带 WHERE deleted = 0 的查询可能全表扫描
• 不要设默认值为 1，新插入数据必须默认 0，否则写入即“不可见”

手动 WHERE 过滤 deleted=0 是最直接方式 几乎所有 SQL 场景下，你都需要显式加条件：WHERE deleted = 0。它简单、可控、无隐式行为风险。

• 查询用户列表：SELECT * FROM users WHERE deleted = 0
• 关联查询时，每个被 JOIN 的主表都要加该条件，例如：SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.deleted = 0 AND o.deleted = 0
• UPDATE / DELETE 操作也需主动排除已软删除行，比如恢复某条记录：UPDATE users SET deleted = 0 WHERE id = 123 AND deleted = 1
• 错误示范：漏写 WHERE deleted = 0 导致前端展示“已删除”的脏数据

视图封装可减少重复 WHERE 条件 如果你在多个地方反复写 WHERE deleted = 0，可以建一个只读视图来收敛逻辑：

CREATE VIEW active_users AS
SELECT id, name, email, created_at
FROM users
WHERE deleted = 0;

• 视图里不能包含 *（防止底层加字段后视图失效），必须显式列出字段
• 视图无法替代应用层校验：INSERT/UPDATE 仍需业务代码控制 deleted 值
• 某些 ORM（如 Laravel Eloquent）的全局作用域或 Django 的 Manager 本质也是类似思路——但它们运行在应用层，不是数据库层

触发器或存储过程不能替代 WHERE 过滤 有人想用触发器自动把 deleted = 1 的行从 SELECT 结果里剔除，这是行不通的。

• MySQL / PostgreSQL 不支持 SELECT 触发器
• 即便通过函数包装查询（如 SELECT * FROM get_active_users()），也会让 SQL 变得难以调试、ORM 难以适配、执行计划不稳定
• 最容易被忽略的一点：软删除的“自动过滤”永远不可能 100% 透明。只要用了 JOIN、子查询、UNION 或窗口函数，deleted 状态就必须由开发者显式判断和处理

别指望数据库替你记住哪些表要过滤。每个涉及软删除的表，每次查询，都得自己写 WHERE deleted = 0——少写一次，就可能出一次生产问题。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载