应显式设置事务隔离级别为REPEATABLE READ以保证可重复读；禁止READ UNCOMMITTED避免脏读；修改操作前必须先SELECT验证条件，禁用无WHERE的DELETE/UPDATE。
用 SET TRANSACTION ISOLATION LEVEL 控制读写干扰
多人同时操作同一张表时，SELECT 可能读到未提交的脏数据，或因其他事务正在更新而阻塞。这不是权限问题，是隔离级别没设对。
-
开发环境默认常为
READ COMMITTED，但若业务逻辑依赖“可重复读”，比如两次SELECT之间不能有中间变更，就得显式设成REPEATABLE READ - 避免用
READ UNCOMMITTED——哪怕只为了“快”，它会让SELECT返回回滚前的临时值，线上查账、导出报表时极易出错 - 在事务开头第一句就写
SET TRANSACTION ISOLATION LEVEL ...，不要依赖客户端连接池的全局配置，不同模块可能有冲突
禁止直接 DELETE 或 UPDATE 不带 WHERE 条件
这类语句一旦执行，没有回收机制。MySQL 的 autocommit=1 默认开启，PostgreSQL 也默认自动提交单条语句。
- 所有修改类语句必须先写
SELECT验证条件：比如要删用户，先跑SELECT id, name FROM users WHERE status = 'inactive' AND created_at 看数量和样本 - 把
WHERE条件单独抽成变量或注释块，方便复核：“// 注意：仅处理 2023 年前注册且未登录的用户” - DBA 可通过触发器或代理层拦截无
WHERE的DELETE/UPDATE，但更可靠的是流程卡点——比如运维平台要求粘贴SELECT结果截图才能提交工单
用 WITH CHECK OPTION 限制视图写入范围
给运营或数据分析人员开放部分数据权限时，常建视图。但若不加约束，他们通过视图 INSERT/UPDATE 可能突破原始定义的行级过滤条件。
- 创建视图时务必加上
WITH CHECK OPTION，例如：CREATE VIEW active_users AS SELECT * FROM users WHERE status = 'active' WITH CHECK OPTION; - 这样即使有人执行
INSERT INTO active_users (status) VALUES ('inactive');，数据库也会报错new row violates check option for view - 注意 PostgreSQL 支持
CASCADED和LOCAL两种模式；MySQL 只支持CASCADED（默认），嵌套视图下检查更严格
用 pg_dump --inserts 或 mysqldump --skip-extended-insert 生成可审计的 SQL
备份恢复脚本如果全是批量 INSERT INTO ... VALUES (...),(...),(...)，出问题时很难定位哪一行坏了，也没法加条件跳过某条记录。
- 导出时强制单行插入：MySQL 用
mysqldump --skip-extended-insert，PostgreSQL 用pg_dump --inserts - 这类输出天然带行号，配合
grep -n快速定位异常数据；也能用sed -n '123,125p'精确重放某几行 - 别省略
--no-create-info或--no-tablespaces等开关——它们会混入 DDL，导致在只想要 DML 的场景下误删表结构
真正难防的不是语法错误，是“看起来完全合理”的语句在特定数据分布下引发连锁反应。比如一个加了索引的 WHERE 条件，在某天凌晨因统计信息过期，让优化器选错执行计划，结果锁住整张表三分钟。这类风险没法靠单条规则堵死，得靠执行前看执行计划、小流量验证、以及留好回滚窗口。
