set global sql_safe_updates = 1仅对后续新建连接生效，当前会话不受影响，且需super权限；普通账号执行报错error 1227，必须单独执行set sql_safe_updates = 1才作用于当前会话，并通过select @@sql_safe_updates和select @@global.sql_safe_updates双验证确认生效。
SET GLOBAL sql_safe_updates = 1 能生效，但仅对**后续新建连接**有效，当前会话不受影响；且必须拥有 SUPER 权限，普通开发账号执行会报错 ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s)。
为什么 SET GLOBAL 不立即保护你的当前操作
全局设置只改变新会话的默认值，不触发现有连接的变量重载。你执行完 SET GLOBAL sql_safe_updates = 1 后，当前终端里的 SELECT @@sql_safe_updates 仍返回 0 —— 它还是会话级变量，得单独再执行一次 SET sql_safe_updates = 1 才管用。
常见误操作：
- 以为设了 GLOBAL 就一劳永逸，结果接着在同一个 shell 里删数据，照样没拦住
- 用普通账号（如
dev）执行SET GLOBAL，直接被拒绝，但错误提示没说清楚缺什么权限 - 设完没验证：连上新终端后不查
SELECT @@sql_safe_updates，误以为已开启
如何确认 GLOBAL 设置真正落地
光执行 SET GLOBAL 不够，必须分三步验证：
- 执行
SET GLOBAL sql_safe_updates = 1（需 root 或 SUPER 权限） - 断开当前连接，新开一个 mysql 终端（或用
mysql -u... --safe-updates重连） - 运行
SELECT @@sql_safe_updates，输出必须是1；再执行SELECT @@global.sql_safe_updates确认全局值也是1
注意：@@sql_safe_updates 查的是当前会话值，@@global.sql_safe_updates 才反映 GLOBAL 设置是否写入成功。两者都为 1 才算稳。
SET GLOBAL 在不同客户端下的兼容性差异
不是所有工具都会尊重 MySQL 服务端的 GLOBAL 设置：
- 原生命令行
mysql工具：默认继承，只要 GLOBAL 设对，新连接就自动开启 - Navicat / DBeaver / JDBC 连接池：多数**忽略** GLOBAL 值，仍按自己默认行为走；它们更依赖连接字符串参数（如
?useSSL=false&allowPublicKeyRetrieval=true）或驱动配置 - 某些 ORM（如 Django 的
django.db.connection）初始化时可能显式关闭 safe mode，覆盖服务端设置
所以别只信 SHOW VARIABLES LIKE 'sql_safe_updates' 的返回值——得在目标客户端里实际跑一条无 WHERE 的 UPDATE，看是否真报 ERROR 1175。
生产环境慎用 SET GLOBAL 的真实原因
它看似一劳永逸，但存在两个硬伤：
- MySQL 重启后失效（除非配合
init_connect或配置文件固化） - root 用户的新连接虽然继承，但其他用户（如应用账号）若通过连接池复用旧连接，仍可能绕过防护
真正防住误删，靠的不是某次 SET GLOBAL，而是把 init_connect='SET sql_safe_updates=1;' 写进 [mysqld] 段，并确保所有应用连接都走标准协议——否则，安全模式只是纸面开关。
