Saltyfish数据库查询忽快忽慢该升档吗？参数分布与计划复用怎样验收

同一条订单查询，小商户打开很快，大商户却经常超时，升级数据库服务器之前，值得先保留两组参数的执行计划。查询文字相同，实际需要读取的数据量可能差几个数量级；预备语句节省了重复处理的开销，也可能让参数差异与计划复用发生冲突。把Saltyfish列为候选主机时，应先用代表性租户验证计划选择，再询问计算资源、磁盘与管理权限。否则换了更贵的机器，仍可能沿用不适合大商户的访问路径。

先用两份租户数据决定试验顺序

设想一张包含一百万条记录的订单表，其中一个小租户只有一百条，一个大租户拥有四十万条。这是解释方法的假设数据，不是Saltyfish测试结果。两者分别占表的百分之零点零一与百分之四十，返回规模相差四千倍。查询条件虽然只替换一个租户编号，合理的读取方式却未必相同。索引定位少量记录通常值得尝试；需要读取大量记录时，顺序读取或其他路径也可能更划算，最终要看行宽、物理分布、缓存和过滤条件。

采购测试不要只放一个“典型账号”。应保留小、中、大租户，以及结果为空、近期数据集中等代表参数；每组记录返回行数、规划时间、执行时间和应用端完整耗时。选样的目标是覆盖会改变访问路径的分布，而不是把平均数据复制得更大。如果验收集没有大租户，机器跑过验收也无法说明它能应对真实的晚高峰。

PostgreSQL官方说明，通用计划在多次执行中相同，定制计划则利用本次参数生成。前者减少规划开销，后者在某些参数下可能更高效。这里的“复用”指执行计划，不是缓存查询结果；不能据此承诺第二次调用就会直接得到旧结果。

记录数差异只是线索。四千倍的返回规模不代表四千倍的耗时，也没有一个固定占比能替所有业务决定索引或顺序扫描。要把过滤后行数、实际读取和业务需要一起看。如果页面只显示最近二十条，排序索引和提前停止可能改变结论；如果业务必须导出全部订单，减少返回列、分批交付和输出传输也属于方案的一部分。

不要把第五次执行当成固定故障开关

当前读取到的PostgreSQL官方文档给出的自动选择规则是：带参数的预备语句先执行五次定制计划，计算这些计划的平均估算成本，再生成通用计划进行比较；后续是否复用通用计划，取决于这次成本判断。这说明早期执行参数值得保留，但不能把“运行几次后变慢”直接诊断为必然切换通用计划，更不能把估算成本当作实测毫秒数。

同一文档指出，预备语句只在当前数据库会话中存在，会话结束后便被遗忘。应用有多个数据库连接时，需要先确认慢请求究竟落到哪个会话、驱动是否实际建立了预备语句，以及连接重建是否改变观察结果。直接在新开的命令行连接中复制一条普通查询，可能绕开原来的计划状态；这类对照能提供线索，却不够还原应用故障。

可在受控会话中对同一预备语句分别安排小租户和大租户，再用EXPLAIN EXECUTE观察。官方文档说明，通用计划会显示参数符号，定制计划则代入实际参数值。保留参数与计划对应关系后，再判断是否需要比较强制定制和强制通用两种模式，避免只截一张“看起来用了索引”的图就结束。

plan_cache_mode提供auto、force_custom_plan和force_generic_plan选项；它在缓存计划即将执行时生效，而不是建立预备语句时生效。因此局部诊断可以在明确范围内进行，并记录如何恢复原设置。不宜先把生产实例全局改成强制定制，再以短暂好转宣布已经解决。其他语句可能本来就适合通用计划，额外规划消耗也会出现在整机预算里。

把节省的执行时间与新增的规划时间放在同一单位里

假设强制定制每次额外消耗两毫秒规划时间，调用频率为每秒二百次，则累计增加每秒四百毫秒的规划耗时。这只是量纲演算，不能直接等同于百分之四十的整机CPU占用，因为计时口径、等待、并行和硬件都可能不同。应再测进程CPU与实际吞吐。对于本来执行很短的查询，这笔开销可能不划算；对于少数大租户的昂贵查询，局部定制仍可能显著改善尾部等待。

可执行的决策门槛是：先为各参数组设定业务期限和峰值调用量，在可复现负载下比较完整响应与资源占用；只有新增规划成本可接受、慢参数确实改善且其他参数没有明显退化，才保留改动。不要用一次最快值替代重复运行的分布，也不要用所有租户混在一起的平均数掩盖大租户失败。

计划里看到的快，仍要与应用端对上

EXPLAIN ANALYZE会真正执行语句，并给出节点实际行数与运行时间。官方同时提醒，估算成本使用的是任意单位，与实际时间不是同一种数字；节点重复执行时，显示的时间和行数按每次执行平均，需要结合loops解读。如果一个内层节点重复很多次，仅盯着它单次的短耗时，会低估整个访问路径的代价。

检查重点应落在估算与实际行数是否相差明显、慢参数是否多读了大量块、排序是否外溢，以及同样参数是否稳定复现。如果统计信息不足导致选择偏差，可评估ANALYZE或针对列提高统计采集量，但更大的统计目标也增加采集工作，不能代替复核计划。表变更或统计更新还可能触发预备语句重新分析规划，前后比较要记录这些变化。

数据库内部执行快，也不等于用户已经收完结果。官方指出，EXPLAIN ANALYZE不向客户端发送查询结果，因此不包含网络传输成本；它自身的测量也可能引入额外开销。若内部计划已达标而导出仍慢，就应沿返回数据量、应用序列化、连接等待和传输路径继续定位。此时购买更快的数据库CPU，未必改善用户看到的主要等待。

在生产数据上诊断写语句尤其需要控制影响，因为ANALYZE选项确实会执行操作。采购验收更适合使用脱敏副本、只读查询和受控负载，并提前约定测试时段、停止条件与数据处理责任。测试准备成本也要算入迁移预算，不能只比较两台服务器的月租差。

Saltyfish候选订单按权限、资源和退出条件分别询价

本轮渠道通接口、Saltyfish官网与推广跳转均超时。推广入口来自二二六年十月三十日保存并核验的渠道通广告快照，现价、库存、处理器、磁盘性能、线路和退款条件尚未核实；这篇没有商家主机实测，也不宣称已确认最终落地页。因此下面是采购条件，不是现售套餐承诺。

适合继续询价的是能够自行管理数据库、可以保留诊断记录，并愿意在相同数据集上比较候选实例的团队。若只能使用受限托管环境，又无法获取会话设置或执行计划，先让服务方确认能否配合验收；没有这种交付能力，单纯增加核心和内存很难证明解决了问题。需要专属CPU、稳定持续磁盘性能或明确地域线路的业务，也必须取得具体订单说明，不能从品牌名称推导。

可通过Saltyfish套餐与采购咨询入口（推广）核对当前可售配置。下单前直接提交问题：数据库版本能否固定，是否允许设置会话级plan_cache_mode，能否导出EXPLAIN结果，磁盘和CPU属于何种共享或限制口径，试用与退款如何处理，升档是否要迁移及停机。这里只使用历史返回的推广链接，打开后还应核对实际商家与订单内容。

总成本可拆为主机费用、额外备份与副本费用、测试迁移人工、停机影响和退出成本。若两份报价每月差五个相同货币单位，全年仅固定租费就差六十个单位；这仍只是示例，不是Saltyfish报价。还应比较为了运行测试副本临时开机多久，以及发现不适配后如何取回数据。账单低而验收权限不足的方案，可能把节省的钱变成后续排障支出。

最终交付应保留按租户分组的结果：原参数、会话与驱动设置、计划类型、规划和执行耗时、应用完整响应、资源占用及可恢复设置。若更换计划已经让目标负载达标，可以暂缓升档；若合理计划仍持续受CPU或存储约束，再拿同一组样本比较候选主机。让订单对应可重复的业务结果，扩容预算才有明确用途。

资料来源

PostgreSQL官方：PREPARE

PostgreSQL官方：查询规划配置

PostgreSQL官方：EXPLAIN