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 复制代码

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。

工作流程：

css 复制代码

SQL
→ Planner
→ Executor
→ LLVM IR
→ Machine Code
→ CPU 执行

八、JIT 的几个阶段

EXPLAIN ANALYZE 中你会看到：

yaml 复制代码

JIT:
  Functions: 10
  Options: Inlining true, Optimization true
  Timing:
    Generation 3.2 ms
    Inlining 20 ms
    Optimization 35 ms
    Emission 10 ms

1. Generation

生成 LLVM IR。

2. Inlining

函数内联。

减少函数调用成本。

3. Optimization

LLVM 做代码优化。

4. Emission

生成机器码。

九、为什么 JIT 有时候反而更慢？

JIT 的本质：

复制代码

编译成本 + 执行收益

如果：

复制代码

编译时间 > 节省时间

那么：

JIT 就会拖慢 SQL

十、典型错误场景

❌ 小 SQL

ini 复制代码

SELECT * FROM users WHERE id = 1;

问题：

SQL 执行可能只要 1ms
JIT 编译可能花 5~20ms

结果：

总耗时变大

❌ 高频 API SQL

Rails / GraphQL 系统非常常见：

ini 复制代码

SELECT * FROM tasks WHERE project_id = ? LIMIT 20;

特点：

高频
短 SQL
延迟敏感

这种场景：

JIT 几乎一定不划算

❌ 高并发系统

JIT 会：

增加 CPU
增加 LLVM 编译压力
增加 latency spike

十一、哪些场景适合 JIT？

✔ 报表系统（OLAP）

例如：

sql 复制代码

SELECT
    user_id,
    SUM(price * tax_rate)
FROM orders
GROUP BY user_id;

特点：

扫描大量数据
计算复杂
SQL 执行时间长

✔ 大 JSONB 查询

sql 复制代码

SELECT *
FROM logs
WHERE metadata->>'type' = 'error';

✔ 数据分析类 SQL

大聚合
大过滤
CPU-heavy

十二、哪些场景不适合？

❌ OLTP

例如：

Rails
微服务
GraphQL
API Server

特点：

查询短
QPS 高
latency 敏感

❌ 索引查询为主

ini 复制代码

WHERE id = ?

这种本来就很快。

❌ 高并发在线业务

JIT 容易导致：

CPU 波动
RT 抖动
p99 上升

十三、如何查看 JIT 是否生效？

查看是否开启

ini 复制代码

SHOW jit;

查看 JIT 参数

ini 复制代码

SHOW jit_above_cost;
SHOW jit_inline_above_cost;
SHOW jit_optimize_above_cost;

十四、核心参数详解

1. jit

是否开启。

ini 复制代码

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

scss 复制代码

EXPLAIN (ANALYZE, BUFFERS, JIT)
SELECT ...

你会看到：

yaml 复制代码

JIT:
  Functions: 8
  Timing:
    Generation 4ms
    Optimization 30ms

2. pg_stat_statements 统计 JIT 开销（核心排查 SQL）

下面这条 SQL 可以用于：

找出正在使用 JIT 的 SQL
分析 JIT 平均耗时
判断 JIT 是否值得
排查哪些 SQL 被 JIT "误伤"

sql 复制代码

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（核心）

scss 复制代码

(
 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）

通常建议：

ini 复制代码

jit = off

原因：

latency 更稳定
CPU 更低
p99 更好

OLAP / 报表系统

建议：

ini 复制代码

jit = on

因为：

SQL 很长
CPU-heavy
编译成本可摊销

十九、生产上最推荐的策略

不是：

复制代码

全局开

也不是：

复制代码

全局关

而是：

二十、总结一句话

PostgreSQL JIT 是一个"用编译换执行速度"的 CPU 优化器，只适合"大量数据 + 复杂计算"的 SQL，不适合高频短查询 OLTP 系统。

二十一、你当前场景的判断（结合你之前的问题）

你之前提到：

慢 SQL
Rails
GraphQL
API
CPU 压力
怀疑 JIT 导致慢查询

这种场景里：

关闭 JIT 是非常常见且合理的优化方向。

因为：

你的系统更像：

复制代码

OLTP / API 型系统

而不是：

复制代码

OLAP / 报表型系统

所以：

ini 复制代码

jit = off

很可能会：

降低 CPU
提升 RT 稳定性
降低 p99
减少 latency spike

PostgreSQL JIT 详细讲解