本文详解为何连续查询的性能测量会出现偏差，并提供基于连接池、预热机制和统计学方法的可靠基准测试方案，避免缓存、jit 编译、连接复用等干扰因素导致的误判。
“第二个查询总是比第一个快”——这个现象你是不是看着特眼熟？别急着怀疑代码逻辑，这其实是典型的基准测试陷阱，根本不是真实性能差异。背后的猫腻在于数据库与运行时环境的多层优化机制：PostgreSQL 的查询计划缓存、操作系统页缓存、Node.js V8 的 JIT 预热，还有 TCP 连接建立开销的摊销效应。你每次新建 Client 实例并调用 connect()，看似“隔离”，实则共享着底层资源——比如 socket 复用、DNS 缓存，甚至 PG 的 shared_buffers。结果就是后续查询天然沾了前序操作“热身”的光。
那么，怎么才能测准？关键就三点：连接池 + 预热 + 多轮统计。
首先，绝不要在单次基准测试里反复新建和销毁连接，就像你那个 new Client() 循环。这会引入巨大的连接建立/销毁噪声（通常1~5毫秒），对毫秒级测量来说简直就是毒药。正确的做法是用 pg.Pool 复用连接：
const { Pool } = require('pg');const pool = new Pool({
user: 'postgres',
host: 'localhost',
database: 'indexing-is-really-hard',
password: process.env.DB_PASSWORD,
port: 5432,
max: 10, // 控制并发连接数，避免过载
});
// 预热：执行一次 dummy 查询，确保连接就绪、计划缓存填充
await pool.query('SELECT 1');
其次，必须把“预热阶段”和“测量阶段”分开。每组查询都要独立预热+测量，而且顺序要随机化，消除顺序偏差：
async function benchmarkQuery(queryObj, iterations = 1000) {
// Step 1: Warm-up (5x)
for (let i = 0; i < 5; i++) {
await pool.query(queryObj.queryStr, queryObj.options);
}
// Step 2: Measurement (discard first few for stability)
const times = [];
for (let i = 0; i < iterations + 10; i++) {
const start = performance.now();
await pool.query(queryObj.queryStr, queryObj.options);
const end = performance.now();
if (i >= 10) times.push(end - start); // skip first 10
}
const a vg = times.reduce((a, b) => a + b, 0) / times.length;
const p95 = times.sort((a, b) => a - b)[Math.floor(times.length * 0.95)];
console.log(
`${queryObj.queryStr.replace(/[rns]+/g, ' ').substring(0, 60)}... ` +
`→ a vg: ${a vg.toFixed(3)}ms, p95: ${p95.toFixed(3)}ms`
);
return { a vg, p95, times };
}
// 执行时打乱顺序，避免系统性偏差
const shuffled = [...queries].sort(() => Math.random() - 0.5);
for (const q of shuffled) {
await benchmarkQuery(q);
}
⚠️ 关键注意事项
- 别用 Date.now()：精度只有毫秒级，还受系统时钟调整影响；必须用 performance.now()（微秒级高精度，单调递增）。
- 禁用自动 prepared statement：pg 默认启用 prepare: true，可能导致首次查询变慢（计划生成开销）。如果要纯 SQL 比较，显式关闭：
await pool.query({ text: queryObj.queryStr, values: queryObj.options, prepare: false }); - 控制变量：确保测试期间没有其他负载（比如后台备份、监控查询）；用 EXPLAIN (ANALYZE, BUFFERS) 在 psql 里交叉验证执行计划是否一致。
- 统计有效性：单次 1000 次循环容易受 GC 或系统抖动影响。建议跑 3~5 轮完整 benchmark，取各轮平均值的中位数。
? 总结
你看到的“B 总比 A 快”本质上是没控制实验条件的伪相关。真实性能对比必须满足：① 连接复用（池化）；② 充分预热；③ 顺序随机化；④ 排除首尾异常值；⑤ 使用高精度计时器。只有这样做，测出来的 a vg 才能反映查询本身的计算与 I/O 开销，而不是环境噪声。最终结论始终以 psql 的 EXPLAIN ANALYZE 作为金标准，Node.js 测量仅用于验证应用层行为的一致性。
