PmaControl
本页是 PmaControl 的原创文档。它保留了用于 MySQL 优化工作的实用索引结构，不复制第三方内容，也不依赖外部产品。
目标
性能评估页面把 MySQL 服务器的主要信号聚合成一个视图。它用于确定行动优先级，而不是替代 DBA 分析。
有用维度
- 配置：变量与内存、存储和负载的一致性。
- 查询：慢查询和高频查询的权重。
- 架构：索引、主键、数据量和临时表。
- 稳定性：重启、连接错误、死锁和线程饱和。
- 容量：CPU、I/O、QPS、连接数和磁盘空间趋势。
示例表格
| 维度 | 信号 | 优先级 |
|---|---|---|
| 内存 | Buffer pool 太小或发生 swapping | 高 |
| 查询 | 5 个 digest 消耗大部分时间 | 高 |
| 架构 | 关键表缺少合适索引 | 中到高 |
| 连接 | Max_used_connections 接近 max_connections |
中 |
要点
全局评分只有在可解释时才有价值。每一点都必须指向可验证的指标、查询或配置。
明确评估对象
针对每种服务器角色和代表性负载建立带日期的评估。记录观测窗口、数据新鲜度、版本、拓扑、硬件限制与业务目标。评估用户延迟时包括应用和代理链路。写入节点、报表复制节点和备用节点的可接受负载与风险并不相同。本指南描述审核方法；下列表格是模板，并非测量结果或自动计算的 PmaControl 评分。
SELECT NOW() AS observed_at, @@hostname AS hostname,
VERSION() AS server_version, @@global.read_only AS read_only;
SHOW GLOBAL STATUS WHERE Variable_name IN (
'Uptime', 'Questions', 'Threads_connected', 'Threads_running',
'Connection_errors_max_connections', 'Innodb_log_waits',
'Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests'
);建立基于证据的评估表
| 维度 | 证据 | 需要回答的问题 |
|---|---|---|
| 可用性 | 实际客户端链路、重启、当前错误 | 目标服务当前能完成工作吗？ |
| 查询 | 查询摘要、计划、请求分位数 | 哪类负载消耗时间预算？ |
| 内存与 I/O | RSS、内存压力、读取/刷盘延迟 | 主机是否限制有效吞吐量？ |
| 表结构 | 关键表、索引使用、增长 | 哪些结构成本可由执行计划确认？ |
| 恢复与安全 | 恢复测试、复制水位、授权、TLS | 数据丢失与访问风险是否可接受？ |
缺失、过时或未启用的采集项应标为未知。缺少指标不能变成绿色状态，也不能填入虚构的零。将观测结果、解释和建议操作分开。缓冲池未命中率、历史连接峰值或未使用索引列表，都需要结合负载背景才能形成结论。
按影响、紧迫性和可信度排序
- 严重：当前中断、存储即将耗尽、已确认且不可接受的数据丢失或访问暴露。
- 高：反复超过延迟或错误目标，或有已确认机制的持续压力增长。
- 计划处理：存在可测成本或风险，但无当前影响；安排受控验证。
- 未知：证据不足；分派数据采集任务，不应宣告成功。
使变更前后结果可比较
| 测量项 | 单位与采集方法 |
|---|---|
| 客户端延迟 p50/p95/p99 | 毫秒，相同端点及请求分布 |
| 有效吞吐量与错误 | 完成操作数/秒及失败请求数/总请求数 |
| 资源成本与可靠性 | CPU %、RSS MiB、I/O 毫秒、复制延迟秒、结果一致性 |
保持硬件、数据、流量构成、并发度与缓存状态可比，记录差异并重复试验。数据库计数器需要计算增量并检查重置。查询摘要的平均值不是请求分位数。同时报告收益和退化，保留原始证据，未测字段留空或明确标为未知。测试前定义验收和回滚条件；吞吐量提高但失败增多，不一定是改进。
用问题记录完成跟踪闭环
每项发现都应记录受影响的服务器或查询、时间、证据链接、可信度、业务影响、负责人、下一步、期限、验收测试与回滚方案。整改后附上测得的结果及剩余限制，在高峰流量和下一个完整业务周期复查。不能仅因参数已修改或总体评分改善就关闭问题。