MySQL创建只读用户需避免SELECT全局授权、禁用SHOW DATABASES/PROCESS权限、仅对审计所需库表授SELECT权、强制REQUIRE SSL加密连接、用ALTER USER替代GRANT+FLUSH PRIVILEGES确保权限实时生效。
mysql创建只读用户要绕开SELECT权限的常见误区
MySQL 的“只读”不是靠禁止INSERT/UPDATE就能实现的，核心在于权限粒度控制。很多审计人员被授予SELECT权限后，仍能执行SHOW CREATE TABLE、SHOW INDEX甚至INFORMATION_SCHEMA查询——这些操作本身不修改数据，但可能暴露敏感结构或元数据。
实操建议：
- 不要用
GRANT SELECT ON *.*，这会让用户看到所有库名、表名、列类型，审计场景下属于信息泄露 - 只对审计必需的库显式授权：
GRANT SELECT ON `audit_log_db`.* TO 'auditor'@'%' - 禁用
PROCESS和SHOW DATABASES权限，否则SHOW DATABASES会列出所有库名 - 确认
sql_mode中不含NO_AUTO_CREATE_USER（旧版本需注意），避免CREATE USER语句静默失败
审计需要的全局权限其实只有AUDIT_ADMIN和SELECT日志表
MySQL 8.0+ 内置审计日志（如mysql.audit_log插件）或企业版 Audit Log 不依赖普通用户权限，但审计人员要查日志，得有对应表的SELECT权。关键点是：没有“全局只读”权限，只有“对特定日志表只读”。
实操建议：
- 启用
audit_log插件后，日志默认写入文件，不进数据库；若用audit_log_filter_linux等第三方方案，日志才存表，此时才需授SELECT权 - 若使用
performance_schema做行为审计（如查events_statements_history_long），必须授SELECTonperformance_schema，但该库默认对普通用户不可见，需显式授权 -
AUDIT_ADMIN权限仅用于管理审计规则（如加载过滤器），审计人员不需要它，也不该给——它可停用/重载审计插件
用REQUIRE SSL强制加密连接防中间人窃听审计流量
审计用户查的是原始SQL和用户行为，一旦明文传输，攻击者截获连接就能拿到完整操作记录。MySQL 默认不加密，REQUIRE SSL不是可选项，是审计合规的基本要求。
实操建议：
- 创建用户时必须加
REQUIRE SSL：CREATE USER 'auditor'@'%' IDENTIFIED BY 'xxx' REQUIRE SSL - 检查服务器是否启用了SSL：
SHOW VARIABLES LIKE 'have_ssl';返回YES才算生效；若为DISABLED，需配置ssl_ca、ssl_cert、ssl_key - 客户端连接时不能省略
--ssl-mode=REQUIRED，否则即使服务端要求SSL，客户端也可能降级到非加密连接
权限变更后必须FLUSH PRIVILEGES，但更推荐用ALTER USER避免缓存问题
直接改mysql.user表或用GRANT后不刷新，权限不会实时生效；而FLUSH PRIVILEGES在某些高并发场景下有短暂窗口期，导致权限状态不一致。
实操建议：
- 优先用
ALTER USER 'auditor'@'%' REQUIRE SSL;代替UPDATE mysql.user，它自动触发权限重载 - 如果必须用
GRANT，执行完立刻跟FLUSH PRIVILEGES;，不要依赖连接复用或等待后台同步 - 验证权限是否生效：用审计用户登录后执行
SELECT USER(), CURRENT_USER();，确认匹配预期的host和认证方式；再试SELECT 1 FROM performance_schema.events_statements_current LIMIT 1;看是否报Access denied
真正难的不是建用户，而是确保每次权限变更都覆盖到所有节点（主从架构下从库不自动同步权限表）、且SSL证书没过期——这两点一漏，审计链就断了。
