effective_cache_size设得过大（如超物理内存）会导致查询规划器高估缓存命中率，倾向选择低效的顺序扫描而非索引扫描，尤其影响中等规模常驻内存的表；需根据shared_buffers与os page cache实际使用情况合理设置，修改后需pg_reload_conf()生效且仅影响新执行计划。
effective_cache_size 设的值比物理内存还大，会怎样
postgresql 查询规划器用 effective_cache_size 估算「有多少数据可能在 OS 缓存里」，从而决定走索引扫描还是顺序扫描。它不分配内存，也不影响缓存行为——只是个成本模型里的假设值。
设成比物理内存还大（比如机器有 64GB RAM，却配 effective_cache_size = 128GB），规划器会高估缓存命中率，倾向于认为随机 I/O 很便宜，结果可能选错执行计划：该用索引时走了全表扫描，尤其在中等大小、能常驻内存的表上容易出问题。
- 典型现象：
EXPLAIN显示用了Seq Scan，但加/*+ IndexScan(t) */或临时改小effective_cache_size后反而快几倍 - 不是所有查询都敏感，对小表或纯内存操作影响微乎其微
- linux 的 page cache 没有「预留」概念，
effective_cache_size不会抢占或保留任何物理内存
怎么根据实际内存和 workload 设一个靠谱的值
别直接填总内存，也别拍脑袋。重点看「长期稳定被复用的数据量」——通常是 shared_buffers + 常驻的 OS page cache 部分。
- 保守起点：设为物理内存的 1/2 到 3/4（例如 64GB 机器，从
32GB开始试） - 如果数据库是独占机器且负载稳定，可观察
pg_stat_bgwriter中的buffers_checkpoint和buffers_clean比例；若 checkpoint 写压力小、cleaner 工作少，说明 page cache 利用率高，可适当调高 - OLAP 类查询多、大量 JOIN 大表时，倾向设低些（如 1/2），避免规划器误判 hash join 的内存成本
- 设太高比设太低更危险：低估磁盘 I/O 成本导致计划劣化，而设低顶多是多走几次索引，通常可接受
修改后要不要重启？生效范围是什么
effective_cache_size 是 superuser-only 的配置参数，修改后不需要重启 PostgreSQL，但必须 select pg_reload_conf() 或发 SIGHUP 才生效。
- 只影响新生成的执行计划，已缓存的 plan（比如 prepared statement 或函数内嵌 SQL）不会自动重编译
- 连接级生效，不是会话级：新连接用新值，老连接仍用旧值，直到它下次生成新 plan（如执行
PREPARE后的EXECUTE） - 不能在会话里用
SET effective_cache_size = 'xx'修改，会报错Error: parameter "effective_cache_size" cannot be changed now
和 shared_buffers 的关系经常被搞混
shared_buffers 是 PostgreSQL 自己管理的内存池，真正放数据页；effective_cache_size 是给规划器看的「外部缓存能力」估算值，两者完全不重叠、不竞争。
- 常见错误：把
shared_buffers设成 8GB，就顺手把effective_cache_size也设成8GB——这等于告诉规划器「除了 PG 自己的缓存，OS 一点额外缓存都没有」，严重低估真实缓存能力 - 典型合理组合：
shared_buffers = 8GB+effective_cache_size = 32GB（假设系统总内存 64GB，其余由 OS page cache 承担） - Linux 下
cached字段（/proc/meminfo）反映的是 page cache + slab 等，其中真正能被 PG 利用的，才是effective_cache_size应该逼近的部分
最麻烦的不是设错值，而是设完没验证——它不报错、不告警、不写日志，只悄悄让慢查询变更多。上线前用真实业务 SQL 跑 EXPLAIN (ANALYZE, BUFFERS) 对比前后计划，比查文档管用得多。