在 PmaControl 基准测试中，我们观察到了一项明显改进：同一项完整缓存检查，在受测 ProxySQL 2.7.3 和 3.0.5 构建版本上的平均耗时分别为 8.112 毫秒和 2.015 毫秒。这意味着耗时减少 75.16%，平均时间缩短至原来的约 1/4.03。

本文公开测量数据、指标定义、查询语句和测试方法，帮助读者准确理解结果。受测任务是 PmaControl 通过 ProxySQL Admin 接口执行的缓存有效性检查。

相同工作量下的结果

指标	ProxySQL 2.7.3	ProxySQL 3.0.5	耗时降幅
平均值, ms/audit	8.112204	2.014760	75.16 %
批次平均值的中位数, ms/audit	7.895812	2.053810	73.99 %
批次平均值的最大值, ms/audit	11.914402	2.919234	75.50 %
PHP 已分配内存峰值，MiB	4	4	不变

除内存指标外，表中的时间单位均为 ms/audit，即每次审计的毫秒数。中位数和最大值取自 15 个批次的平均值，每批包含 10 次审计。因此，最大值既不是单次调用的最坏延迟，也不是延迟百分位数。数据文件保留原始精度，信息图中的时间四舍五入至小数点后三位。

4 MiB 的 PHP 峰值表示分配给 PHP 进程的内存，不是 ProxySQL 服务端的内存使用量。

PmaControl 基准测试：ProxySQL 2.7.3 为 8.112 ms/audit，3.0.5 为 2.015 ms/audit，附测试方法和范围

“ms/audit”的含义

这里的一次审计是指完整调用一次 QueryCacheEffectiveness::run()，并不代表对服务器的所有检查。它执行两条只读 SELECT：第一条读取已启用的缓存规则及其匹配计数，第二条读取缓存计数器和配置大小。测试数据分别返回一行和七行。

计时器覆盖整个 PHP 检查，包括原生 SQL 执行、loopback 通信、结果获取以及 PmaControl 的处理逻辑。建立初始连接、启动 PHP 进程、HTTP 和界面渲染均在计时范围之外。这些数据是客户端观察到的耗时，没有单独分离 ProxySQL 内部执行时间。

下面给出两条查询，为便于阅读调整了排版。它们在两个版本上的逻辑完全相同。

SELECT r.rule_id, r.cache_ttl, r.digest,
       r.match_digest, r.match_pattern,
       COALESCE(h.hits, 0) AS hits
FROM runtime_mysql_query_rules r
LEFT JOIN stats_mysql_query_rules h
       ON h.rule_id = r.rule_id
WHERE r.active = 1 AND r.cache_ttl > 0
ORDER BY r.rule_id;

SELECT Variable_Name AS name, Variable_Value AS value
FROM stats_mysql_global
WHERE Variable_Name IN (
    'Query_Cache_count_GET', 'Query_Cache_count_GET_OK',
    'Query_Cache_count_SET', 'Query_Cache_Memory_bytes',
    'Query_Cache_Entries', 'Query_Cache_Purged'
)
UNION ALL
SELECT variable_name, variable_value
FROM global_variables
WHERE variable_name = 'mysql-query_cache_size_MB';

stats_mysql_query_rules.hits 统计规则匹配次数，而不是归属于该规则的缓存命中次数。缓存计数器是累计值，不能单独用于推断近期命中率。从 MAIN 读取的 mysql-query_cache_size_MB 是配置的清理目标，并非硬性上限；本检查不验证其 runtime 值。

基准测试方法

原始基准测试使用运行 Ubuntu 24.04.4 LTS 的共享测试虚拟机，配置为 2 vCPU、4 GiB RAM 和 PHP 8.4.26。通过 loopback 连接以下原生 ProxySQL 构建版本：

2.7 系列：2.7.3-12-g50b7f85；
3.0 系列：3.0.5-60-g7e9e009。

每个版本公布的数据包含 15 个批次，每批 10 次计时审计，每批之前执行 3 次预热调用：即每个版本 150 次完整审计，共 300 次审计和 600 条 SELECT。PHP 检查代码与 SQL 字符串相同；每批及每次调用均检查代码哈希和返回行数。

原始实验采用 15 对 AB/BA，交替运行旧版与修正后的 PmaControl 实现，每个实现使用独立 PHP 进程。本文仅选取修正后的实现。在每个进程内，先测试 ProxySQL 2.7.3，再测试 3.0.5：ProxySQL 版本顺序没有交替。包含旧实现的完整实验共有 600 次调用和 900 条 SELECT，这些数字不是本文版本对比的样本量。

为什么只比较完整检查

该基准测试原本用于验证一个功能修复：一条合法规则的带符号标识符为 rule_id=-1，TTL 为 5,000 毫秒，之前会导致检查在第一次读取后提前结束。检查错误地报告统计信息不可用，第二条查询从未执行。

将这种不完整结果与修正后的检查比较，会造成工作量不一致。因此我们在两个 ProxySQL 版本上使用完全相同的修正后检查代码，执行两次读取并获得完整观测。本文描述的是该场景下 ProxySQL 构建版本之间的差异，不把性能提升归因于 PmaControl 的校验修复。我们复核了已有测量数据，没有为本文重新运行基准测试。

这些改进能够说明什么

在这个环境中，受测 3.0 构建的平均值、批次平均值的中位数及最大值均更低，PHP 已分配内存峰值保持不变。这是监控任务中可以测量到的改进。

结果只针对共享虚拟机、小规模结果集和这一具体检查，不能证明应用查询吞吐量、前端路由延迟或高并发场景下也有相同提升。测试没有分离服务端 prepare/step/copy/finalize 各阶段，不证明 SQL 耗时低于 1 毫秒，也不评估生产容量或数据持久性。这里没有建立置信区间，版本测试顺序也是固定的。

在上述范围内，完整缓存检查的平均耗时约为原来的四分之一。ProxySQL 的这项改进值得肯定！

重新计算结果

公开数据包含选取的 30 个批次、300 次单独调用的耗时、结果行数和测试方法元数据。内部路径和诊断消息已删除，测量值保持不变。Python 脚本仅使用标准库，可重新计算表格，但不会重新运行基准测试。

耗时降幅计算公式为 100 × (1 − time_3.0 / time_2.7)，比值为 time_2.7 / time_3.0。所有批次大小相同。下面的哈希标识实际加载的检查代码，commit 对应包含该实现的 PR 修订版本。

curl -fsSLO https://pmacontrol.com/downloads/proxysql-2.7-vs-3.0/benchmark-data.json
curl -fsSLO https://pmacontrol.com/downloads/proxysql-2.7-vs-3.0/analyze.py
python3 analyze.py benchmark-data.json

PmaControl revision:
b4e7b4c6ca72cf27077ddbdb1f2c89af05800b5a
QueryCacheEffectiveness helper SHA-256:
c47a169935f665259554bd0fbaa85e90af9cbcd3983bf7ad3548e2caaf63d4dc

图表、分享和来源

为方便分享，图表使用英文；本文完整说明了图中的数据和解释。页面上的 PDF 按钮也可导出包含图片的文章。

原始工作记录：PmaControl PR #6389 和传播内容 issue #6390。这些 Forgejo 链接需要仓库访问权限，上述下载文件则公开可用。

ProxySQL 2.7 → 3.0：PmaControl 缓存审计速度提升约 4 倍