PostgreSQL 14多OR条件+ORDER BY+LIMIT查询性能骤降求助

针对你的场景——单WalletID查询高效，但OR两个小交易量WalletID时，ORDER BY id DESC LIMIT 10耗时极长——以下是全场景可行的优化方案：

方案1：用UNION ALL合并单条件查询（最快捷的临时解决） #

将OR条件拆分为两个独立的单WalletID查询，通过UNION ALL合并结果后再排序取前10。由于每个子查询都会用到已有的transactions_wallet_id_index，快速获取对应Wallet的所有ID，合并后的总数据量仅为两个Wallet的交易数之和（此处仅59条），排序成本可以忽略。

优化后SQL：

SELECT id FROM (
  SELECT id FROM transactions WHERE wallet_id = $1
  UNION ALL
  SELECT id FROM transactions WHERE wallet_id = $2
) AS combined_results
ORDER BY id DESC
LIMIT 10;

注：用UNION ALL而非UNION，因为主键ID唯一，无需去重，性能更优。

方案2：创建复合索引（长期最优解） #

创建包含wallet_id和id DESC的复合索引，让数据库直接通过索引获取每个Wallet已按ID降序排列的交易数据，无需额外排序，无论Wallet交易量大小都能高效响应。

创建索引语句：

CREATE INDEX idx_transactions_wallet_id_id_desc ON transactions (wallet_id, id DESC);

该索引覆盖了WHERE wallet_id = ?的过滤条件和ORDER BY id DESC的排序需求，原查询或方案1的查询都会直接使用此索引，执行效率大幅提升。

方案3：调整统计信息（修正执行计划估算偏差） #

虽然你已执行过VACUUM和ANALYZE，但可以针对性提高wallet_id列的统计精度，让PostgreSQL更准确评估每个Wallet的交易行数，避免错误选择主键反向扫描的执行计划。

执行语句：

ALTER TABLE transactions ALTER COLUMN wallet_id SET STATISTICS 1000;
ANALYZE transactions;

注：1000为统计目标值，可根据实际数据分布调整，默认值为100，增大后统计信息更精准。

方案4：强制指定索引（应急场景） #

如果上述方案暂时无法实施，可通过索引提示强制数据库使用transactions_wallet_id_index（需PostgreSQL 12+并安装pg_hint_plan扩展），避免走主键全表扫描。

示例SQL：

SELECT /*+ IndexScan(transactions transactions_wallet_id_index) */
       "transactions"."id"
FROM "transactions"
WHERE ("wallet_id" = $1 OR "wallet_id" = $2)
ORDER BY "transactions"."id" DESC
LIMIT 10;

注：此方案为应急手段，长期不推荐，因为数据分布变化后可能导致执行计划不再最优。

问题根源说明 #

原查询慢的核心原因是PostgreSQL的执行计划估算偏差：当两个Wallet的交易总量极小时，数据库错误认为从主键（ID）反向扫描，快速找到10条符合条件的数据成本更低，但实际上这两个Wallet的最新交易ID非常陈旧，导致数据库扫描了1亿+条数据才筛选出目标结果。而拆分查询或复合索引的方式，直接从WalletID索引获取目标数据，完全避免了无效扫描。

内容的提问来源于stack exchange，提问作者Ahmed Abderraham