MySQL监控需确保performance_schema启用并配置关键instruments、创建最小权限专用账号、匹配mysqld_exporter与MySQL协议版本及TLS设置、合理配置慢查询阈值，缺一不可。
监控平台里搭 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 的开关粒度、账号权限的实际生效范围、以及协议兼容性这些「看不见的握手细节」。漏掉任意一项，都会让指标看起来「连上了」，却始终缺关键维度。
