管理权限（如SUPER、RELOAD）与数据权限混用违反最小权限原则；前者控制服务器行为（如KILL、FLUSH），后者仅限数据操作；业务账号持有管理权限将导致高危误操作风险，如STOP SLAVE或SET GLOBAL拖垮实例。
管理权限（如 SUPER、RELOAD）和数据权限（如 SELECT、INSERT）混用会直接破坏最小权限原则
MySQL 的管理类权限不作用于具体数据，而是控制服务器行为本身。比如 SUPER 允许用户执行 KILL、SET GLOBAL、关闭复制线程；RELOAD 可触发 FLUSH PRIVILEGES 或清空查询缓存。一旦这些权限被业务账号持有，就等于把数据库“开关”交给了应用——某次误配参数或自动脚本调用 SET GLOBAL innodb_buffer_pool_size 就可能拖垮整套实例。
读写账号被授予 SUPER 权限后，主从复制可能瞬间中断
真实线上故障中，常见场景是应用账号拥有 SUPER 权限，在连接从库时执行了 STOP SLAVE（MySQL 8.0+ 中 SUPER 隐式包含该能力）。结果就是：主库照常写入，从库停止同步，延迟持续累积，直到人工介入。更隐蔽的是，某些 ORM 框架在连接初始化阶段会尝试探测服务状态，自动执行类似语句，而你根本没在代码里写过它。
-
REVOKE SUPER ON *.* FROM 'app_rw'@'192.168.10.50'必须显式执行，不能依赖“创建时没给就默认没有” - MySQL 8.0+ 默认角色（如
mysql.session）可能携带管理权限，需检查SELECT * FROM mysql.role_edges - 中间件（如 ProxySQL、ShardingSphere）若配置了全局管理账号，也要确保其连接池使用的不是业务账号
只读账号即使只有 SELECT 权限，也可能因隐式继承获得写能力
权限不是靠“没给什么”来保证安全，而是靠“明确撤销了什么”。SELECT 权限本身不排斥写操作；如果账号通过 mysql.role_edges 继承了高权限角色，或旧账号残留了未清理的 INSERT 权限，它就能执行 DROP TABLE。2025 年某金融系统事故就是只读报表账号删掉了核心交易表，根源正是没做 REVOKE LOCK TABLES —— 这个权限允许阻塞读操作，间接破坏读写分离语义。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 创建只读账号必须走三步：
DROP USER→CREATE USER→GRANT SELECT→REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, INDEX, LOCK TABLES - 主机段禁用通配符：
'app_ro'@'192.168.10.%'可接受，'app_ro'@'%'不可接受 -
FLUSH PRIVILEGES不是可选操作，尤其在跳过 grant 表启动或权限表手动修改后，必须执行
权限分离不到位，会让审计和故障归因失效
当所有操作都由一个高权限账号完成，日志里只会看到 “user@host 执行了 DROP”，无法区分是运维误操作、应用 Bug 还是恶意行为。而分离后，app_rw 账号只能改数据，dba_admin 账号才能调参或重启，audit_reader 账号仅能查 performance_schema 和慢日志——每类行为对应唯一身份，链路清晰。这点在金融、医疗等强合规场景中不是优化项，而是准入硬要求。
最易被忽略的是权限表不同步问题：MySQL 主从复制默认不复制 mysql 库，你在主库上 REVOKE SUPER，从库不会自动生效。所以读写分离架构下，每个节点的权限必须单独维护，不能只在主库操作完就认为万事大吉。
