运行监控与维护

MySQL 运维应从服务目标出发：连接是否可建立、事务是否及时完成、持久化链路是否健康、空间是否充足、Replica 是否追平。单个 CPU 或 QPS 指标不能独立说明数据库状态。

---

可观测来源

来源	作用
Performance Schema	等待、语句、事务、锁、I/O、内存和复制等运行事件
sys Schema	对 Performance Schema 和 Information Schema 的常用聚合视图
Information Schema	Schema、InnoDB 事务和对象元数据
Error Log	启停、崩溃恢复、复制、认证和内部错误
Slow Query Log	超过阈值或满足配置条件的语句
Binary Log	数据变化、复制和 PITR，不是普通查询审计日志

旧版 SHOW PROFILE 已废弃并在现代版本移除。语句性能应使用 Performance Schema、sys Schema 和 EXPLAIN ANALYZE 分析。

---

核心指标

领域	重点观察
连接	当前/峰值连接、拒绝、线程创建、连接池等待
SQL	延迟分位数、扫描行、返回行、临时表、排序和错误率
InnoDB	Buffer Pool、Dirty Page、Redo、Checkpoint、History List
锁	Lock Wait、Deadlock、MDL 阻塞链和长事务
存储	Data、Undo、Redo、Temp、Binlog、磁盘延迟和剩余空间
复制	Source/Replica 连接、Apply Lag、GTID 差距和错误

平均延迟会掩盖尾部阻塞，应同时记录 P95/P99 和最大值。数据库层指标还需关联应用请求、连接池和主机 I/O。

---

慢 SQL 分析

SELECT *
FROM sys.statement_analysis
ORDER BY total_latency DESC
LIMIT 20;

处理顺序：

1. 按总资源或尾延迟识别真正影响业务的 Digest。
2. 获取完整 SQL、参数分布和执行频率。
3. 用 EXPLAIN ANALYZE 核对估算与实际执行。
4. 判断是索引、统计、查询结构、数据模型还是资源争用。
5. 在代表性数据上验证修改，并观察写入和复制副作用。

慢日志的 long_query_time 需要结合业务 SLO 设置。记录所有未用索引语句可能制造大量噪声，因为小表全扫或高返回比例查询本来就可能不需要索引。

---

容量与维护

• Data Directory、独立表空间、Undo、Redo、Temp 和 Binlog 分别设置告警。
• 大表 DDL 前确认额外临时空间、Algorithm、Lock、复制延迟和回滚方案。
• Binary Log 使用 MySQL 命令按保留策略清理，不直接删除文件。
• 统计信息在数据分布明显变化后按需更新，避免无计划全库高峰 ANALYZE。
• 升级先检查目标版本支持路径、认证插件、Collation 和弃用功能，并进行回滚演练。

---

权限与安全

• 应用账号只授予需要的 Schema 与操作权限，不使用 Root。
• 管理入口限制网络范围并启用 TLS。
• 密码、证书和 Keyring 不写入普通笔记、脚本或命令历史。
• 审计与日志设置保留周期，避免敏感参数直接进入日志。
• read_only 不能防止所有高权限账号写入，Replica 还应结合 super_read_only 和代理路由。

参考资料

• Performance Schema
• sys Schema
• Slow Query Log