监控mysql账户必须且仅需select、process、replication client三项权限：select用于查询information_schema和performance_schema统计表，process用于show processlist获取全部会话，replication client用于show slave status等复制状态。
监控账户需要哪些权限，缺一不可
MySQL监控账号（比如 mysqld_exporter、Zabbix agent 或自研采集脚本）不是“只读”那么简单。它必须能获取运行时状态、复制拓扑、连接数、锁等待等指标，但又不能具备任何写能力或跨库发现能力。
核心权限只有三个：SELECT、PROCESS、REPLICATION CLIENT。少一个都可能让监控断点或报错：
-
SELECT：用于查information_schema、performance_schema中的统计表（如processlist、table_io_waits_summary_by_table） -
PROCESS：执行SHOW PROCESSLIST，否则只能看到自己的会话（默认行为），无法识别慢查询或阻塞线程 -
REPLICATION CLIENT：读取主从状态（SHOW SLAVE STATUS、SHOW MASTER STATUS），没有它就看不到复制延迟
注意：SHOW DATABASES 不是必需项，且存在信息泄露风险——一旦给了，监控账号就能列出所有库名，违背最小权限原则。
为什么直接用 SHOW GRANTS 导出再执行会失败
迁移后若直接在新实例上执行源库导出的 SHOW GRANTS FOR 'monitor'@'10.0.0.11' 结果，大概率报错，常见原因有：
- 目标库尚未创建该用户：
ERROR 1133 (HY000): Can't find any matching row in the user table - 主机名不匹配：源库是
'monitor'@'10.0.0.11'，但新环境监控服务跑在容器内，实际 IP 是172.18.0.5，或用了域名但 DNS 未同步 - 密码字段不兼容：MySQL 8.0+ 使用
authentication_string字段，而旧导出脚本可能还依赖已弃用的password字段 - 系统库权限被隐式继承：老版本导出语句含
ON *.*，但在 8.0.29+ 上需显式回收information_schema权限，否则REVOKE SELECT ON *.*会失败
别信“一键迁移权限”脚本。监控账号权限必须手写重建，确保每条 GRANT 都精确到库表级或全局级，且不含 WITH GRANT OPTION。
正确重建监控账号的四步操作顺序
顺序错了就会卡住，尤其在 MySQL 8.0+ 环境下：
- 先用
CREATE USER创建账号（显式指定认证插件，如mysql_native_password，避免默认caching_sha2_password导致客户端连不上） - 再用
GRANT分别授权：SELECT和PROCESS只需ON *.*；REPLICATION CLIENT也必须是ON *.*（它不支持库级限制） - 立即执行
REVOKE SELECT ON information_schema.* FROM 'monitor'@'host'和REVOKE SELECT ON performance_schema.* FROM 'monitor'@'host'—— 否则该账号仍能遍历所有库名和表结构 - 最后验证：用该账号登录后执行
SHOW PROCESSLIST、SHOW SLAVE STATUS、SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest LIMIT 1，三项全通才算到位
特别注意：FLUSH PRIVILEGES 在 8.0+ 中对普通权限变更已非必需（GRANT 自动持久化），但它对 REVOKE 系统库权限后生效是必要的——漏掉这步，REVOKE 不会立刻起效。
容易被忽略的兼容性细节
监控账号看似简单，但跨版本迁移时几个细节极易翻车：
- MySQL 8.0.29+ 默认开启元数据可见性控制（
show_compatibility_56=OFF），但若目标实例仍为 8.0.28 或更低，REVOKE SELECT ON information_schema.*会报错Access denied; you need (at least one of) the SUPER privilege(s)—— 此时必须用 root 执行，且确认 root 有SUPER权限 - 如果监控工具依赖
INFORMATION_SCHEMA.INNODB_TRX查事务，而你已REVOKE了information_schema，就得单独补一条：GRANT SELECT ON information_schema.INNODB_TRX TO 'monitor'@'host' - 容器化部署时，
'monitor'@'10.0.0.11'往往无效，应改为'monitor'@'%'并配合max_user_connections=3限流，或改用'monitor'@'172.%'白名单网段
真正麻烦的从来不是“授什么权”，而是“撤掉不该有的权”。迁移后第一件事不是加权限，而是检查 information_schema 和 performance_schema 是否已被显式收回——这点绝大多数人会跳过。
