Prateek Arora：我在真实数据上对179条索引建议进行了计时，其中18%反而拖慢了查询。
内容提要
作者实测PgLens的179条索引建议，发现18%反而拖慢查询，最差一条估算省91%但实测慢约十倍，原因是规划器低估行数；另有34条因值过长无法建索引。规划器排序尚可，但单条提速估算不可靠。作者因此将数字标为估算，并新增真实建索引计时与超长值警告。
延伸解读
估算与实测的差距
文章显示，基于HypoPG的索引建议依赖规划器的估算成本，但估算可能严重偏离实际。最差案例中，估算成本降低91%，实测却慢约十倍，原因是规划器低估了连接返回的行数，导致嵌套循环执行次数远超预期。这提醒我们，估算数字不能直接当作提速承诺，必须通过真实建索引和计时来验证。
无法建索引的隐藏问题
179条建议中有34条无法测量，因为索引无法构建。具体原因是movie_info(info)列的值过长，14.8百万个值中有1,182个超过B-tree条目最大8191字节的限制。HypoPG不会实际写入条目，因此无法发现这类问题。PgLens新增了超长值警告，帮助用户提前识别此类风险。
规划器排序的可靠性
尽管单条查询的提速估算不可靠，但规划器在索引重要性排序上表现尚可。PgLens的#1索引节省了424秒总耗时中的364秒，且按估算节省排序与按实测节省排序的Spearman相关系数为0.83。因此，用规划器回答“哪个索引最重要”是合理的，但回答“这条查询能快多少”则不行。
工具改进与使用建议
作者将PgLens中的所有规划器数字标记为估算，不再显示为提速。新增的pglens confirm功能会在数据库副本上真实建索引并计时，展示每个查询前后的实测时间。工具还警告可能超长的列值。建议用户先通过confirm在副本上验证，再决定是否在生产环境建索引，以降低风险。
Q&A
PgLens 的索引建议在真实数据上的准确率如何？
在 Join Order Benchmark 的 179 条可测量建议中，128 条使查询至少快 15%，32 条使查询至少慢 5%，7 条使查询慢两倍以上，另有 34 条因索引无法构建而无法测量。
为什么有些索引建议反而会拖慢查询？
因为规划器低估了连接返回的行数，导致选择了嵌套循环，实际执行时循环次数远超预期，读取了更多缓冲区。例如查询 10c 的索引使缓冲区读取量增加了 71 倍。
PgLens 如何验证索引建议？
PgLens 使用 HypoPG 创建假设索引，重新运行 EXPLAIN，如果规划器估算成本下降至少 15% 则保留建议。但作者后来增加了 pglens confirm 命令，在数据库副本上真实构建索引并计时查询，以获取实际性能数据。
为什么有些索引无法构建？
因为索引列中的值可能过长，超出 B-tree 条目最大尺寸（8191 字节）。例如 movie_info (info) 索引中，1480 万值中有 1182 个值过长，导致索引构建失败。
PgLens 在规划器估算方面有哪些发现？
规划器在索引排序上表现良好（Spearman 相关系数 0.83），但单条查询的提速百分比估算几乎不可靠。因此 PgLens 将所有规划器数字标记为估算值，不再显示为提速。
PgLens 做了哪些改进？
PgLens 将所有规划器数字标记为估算值，新增 pglens confirm 命令在数据库副本上真实构建索引并计时查询，显示构建前后的实测时间，并对可能包含过长值的索引列发出警告。
