别将 maintenance_work_mem 设为 4gb；它按每个维护操作独立分配，多并发建索引易触发 oom；建议单次建 1–2 个索引，会话级设为 300–500mb，配合 max_parallel_maintenance_workers=2，并确保 shared_buffers 不过高。
maintenance_work_mem 设置过大反而导致 OOM
直接结论：别一上来就设成 maintenance_work_mem = 4GB。32GB 物理内存的服务器上，同时建 16 个索引、每个用 4GB，光这一项就吃掉 64GB 内存——操作系统直接杀进程，报 Out of memory: Kill process 不是 bug，是必然。
根本原因在于：maintenance_work_mem 是**每个维护操作独立分配**的内存上限，不是全局池。你开 16 个 psql 并发执行 CREATE INDEX，PostgreSQL 就会尝试为每个连接预留一份该值大小的内存（实际使用可能略少，但预分配行为已触发）。
实操建议：
- 单次只建 1–2 个索引，避免并发维护操作；
- 临时调高该值仅限当前会话：
SET maintenance_work_mem = '512MB';，建完即丢，不影响其他操作； - 若必须批量建索引，把
maintenance_work_mem设为300MB ~ 500MB（非 GB 级），再配合max_parallel_maintenance_workers = 2（别设成 4）； - 确认
shared_buffers没被设得过高（比如 >8GB），否则和maintenance_work_mem叠加后极易突破物理内存边界。
为什么 300MB 是更安全的起点
按 PostgreSQL 官方建议，maintenance_work_mem 不宜超过物理内存的 1/8。32GB × 1/8 = 4GB —— 这是理论极限，但前提是：无其他内存压力、无并发维护、无 autovacuum 干扰、且 work_mem 和 autovacuum_work_mem 未额外放大占用。
真实生产环境永远达不到这个理想条件。300MB 是一个经过压测验证的平衡点：
- 对千万级表建 B-tree 索引，速度提升明显（相比默认 64MB）；
- 即使开启 2 个并行 worker，总内存占用也控制在 1GB 以内；
- 留足空间给
shared_buffers（建议 8GB）、work_mem（设为 16MB）、以及 OS 缓存； - 不会触发 Linux OOM Killer，也不影响连接数较多时的稳定性。
别忽略 max_parallel_maintenance_workers 的副作用
这个参数不是“越大越快”。它控制的是单个 CREATE INDEX 能启用多少后台 worker 进程，每个 worker 都会申请一份 maintenance_work_mem 内存。
例如：maintenance_work_mem = 512MB + max_parallel_maintenance_workers = 4 → 单条建索引命令最多申请 512MB × (1 + 4) = 2.5GB 内存（1 主 + 4 worker）。
所以务必同步约束：
- 设
max_parallel_maintenance_workers = 2（8 核 CPU 下足够）； - 避免在低配机器（如 16GB 内存）上启用并行维护；
- 注意：并行建索引对数据分布敏感，如果字段高度重复或存在大量 NULL，加速效果会打折扣。
真正影响大索引速度的，往往不是 memory，而是 I/O 和排序效率
如果你的表数据物理存储是乱序的（比如按时间插入但没聚簇），CREATE INDEX 必须先做一次全表排序，这时 maintenance_work_mem 再大也救不了磁盘随机读瓶颈。
更有效的前置动作是：
- 建索引前先
CLUSTER或VACUUM FULL（慎用，锁表）让数据物理有序； - 用
pg_prewarm把热数据页提前载入shared_buffers； - 确认磁盘是 SSD，且
random_page_cost已调低（比如设为 1.1）； - 避免在高负载时段建索引，防止 I/O 争抢拖慢整个实例。
最后提醒一句：所有调优都得在测试库跑通再上生产。特别是 maintenance_work_mem，它不像 work_mem 那样能会话级动态覆盖——改了配置文件就得重启，而重启本身对业务就是风险点。
