SQL 如何降低人为操作风险？

应显式设置事务隔离级别为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 条件单独抽成变量或注释块，方便复核：“// 注意：仅处理 2025 年前注册且未登录的用户”
• 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 条件，在某天凌晨因统计信息过期，让优化器选错执行计划，结果锁住整张表三分钟。这类风险没法靠单条规则堵死，得靠执行前看执行计划、小流量验证、以及留好回滚窗口。