只设 read_only = ON 不等于数据库真正只读，因该参数默认仅限制非 SUPER 用户，root 等高权限账号仍可执行写操作；真正全局只读必须启用 super_read_only = ON（MySQL 5.7.20+），它自动设 read_only = ON 并禁止所有用户（含 SUPER）的 DML/DDL 操作，且需通过 SET PERSIST 或配置文件持久化。
只设 read_only = ON 不等于数据库真正只读，普通用户确实被拦住，但 root 或任何带 SUPER 权限的账号照常能删表、改数据——这不是配置失败，是 MySQL 的设计行为。
为什么 read_only = ON 后 root 还能写？
因为 read_only 仅限制非 SUPER 用户。运维用 root 登录后执行 SET GLOBAL read_only = ON，自己仍可执行 INSERT、DROP TABLE，监控脚本若也用高权限账号连库，照样可能污染从库。
- 验证当前连接权限：
SELECT CURRENT_USER(), USER();+SHOW GRANTS FOR CURRENT_USER();，重点看是否含SUPER或SYSTEM_VARIABLES_ADMIN -
read_only对已存在连接无效，只影响新连接；重启后失效，除非写入配置文件或用SET PERSIST - 云数据库（如阿里云 RDS）可能禁用该变量，需通过控制台开关，
my.cnf修改无效
真正全局只读必须开 super_read_only = ON
super_read_only 是 MySQL 5.7.20+ 才支持的开关，它自动启用 read_only，并禁止所有用户（含 SUPER）执行写操作，包括 ANALYZE TABLE、OPTIMIZE TABLE —— 因为它们会更新系统表。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 动态启用（需
SUPER权限）：SET GLOBAL super_read_only = ON;（注意：必须先确保read_only = ON，否则会静默失败） - 持久化推荐方式（避免重启丢失）：
SET PERSIST super_read_only = ON;（MySQL 8.0.22+），值写入mysqld-auto.cnf，优先级高于my.cnf - 关闭时必须先关它：
SET GLOBAL super_read_only = OFF;，否则SET GLOBAL read_only = OFF会直接报错ERROR 1290
账号级只读不能靠 read_only 代替
read_only 和 super_read_only 是实例级开关，和账号权限完全解耦。即使开了 super_read_only，如果应用仍用高权限账号连接，后续权限变更（如回收 SUPER）就失去意义；更常见的是，只授 SELECT 却漏掉显式回收 LOCK TABLES，导致 FLUSH TABLES WITH READ LOCK 阻塞复制线程。
- 创建账号必须拆开：
CREATE USER 'ro_app'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'pwd';，再GRANT USAGE ON *.*（缺这句会Access denied） - 只读授权要明确：
GRANT SELECT ON `app_db`.* TO 'ro_app'@'192.168.10.%';，如需查结构，补GRANT SELECT ON `information_schema`.`TABLES` - 必须显式回收隐式权限：
REVOKE LOCK TABLES, CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, EXECUTE ON *.* FROM 'ro_app'@'192.168.10.%'; - 云只读实例（如 RDS 只读节点）的账号需单独初始化，主库上
CREATE USER不会同步过去
验证只读是否真生效，别只看变量值
SELECT @@global.read_only, @@global.super_read_only; 返回 ON 只说明开关开了，不代表安全。真正验证得用实际账号执行写操作，并确认错误类型是 ERROR 1290 而不是权限拒绝类错误（如 ERROR 1142）。
- 用业务账号连从库，执行
INSERT INTO t VALUES (1);，应报ERROR 1290 - 用 root 连，同样执行，也应报
ERROR 1290（开super_read_only后） - 检查
SHOW SLAVE STATUS\G中SQL_Running: Yes和Seconds_Behind_Master是否稳定，排除LOCK TABLES类操作干扰复制 - 临时表（
CREATE TEMPORARY TABLE）和日志清理（PURGE BINARY LOGS）不受read_only限制，需单独管控
最易被忽略的点：权限变更对已有连接不生效，旧连接仍持有旧权限快照；super_read_only 开启后，连 SET GLOBAL 自身都会被拒，调试时容易卡住。
