仅靠SET GLOBAL read_only = ON不够，因开发账号常具SUPER权限（如本地root），read_only对其无效；且可通过CREATE TEMPORARY TABLE、SET SESSION等绕过限制，甚至执行DROP DATABASE mysql等高危操作。
开发环境必须隔离、只读、库级精确控制——仅靠 read_only 不够，必须组合用户权限 + 实例级只读 + 显式撤销高危权限。
为什么不能只用 SET GLOBAL read_only = ON
因为开发账号往往有 SUPER 权限（如本地 root 或 docker 默认 root），read_only 对其完全无效；即使没 SUPER，只要账号能连上实例，就可能通过 CREATE TEMPORARY TABLE、SET SESSION 或触发器绕过限制。更危险的是：开发人员可能误执行 DROP DATABASE mysql 或修改系统表——这些操作在 read_only=ON 下仍可能成功。
创建限定主机+指定库的只读用户（最小权限）
这是第一道防线，也是最可控的一层：
- 用具体 IP 或网段代替
'%'，例如开发机固定在192.168.50.0/24，就写'dev_user'@'192.168.50.%' - 只对目标库授权：
GRANT SELECT ON app_production.* TO 'dev_user'@'192.168.50.%';（注意不是*.*） - 显式撤销所有写权限：
REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, INDEX, LOCK TABLES, EXECUTE ON *.* FROM 'dev_user'@'192.168.50.%'; - 关键一步：撤销
SUPER和REPLICATION CLIENT：REVOKE SUPER, REPLICATION CLIENT ON *.* FROM 'dev_user'@'192.168.50.%';，否则可通过SET sql_log_bin=0绕过 - 执行
FLUSH PRIVILEGES;立即生效
在从库实例上启用 super_read_only（防特权绕过）
开发环境通常连的是主库的副本（比如 mysqldump 导出的静态库，或基于 GTID 的延迟从库）。此时必须确保实例本身不可写：
- 确认 MySQL 版本 ≥ 5.7.8，否则
super_read_only不可用 - 在
my.cnf的[mysqld]段下写死：read_only = ON和super_read_only = ON（顺序无关，但二者必须同时存在） - 重启生效后验证：
SELECT @@global.read_only, @@global.super_read_only;返回两个1才算到位 - 不要依赖
SET GLOBAL临时设置——开发环境重启频繁，配置文件才是唯一可靠方式
额外加固：禁用 innodb_read_only（仅适用于只读介质部署）
如果开发环境是挂载只读 NFS、CD/DVD 镜像或容器只读 volume，可进一步启用 innodb_read_only：
- 它是静态参数，只能在启动时设置：
mysqld --innodb-read-only=1 --pid-file=/tmp/mysql.pid --innodb-temp-data-file-path=../tmp/ibtmp1:12M:autoextend - 启用后，连
CREATE USER、GRANT、INSTALL PLUGIN都会失败（报错ERROR 1836 (HY000): Running in read-only mode） - 副作用明显：无法动态增删用户、无法装插件、无法执行
ANALYZE TABLE，仅适合完全冻结的离线分析库 - 日常开发环境不推荐，除非你明确需要“只读介质级防护”
真正难的不是加锁，而是判断哪些权限该留、哪些必须砍——比如 SHOW VIEW 是否允许？PROCESS 权限要不要开？这些得看开发是否真需要查慢日志或视图定义。别一上来就全关，先观察报错再收紧。
