PostgreSQL JIT 详细讲解
PostgreSQL JIT 详细讲解
PostgreSQL 的 JIT（Just-In-Time Compilation）是 PostgreSQL 11 引入的一个高级性能优化特性。
很多人会误以为：
“开启 JIT = SQL 自动变快”
实际上并不是。
在真实生产环境中：
- 有些系统开启后性能提升明显
- 有些系统开启后 CPU 飙升、RT 变差
- 很多 Rails / API 系统最后会选择关闭 JIT
所以理解 JIT 的核心，不是“怎么开启”，而是：
它到底优化什么、适用于什么场景、为什么会拖慢系统。
一、JIT 是什么？
JIT 全称：
Just-In-Time Compilation（即时编译）
本质上：
PostgreSQL 会把 SQL 执行中的部分逻辑，动态编译成机器码执行。
传统 PostgreSQL 的执行方式
默认情况下，PostgreSQL 是：
SQL → Parser（解析） → Planner（生成执行计划） → Executor（执行器） → Interpreter（逐行解释执行）
也就是说：
SQL 中的表达式：
price * tax_rate > 100
会被 PostgreSQL 一行一行解释执行。
每处理一行：
- 读取字段
- 做运算
- 做判断
- 返回结果
这种方式灵活，但 CPU 开销较高。
二、JIT 的核心原理
JIT 会把这些“重复执行的表达式逻辑”：
price * tax_rate > 100
编译成：CPU 可以直接执行的机器码
从而：
- 减少解释器开销
- 减少函数调用
- 提升 CPU 执行效率
三、JIT 解决什么问题？
JIT 主要解决的是：
“CPU 计算开销过高”的问题
不是 IO 问题。
四、JIT 优化的核心场景
JIT 主要优化：
| 类型 | 示例 |
|---|---|
| 表达式计算 | CASE WHEN、数学运算 |
| JSONB 解析 | -> / ->> |
| WHERE 复杂过滤 | 多层条件 |
| 聚合计算 | SUM / COUNT / GROUP BY |
| 大量行处理 | Seq Scan / Bitmap Scan |
| CPU 密集型 SQL | 报表统计 |
五、JIT 不优化什么？
JIT：
❌ 不优化磁盘 IO
❌ 不优化索引
❌ 不优化网络
❌ 不优化锁等待
❌ 不优化慢 JOIN 算法
六、JIT 的真正优化目标
JIT 优化的是：
Executor 阶段中的“表达式执行成本”
即：每处理一行数据时的 CPU 成本
七、JIT 工作流程
PostgreSQL JIT 基于 LLVM。
工作流程：
SQL → Planner → Executor → LLVM IR → Machine Code → CPU 执行
八、JIT 的几个阶段
EXPLAIN ANALYZE 中你会看到：
JIT:
Functions: 10
Options: Inlining true, Optimization true
Timing:
Generation 3.2 ms
Inlining 20 ms
Optimization 35 ms
Emission 10 ms1. Generation
生成 LLVM IR。
2. Inlining
函数内联。
减少函数调用成本。
3. Optimization
LLVM 做代码优化。
4. Emission
生成机器码。
九、为什么 JIT 有时候反而更慢？
JIT 的本质：编译成本 + 执行收益
如果：编译时间 > 节省时间
那么：
JIT 就会拖慢 SQL
十、典型错误场景
❌ 小 SQL
SELECT * FROM users WHERE id = 1;
问题：
- SQL 执行可能只要 1ms
- JIT 编译可能花 5~20ms
结果：
总耗时变大
❌ 高频 API SQL
Rails / GraphQL 系统非常常见：
SELECT * FROM tasks WHERE project_id = ? LIMIT 20;
特点：
- 高频
- 短 SQL
- 延迟敏感
这种场景：
JIT 几乎一定不划算
❌ 高并发系统
JIT 会：
- 增加 CPU
- 增加 LLVM 编译压力
- 增加 latency spike
十一、哪些场景适合 JIT？
✔ 报表系统（OLAP）
例如：
SELECT
user_id,
SUM(price * tax_rate)
FROM orders
GROUP BY user_id;
特点：
- 扫描大量数据
- 计算复杂
- SQL 执行时间长
✔ 大 JSONB 查询
SELECT * FROM logs WHERE metadata->>'type' = 'error';
✔ 数据分析类 SQL
- 大聚合
- 大过滤
- CPU-heavy
十二、哪些场景不适合？
❌ OLTP
例如：
- Rails
- 微服务
- GraphQL
- API Server
特点：
- 查询短
- QPS 高
- latency 敏感
❌ 索引查询为主
WHERE id = ?
这种本来就很快。
❌ 高并发在线业务
JIT 容易导致：
- CPU 波动
- RT 抖动
- p99 上升
十三、如何查看 JIT 是否生效？
查看是否开启
SHOW jit;
查看 JIT 参数
SHOW jit_above_cost; SHOW jit_inline_above_cost; SHOW jit_optimize_above_cost;
十四、核心参数详解
1. jit
是否开启。
SET jit = on;
2. jit_above_cost（最重要）
表示：
查询成本超过多少才启用 JIT
默认通常较高。
避免小 SQL 被误伤。
3. jit_inline_above_cost
是否启用 inline。
4. jit_optimize_above_cost
是否启用 LLVM 优化。
十五、如何分析 JIT 问题？
最重要的方法：
1. EXPLAIN ANALYZE
EXPLAIN (ANALYZE, BUFFERS, JIT) SELECT ...
你会看到：
JIT:
Functions: 8
Timing:
Generation 4ms
Optimization 30ms
2. pg_stat_statements 统计 JIT 开销（核心排查 SQL）
下面这条 SQL 可以用于：
- 找出正在使用 JIT 的 SQL
- 分析 JIT 平均耗时
- 判断 JIT 是否值得
- 排查哪些 SQL 被 JIT “误伤”
SELECT
query,
calls,
rows,
round((total_exec_time / calls)::numeric, 2) AS avg_exec_ms,
round((total_plan_time / calls)::numeric, 2) AS avg_plan_ms,
round(
(
(
jit_generation_time +
jit_inlining_time +
jit_optimization_time +
jit_emission_time
) / calls
)::numeric,
2
) AS avg_jit_ms,
round(
(
(
jit_generation_time +
jit_inlining_time +
jit_optimization_time +
jit_emission_time
) / NULLIF(total_exec_time, 0) * 100
)::numeric,
2
) AS jit_percent,
jit_functions,
round((shared_blks_hit::numeric / NULLIF(calls, 0)), 2) AS avg_buffer_hit,
round((shared_blks_read::numeric / NULLIF(calls, 0)), 2) AS avg_disk_read
FROM pg_stat_statements
WHERE jit_functions > 0
ORDER BY jit_percent DESC, avg_jit_ms DESC
LIMIT 20;
十六、如何解读这条排查 SQL？
avg_exec_ms
total_exec_time / calls
平均执行时间。
avg_jit_ms（核心）
( jit_generation_time + jit_inlining_time + jit_optimization_time + jit_emission_time ) / calls
表示：
每次 SQL 平均花多少时间在 JIT 编译上
jit_percent（最关键指标）
jit_time / total_exec_time
表示：
SQL 总时间中，有多少比例浪费在 JIT 上
十七、如何判断当前 SQL 不适合 JIT？
🚨 情况 1：jit_percent > 20%
说明：
很多时间都浪费在 LLVM 编译，而不是 SQL 执行。
这是最典型的：
- API SQL
- Rails SQL
- GraphQL SQL
问题。
🚨 情况 2：avg_jit_ms 很高
例如：
| 指标 | 值 |
|---|---|
| avg_exec_ms | 20ms |
| avg_jit_ms | 8ms |
说明：
40% 时间花在 JIT 上。
通常不划算。
🚨 情况 3：calls 非常高
例如：
| calls | avg_exec_ms |
|---|---|
| 100000 | 5ms |
这种高频 SQL：
几乎一定不适合 JIT
因为：
编译成本根本无法摊销。
🚨 情况 4：IO 很低但 CPU 很高
例如：
avg_disk_read 很低 avg_buffer_hit 很低 但 avg_exec_ms 很高
说明：
问题不是 IO。
而是：
CPU 计算 + JIT 开销
十八、生产环境最佳实践
OLTP 系统（Rails / API）
通常建议：
jit = off
原因：
- latency 更稳定
- CPU 更低
- p99 更好
OLAP / 报表系统
建议：
jit = on
因为：
- SQL 很长
- CPU-heavy
- 编译成本可摊销
十九、生产上最推荐的策略
不是：
全局开
也不是：
全局关
而是：
推荐方案
默认关闭
jit = off
报表 SQL 单独开启
SET LOCAL jit = on;
或提高触发门槛
jit_above_cost = 100000
避免短 SQL 被 JIT。
二十、总结一句话
PostgreSQL JIT 是一个“用编译换执行速度”的 CPU 优化器，只适合“大量数据 + 复杂计算”的 SQL，不适合高频短查询 OLTP 系统。
二十一、你当前场景的判断（结合你之前的问题）
你之前提到：
- 慢 SQL
- Rails
- GraphQL
- API
- CPU 压力
- 怀疑 JIT 导致慢查询
这种场景里：
关闭 JIT 是非常常见且合理的优化方向。
因为：
你的系统更像：
OLTP / API 型系统
而不是：
OLAP / 报表型系统
所以：
jit = off
很可能会：
- 降低 CPU
- 提升 RT 稳定性
- 降低 p99
- 减少 latency spike
到此这篇关于PostgreSQL JIT 详细讲解的文章就介绍到这了,更多相关PostgreSQL JIT内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
PostgreSQL流复制参数max_wal_senders的用法说明
这篇文章主要介绍了PostgreSQL流复制参数max_wal_senders的用法说明，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧2020-12-12
在开发过程中经常要取日期的年,月,日,小时等值,下面这篇文章主要给大家介绍了关于postgresql常用日期函数使用整理的相关资料,文中通过代码及图文介绍的非常详细,需要的朋友可以参考下2024-02-02
这篇文章主要介绍了PostgreSQL 中的postgres_fdw扩展详解，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧2021-01-01
在 PostgreSQL 中,处理日期范围的查询是常见的操作,然而,如果不进行适当的优化,这些查询可能会导致性能问题,特别是在处理大型数据集时,本文章将详细讨论如何优化在 PostgreSQL 中对于日期范围的查询,需要的朋友可以参考下2024-07-07
在 PostgreSQL 的生产运维中,连接数过多是最常见且影响深远的性能问题之一,本文将系统性地剖析 连接数过多的根本原因,详解 PostgreSQL 连接机制与资源开销,并对比主流 连接池方案的原理、配置与适用场景,需要的朋友可以参考下2026-02-02
在PostgreSQL中,数据的导入和导出是数据库管理中不可或缺的操作,通过使用COPYCOPYpg_dump和pg_dumpall等工具,您可以高效地管理您的数据,感兴趣的可以了解一下2026-05-05
Postgresql psql文件执行与批处理多个sql文件操作
这篇文章主要介绍了Postgresql psql文件执行与批处理多个sql文件操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧2021-01-01
了解PostgreSQL执行计划对于程序员来说是一项关键技能,执行计划是我们优化查询,验证我们的优化查询是否确实按照我们期望的方式运行的重要方式,这篇文章主要给大家介绍了关于postgresql数据库执行计划的相关资料,需要的朋友可以参考下2024-01-01
在现代企业级应用开发中,PostgreSQL 作为一款功能强大、开源且高度可靠的数据库系统,被广泛采用,本文将深入探讨 PostgreSQL 跨版本升级的核心策略、实操步骤、常见陷阱及问题排查方法,需要的朋友可以参考下2026-03-03
这篇文章主要介绍了PostgreSQL 使用raise函数打印字符串，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧2021-01-01
最新评论