必须显式授予select并补usage权限、分步创建用户与授权、主动撤销lock tables/super等隐式写权限，mysql 8.0+需逐库授权且验证insert失败而select成功。
只读账号必须显式授予 SELECT，不能靠“不给写权限”来凑
MySQL 的权限模型不是“默认全拒、只开 SELECT 就安全”，而是“未显式授予即无权，但某些隐式权限可能绕过限制”。比如 LOCK TABLES 或 SUPER 权限能让用户绕过只读状态（如执行 SET SESSION read_only = 0）。所以只读 ≠ 不授 INSERT/UPDATE/DELETE，而是必须：
• 显式执行 GRANT SELECT ON db_name.* TO 'user'@'host'
• 显式执行 GRANT USAGE ON *.* TO 'user'@'host'（否则连不上）
• 主动回收高危权限，尤其在旧版本或复制环境中残留的权限
MySQL 8.0+ 必须分两步：先 CREATE USER，再 GRANT
这条语句在 MySQL 8.0+ 会直接报错：GRANT SELECT ON app_db.* TO 'ro'@'%' IDENTIFIED BY 'pwd' → ERROR 1064 (42000)。正确流程是：
- 用
CREATE USER创建账号，推荐指定认证插件：CREATE USER 'ro_app'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'StrongPass!2026' - 再单独授权：
GRANT SELECT ON `app_db`.* TO 'ro_app'@'192.168.10.%' - 跨库只读要逐条授权：
GRANT SELECT ON `log_db`.* TO 'ro_app'@'192.168.10.%' - 别漏掉
USAGE：GRANT USAGE ON *.* TO 'ro_app'@'192.168.10.%'（否则连接时提示 Access denied）
必须主动 REVOKE 隐式写权限，尤其是 LOCK TABLES 和 SUPER
即使你没手动授过，某些初始化脚本、复制配置或历史遗留权限可能让账号拥有绕过只读的能力。安全起见，执行：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, INDEX, LOCK TABLES, CREATE VIEW, SHOW VIEW, TRIGGER, EXECUTE ON *.* FROM 'ro_app'@'192.168.10.%'REVOKE SUPER, REPLICATION CLIENT, REPLICATION SLAVE ON *.* FROM 'ro_app'@'192.168.10.%'- 注意：
LOCK TABLES是重点——它允许用户加读锁后执行非事务性写操作，常被忽略
验证时别只看 SHOW GRANTS，要真连上去试 INSERT 和 SELECT
SHOW GRANTS FOR 'ro_app'@'192.168.10.%' 输出只有 SELECT 行还不够。真实验证步骤是：
- 用该账号连接：
mysql -u ro_app -p -h your-db-host - 执行
SELECT COUNT(*) FROM app_db.users→ 应成功 - 执行
INSERT INTO app_db.users(name) VALUES('test')→ 必须报错ERROR 1142 (42000): INSERT command denied - 执行
SELECT * FROM information_schema.TABLES LIMIT 1→ 如果失败，说明没暴露系统库；如果成功，需额外授权：GRANT SELECT ON information_schema.TABLES TO 'ro_app'@'192.168.10.%'（MySQL 8.0+ 默认禁用）
真正麻烦的不是命令怎么写，而是权限链里哪个环节悄悄开了后门——比如一个被遗忘的 REPLICATION SLAVE 权限，就能让只读账号执行 CHANGE MASTER TO 并间接触发写操作。
