监控平台里搭 MySQL 环境，不是装个数据库就完事——重点是让监控系统能稳定连、持续采、不丢数据。直接用默认配置或跳过权限/网络校验，90% 的后续「采集失败」「连接超时」「指标断更」都源于这一步没踩实。
MySQL 实例必须开启 performance_schema 且启用关键 instruments
很多监控系统（如 Prometheus + mysqld_exporter、Zabbix、夜莺）依赖
performance_schema获取锁等待、语句执行耗时、内存分配等实时指标。它默认开启，但部分 instruments 是关闭的，导致 exporter 查不到数据。 确认已启用：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema';—— 返回
ON关键 instruments 至少要开：
events_statements_history_long、
events_waits_history_long、
table_io_waits_summary_by_table（否则看不到慢查询和表级 IO） 临时启用（重启前有效）：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'instrument/%';永久生效需在
my.cnf加：
performance_schema=ON和
performance_schema_consumer_events_statements_current=ON等对应 consumer 配置
监控账号必须最小权限 + 显式 host 限制
用
root@'%'或空密码账号给 exporter 连，等于把数据库大门钥匙贴在监控大屏上。实际部署中，权限过大反而触发某些安全中间件拦截，导致连接被静默拒绝。 创建专用账号：
CREATE USER 'monitor'@'192.168.10.%' IDENTIFIED BY 'xxx';（host 写监控服务器真实网段，不用
%） 只赋必要权限：
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'monitor'@'192.168.10.%';（
PROCESS查线程，
REPLICATION CLIENT查主从状态） 如果要用
performance_schema指标，额外加：
GRANT SELECT ON performance_schema.* TO 'monitor'@'192.168.10.%';禁止使用
GRANT ALL或
mysql.user表直写 —— 权限变更后记得
FLUSH PRIVILEGES;
mysqld_exporter 启动时必须匹配 MySQL 协议版本与 TLS 设置
MySQL 8.0 默认用
caching_sha2_password插件，而老版本
mysqld_exporter（v0.12.x 及之前）只支持
mysql_native_password，一连就报
plugin caching_sha2_password is not loaded或
Access denied for user。 检查 MySQL 认证插件：
SELECT host, user, plugin FROM mysql.user WHERE user='monitor';若为
caching_sha2_password，降级账号（临时方案）：
ALTER USER 'monitor'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'xxx';更稳妥：升级
mysqld_exporter到 v0.14.0+，并启动时加参数：
--web.listen-address=":9104" --config.my-cnf="/etc/exporter.cnf"，其中
/etc/exporter.cnf显式指定
default-auth=mysql_native_password或启用 TLS 若 MySQL 开了
require_secure_transport=ON，exporter 必须配
--tls.cert-file等参数，否则连不上
实时数据处理卡在「延迟高」或「采样丢失」？先看 MySQL 的 long_query_time 和 slow_query_log
监控系统本身不处理慢查询，但它依赖 slow log 解析出执行计划和耗时分布。如果
long_query_time设成 10 秒，而业务平均响应 800ms，那 95% 的「准慢查询」根本进不了日志，监控看到的永远是「无慢查」假象。 调低阈值（生产建议 0.5～2 秒）：
SET GLOBAL long_query_time = 0.5;（注意：该变量对新连接生效，旧连接需重连） 确保开启：
SET GLOBAL slow_query_log = ON;，日志路径由
slow_query_log_file控制，别指向 /tmp（可能被清理） mysqld_exporter 不直接读 slow log，而是靠
information_schema.PROCESSLIST或
performance_schema.events_statements_summary_by_digest聚合 —— 所以更要确认后者已启用（见第一个副标题） 如果发现 exporter 抓到的语句 digest 数量远低于
SHOW PROCESSLIST中活跃数，大概率是
events_statements_history_long的
MAX_STATEMENT_TIME或内存限制太小，需调大
performance_schema_max_sql_text_length
真正卡住监控数据流的，往往不是 exporter 配置，而是 MySQL 自身 instrumentation 的开关粒度、账号权限的实际生效范围、以及协议兼容性这些「看不见的握手细节」。漏掉任意一项，都会让指标看起来「连上了」，却始终缺关键维度。
