PostgreSQL - 函数与存储过程的性能优化技巧

PostgreSQL 函数与存储过程性能优化摘要 🚀 PostgreSQL 函数与存储过程是业务逻辑下沉的关键组件，但不当使用会导致性能问题。本文总结核心优化技巧： 1️⃣ 区分函数与存储过程函数必须返回值，可嵌入SQL；存储过程无返回值，支持事务控制（PostgreSQL 11+） 2️⃣ 选择合适语言性能排序：SQL函数 > C函数 > PL/pgSQL > 其他语言

Jinkxs

293人浏览 · 2026-02-25 21:00:00

Jinkxs · 2026-02-25 21:00:00 发布

在这里插入图片描述

👋 大家好，欢迎来到我的技术博客！
📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。
🎯 本文将围绕PostgreSQL这个话题展开，希望能为你带来一些启发或实用的参考。
🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！

文章目录

PostgreSQL - 函数与存储过程的性能优化技巧 🚀

PostgreSQL - 函数与存储过程的性能优化技巧 🚀

在现代应用程序开发中，PostgreSQL 作为一款功能强大、开源且高度可扩展的关系型数据库，被广泛应用于各种业务场景。随着系统复杂度的提升，开发者越来越多地将业务逻辑下沉到数据库层，通过编写 函数（Functions） 和 存储过程（Stored Procedures） 来提高数据处理效率、减少网络往返、增强事务一致性。然而，若使用不当，这些数据库端代码反而可能成为性能瓶颈。

本文将深入探讨 PostgreSQL 中函数与存储过程的性能优化技巧，涵盖从基础概念、执行模型、常见陷阱到高级调优策略，并结合 Java 应用示例，帮助你构建高效、可维护的数据库逻辑。无论你是初级开发者还是资深 DBA，都能从中获得实用见解。💡

一、函数 vs 存储过程：理解差异是优化的前提 🔍

在 PostgreSQL 中，“函数”和“存储过程”这两个术语常被混用，但自 PostgreSQL 11 起，两者有了明确区分：

函数（Function）：
- 使用 CREATE FUNCTION 定义。
- 必须返回一个值（可以是 void）。
- 可以在 SQL 语句中直接调用（如 SELECT my_func()）。
- 支持多种语言：SQL、PL/pgSQL、PL/Python、C 等。
- 默认在事务内执行，不能独立提交或回滚子事务。
存储过程（Procedure）：
- 使用 CREATE PROCEDURE 定义（PostgreSQL 11+ 引入）。
- 不返回值（类似其他数据库中的“过程”）。
- 必须通过 CALL 语句调用。
- 关键优势：支持 COMMIT 和 ROLLBACK，可在过程中管理子事务（autonomous transactions 的近似实现）。

📌 提示：在 PostgreSQL 11 之前，所有逻辑都通过函数实现，即使不返回值也声明为 RETURNS void。如今，若需事务控制能力，应优先考虑存储过程。

执行模型对比

特性	函数	存储过程
返回值	是（包括 `void`）	否
调用方式	`SELECT`, `PERFORM`	`CALL`
事务控制	不支持 `COMMIT/ROLLBACK`	支持
可嵌入 SQL	✅	❌
性能开销	较低（尤其 SQL 函数）	略高（因事务管理）

-- 示例：函数
CREATE OR REPLACE FUNCTION add_numbers(a INT, b INT)
RETURNS INT AS $$
BEGIN
    RETURN a + b;
END;
$$ LANGUAGE plpgsql;

-- 示例：存储过程
CREATE OR REPLACE PROCEDURE transfer_funds(from_id INT, to_id INT, amount NUMERIC)
LANGUAGE plpgsql
AS $$
BEGIN
    UPDATE accounts SET balance = balance - amount WHERE id = from_id;
    UPDATE accounts SET balance = balance + amount WHERE id = to_id;
    COMMIT; -- 允许提交
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK;
        RAISE;
END;
$$;

理解这一区别，有助于我们在设计时选择合适的封装形式，避免因误用导致性能或逻辑问题。

二、函数语言的选择：性能差异巨大 ⚡

PostgreSQL 支持多种过程语言（Procedural Languages），不同语言对性能影响显著：

1. SQL 函数（最快）

纯 SQL 缽数由 PostgreSQL 查询优化器直接内联（inline），几乎无额外开销。

CREATE FUNCTION get_user_name(user_id INT)
RETURNS TEXT AS $$
    SELECT name FROM users WHERE id = user_id;
$$ LANGUAGE sql STABLE;

✅ 优点：

无解释器开销
可被优化器完全内联，参与外层查询优化
适合简单、只读操作

❌ 缺点：

无法包含控制流（如 IF、LOOP）
不能处理异常

2. PL/pgSQL（最常用）

PL/pgSQL 是 PostgreSQL 的默认过程语言，语法类似 Oracle PL/SQL。

CREATE FUNCTION calculate_discount(price NUMERIC, is_vip BOOLEAN)
RETURNS NUMERIC AS $$
BEGIN
    IF is_vip THEN
        RETURN price * 0.8;
    ELSE
        RETURN price * 0.95;
    END IF;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

✅ 优点：

支持复杂逻辑、变量、循环、异常处理
预编译执行计划（首次调用后缓存）

❌ 缺点：

每次调用有解释器开销
无法像 SQL 函数那样被完全内联

3. C 函数（极致性能）

用 C 编写并编译为共享库，可获得接近原生 SQL 的性能。

// 示例：C 函数（需编译为 .so 文件）
PG_FUNCTION_INFO_V1(add_c);
Datum add_c(PG_FUNCTION_ARGS) {
    int32 a = PG_GETARG_INT32(0);
    int32 b = PG_GETARG_INT32(1);
    PG_RETURN_INT32(a + b);
}

✅ 优点：

零解释开销
可直接操作内部数据结构

❌ 缺点：

开发复杂，需熟悉 PostgreSQL 内部 API
安全风险高（可能崩溃数据库）
部署麻烦（需服务器权限）

4. 其他语言（PL/Python、PL/Java 等）

适合需要外部库或复杂算法的场景，但性能通常较差。

CREATE FUNCTION py_upper(text)
RETURNS text AS $$
    return args[0].upper()
$$ LANGUAGE plpython3u;

📊 性能排序（从快到慢）：
SQL 函数 > C 函数 > PL/pgSQL > PL/Python / PL/Java

建议

简单逻辑 → 优先用 SQL 函数
复杂逻辑但高频调用 → 考虑 C 函数（谨慎）
一般业务逻辑 → PL/pgSQL 足够
避免在循环中调用高开销语言函数

三、函数属性（Volatility）对性能的影响 🧪

PostgreSQL 要求为每个函数指定 波动性（Volatility） 属性，这直接影响查询优化器的行为：

属性	含义	优化行为	示例
`IMMUTABLE`	对相同输入永远返回相同结果，不访问数据库	可在索引中使用；常量折叠	`UPPER()`, `ADD(a,b)`
`STABLE`	在单个 SQL 语句中结果不变，但可能跨语句变化	语句内只调用一次	`CURRENT_TIMESTAMP`, `NOW()`
`VOLATILE`（默认）	结果可能随时变化	每次调用都执行	`RANDOM()`, `TIMEOFDAY()`

错误设置的后果

-- ❌ 错误：将实际稳定的函数标记为 VOLATILE
CREATE FUNCTION get_config(key TEXT)
RETURNS TEXT AS $$
    SELECT value FROM config WHERE name = key;
$$ LANGUAGE sql VOLATILE; -- 应为 STABLE！

-- 在以下查询中，若标记为 VOLATILE，会多次查询 config 表
SELECT id, name, get_config('app_mode') FROM users;

若正确标记为 STABLE，优化器会在整个 SELECT 语句中只调用一次该函数，大幅提升性能。

正确设置示例

-- ✅ 正确：只读且结果在语句内稳定
CREATE FUNCTION get_user_role(user_id INT)
RETURNS TEXT AS $$
    SELECT role FROM user_roles WHERE user_id = $1;
$$ LANGUAGE sql STABLE;

-- ✅ 正确：纯计算，无副作用
CREATE FUNCTION factorial(n INT)
RETURNS BIGINT AS $$
DECLARE
    result BIGINT := 1;
    i INT;
BEGIN
    FOR i IN 1..n LOOP
        result := result * i;
    END LOOP;
    RETURN result;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

🔍 检查技巧：使用 EXPLAIN (ANALYZE, BUFFERS) 观察函数调用次数。若 STABLE 函数被多次调用，说明标记错误。

四、避免 N+1 查询：批量处理是关键 📦

在函数中执行 SQL 查询时，最容易犯的错误就是在循环中逐条查询，导致 N+1 问题。

反面教材

-- ❌ 危险！在循环中执行查询
CREATE FUNCTION get_user_orders_bad(user_ids INT[])
RETURNS TABLE(user_id INT, order_count BIGINT) AS $$
DECLARE
    uid INT;
BEGIN
    FOREACH uid IN ARRAY user_ids
    LOOP
        RETURN QUERY
        SELECT uid, COUNT(*) FROM orders WHERE user_id = uid;
    END LOOP;
END;
$$ LANGUAGE plpgsql;

若传入 1000 个用户 ID，将执行 1000 次 SELECT COUNT(*)，性能极差。

优化方案：批量 JOIN

-- ✅ 推荐：单次查询完成
CREATE FUNCTION get_user_orders_good(user_ids INT[])
RETURNS TABLE(user_id INT, order_count BIGINT) AS $$
BEGIN
    RETURN QUERY
    SELECT u.id, COUNT(o.id)
    FROM unnest(user_ids) AS u(id)
    LEFT JOIN orders o ON o.user_id = u.id
    GROUP BY u.id;
END;
$$ LANGUAGE plpgsql STABLE;

这里利用 unnest() 将数组展开为临时表，再与 orders 表 JOIN，只需一次扫描。

更进一步：使用 `LATERAL` 或 `WITH`

对于更复杂的逻辑，可结合 LATERAL 实现高效关联：

-- 获取每个用户的最新订单
CREATE FUNCTION get_latest_orders(user_ids INT[])
RETURNS TABLE(user_id INT, latest_order_date TIMESTAMP) AS $$
BEGIN
    RETURN QUERY
    SELECT u.id, o.order_date
    FROM unnest(user_ids) AS u(id)
    LEFT JOIN LATERAL (
        SELECT order_date
        FROM orders
        WHERE user_id = u.id
        ORDER BY order_date DESC
        LIMIT 1
    ) o ON true;
END;
$$ LANGUAGE plpgsql STABLE;

💡 黄金法则：永远不要在循环中执行 SQL 查询。尽可能将逻辑转化为集合操作。

五、减少上下文切换：内联 vs 外部调用 🔄

每次从 SQL 引擎切换到 PL/pgSQL 解释器（或反之）都有开销。频繁切换会累积显著延迟。

场景分析

考虑以下函数：

CREATE FUNCTION process_data()
RETURNS VOID AS $$
DECLARE
    rec RECORD;
BEGIN
    FOR rec IN SELECT id, value FROM raw_data LOOP
        -- 在 PL/pgSQL 中处理每行
        PERFORM insert_processed(rec.id, rec.value * 1.1);
    END LOOP;
END;
$$ LANGUAGE plpgsql;

这里存在多次切换：

执行 SELECT（SQL 引擎）
进入 PL/pgSQL 循环
调用 insert_processed()（又切换回 SQL）

优化：纯 SQL 实现

-- ✅ 用单条 SQL 完成
INSERT INTO processed_data (id, value)
SELECT id, value * 1.1 FROM raw_data;

若必须用函数，可考虑：

-- ✅ 批量传递，减少调用次数
CREATE FUNCTION bulk_process(data JSONB)
RETURNS VOID AS $$
BEGIN
    INSERT INTO processed_data (id, value)
    SELECT (elem->>'id')::INT, (elem->>'value')::NUMERIC * 1.1
    FROM jsonb_array_elements(data) AS elem;
END;
$$ LANGUAGE plpgsql;

Java 调用示例

// ❌ 低效：逐条调用
for (User user : users) {
    jdbcTemplate.update("SELECT process_user(?)", user.getId());
}

// ✅ 高效：批量传递 ID 数组
List<Integer> ids = users.stream().map(User::getId).collect(Collectors.toList());
jdbcTemplate.update("SELECT bulk_process_user(?)", 
    new PgArray(DataSourceUtils.getConnection(dataSource), "int4", ids.toArray()));

📌 注意：PostgreSQL 的 ARRAY 类型可高效传递批量数据。Java 中可通过 org.postgresql.util.PgArray 构造。

六、利用缓存与预编译：减少重复工作 🗃️

PL/pgSQL 函数在首次调用时会缓存执行计划，但某些情况下缓存失效或未充分利用。

1. 动态 SQL 的陷阱

-- ❌ 每次生成新计划，无法缓存
EXECUTE 'SELECT * FROM ' || table_name || ' WHERE id = ' || id;

应使用参数化动态 SQL：

-- ✅ 计划可缓存
EXECUTE 'SELECT * FROM ' || quote_ident(table_name) || ' WHERE id = $1'
USING id;

2. 避免在函数内创建临时对象

频繁创建临时表或索引会增加开销：

-- ❌ 每次调用都建表
CREATE TEMP TABLE tmp_results (...);

改为复用或使用 UNLOGGED 表（若数据可丢失）。

3. 结果缓存（应用层 or 数据库层）

对于计算昂贵且结果变化不频繁的函数，可考虑缓存：

-- 示例：带缓存的配置获取
CREATE FUNCTION get_cached_config(key TEXT)
RETURNS TEXT AS $$
DECLARE
    result TEXT;
BEGIN
    -- 尝试从缓存表读取
    SELECT value INTO result FROM config_cache WHERE name = key;
    IF result IS NULL THEN
        -- 未命中，计算并缓存
        SELECT value INTO result FROM config WHERE name = key;
        INSERT INTO config_cache (name, value) VALUES (key, result)
        ON CONFLICT (name) DO UPDATE SET value = EXCLUDED.value;
    END IF;
    RETURN result;
END;
$$ LANGUAGE plpgsql STABLE;

⚠️ 注意缓存一致性问题！需配合触发器或应用逻辑清理过期数据。

七、监控与诊断：用工具发现问题 🔧

优化前需先定位瓶颈。PostgreSQL 提供多种工具：

1. `EXPLAIN (ANALYZE, BUFFERS)`

查看函数内 SQL 的执行计划：

EXPLAIN (ANALYZE, BUFFERS)
SELECT get_user_orders_good(ARRAY[1,2,3,4,5]);

关注：

actual time：实际耗时
rows：返回行数是否合理
Buffers: shared hit/miss：I/O 情况

2. `pg_stat_user_functions`

监控函数调用统计：

SELECT funcname, calls, total_time, self_time
FROM pg_stat_user_functions
ORDER BY total_time DESC;

calls：调用次数
total_time：总耗时（含内部 SQL）
self_time：函数自身逻辑耗时（不含 SQL）

3. 日志分析

开启 log_min_duration_statement = 0（生产环境慎用）或设置阈值，记录慢函数调用。

八、Java 应用集成最佳实践 ☕

Java 应用通过 JDBC 调用 PostgreSQL 函数/存储过程时，也有优化空间。

1. 使用 `CallableStatement` 调用存储过程

// 调用存储过程
String sql = "{CALL transfer_funds(?, ?, ?)}";
try (CallableStatement cs = connection.prepareCall(sql)) {
    cs.setInt(1, fromId);
    cs.setInt(2, toId);
    cs.setBigDecimal(3, amount);
    cs.execute();
}

2. 批量调用函数（减少网络往返）

// ❌ 逐条调用
for (int id : ids) {
    String name = jdbcTemplate.queryForObject(
        "SELECT get_user_name(?)", String.class, id);
}

// ✅ 批量查询（利用 SQL 函数 + unnest）
String sql = """
    SELECT id, get_user_name(id) 
    FROM unnest(?) AS id
    """;
List<UserName> results = jdbcTemplate.query(sql, 
    (rs, rowNum) -> new UserName(rs.getInt("id"), rs.getString("get_user_name")),
    ids.toArray()
);

3. 正确处理返回结果集

PL/pgSQL 函数返回 SETOF 时，JDBC 需注册 ResultSet：

String sql = "{ ? = call get_user_orders_good(?) }";
try (CallableStatement cs = connection.prepareCall(sql)) {
    cs.registerOutParameter(1, Types.OTHER); // ResultSet
    cs.setArray(2, connection.createArrayOf("INTEGER", ids.toArray()));
    cs.execute();
    try (ResultSet rs = (ResultSet) cs.getObject(1)) {
        while (rs.next()) {
            // 处理结果
        }
    }
}

📌 提示：Spring Data JDBC 或 MyBatis 可简化此过程。

4. 连接池配置

确保连接池（如 HikariCP）配置合理：

# application.properties
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.connection-timeout=30000

避免因连接不足导致函数调用排队。

九、高级技巧：分区、并行与 JIT 🚄

1. 分区表 + 函数剪枝

若函数操作分区表，确保能利用 分区剪枝（Partition Pruning）：

-- 按日期分区的 orders 表
CREATE FUNCTION get_orders_by_date(start_date DATE, end_date DATE)
RETURNS SETOF orders AS $$
BEGIN
    RETURN QUERY
    SELECT * FROM orders
    WHERE order_date BETWEEN start_date AND end_date; -- 优化器自动剪枝
END;
$$ LANGUAGE plpgsql STABLE;

2. 并行查询支持

PostgreSQL 10+ 支持并行查询。确保函数不阻塞并行：

避免在函数中使用 VOLATILE 属性（除非必要）
不使用临时表（会禁用并行）

-- 启用并行（需配置 max_parallel_workers_per_gather > 0）
SET max_parallel_workers_per_gather = 2;
EXPLAIN SELECT get_user_name(id) FROM large_users_table;

3. JIT 编译加速（PostgreSQL 11+）

对于 CPU 密集型函数，可启用 JIT：

SET jit = on;
SET jit_above_cost = 100000; -- 默认 100000

JIT 会对表达式和元组处理进行即时编译，提升复杂计算性能。

🔗 了解更多：PostgreSQL JIT Documentation

十、常见陷阱与规避策略 🚫

1. 隐式类型转换

-- ❌ 字符串与数字比较，导致索引失效
SELECT * FROM users WHERE id = '123'; -- id 是 INT

-- 在函数中同样危险
CREATE FUNCTION bad_func(input TEXT)
RETURNS users AS $$
    SELECT * FROM users WHERE id = input; -- 隐式转换
$$ LANGUAGE sql;

✅ 解决方案：显式转换或使用正确类型参数。

2. 锁竞争

函数中长时间持有行锁或表锁会阻塞其他事务：

-- ❌ 危险：先查后更，中间可能被修改
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
-- ... 复杂逻辑 ...
UPDATE accounts SET balance = ... WHERE id = 1;

✅ 解决方案：尽量缩短锁持有时间，或使用 SELECT ... FOR UPDATE SKIP LOCKED。

3. 无限递归

CREATE FUNCTION fib(n INT) RETURNS INT AS $$
BEGIN
    IF n <= 1 THEN RETURN n; END IF;
    RETURN fib(n-1) + fib(n-2); -- 指数级调用！
END;
$$ LANGUAGE plpgsql IMMUTABLE;

✅ 解决方案：改用迭代或记忆化（memoization）。

十一、性能对比：可视化分析 📈

下面通过一个典型场景对比不同实现方式的性能差异。

假设需求：给定用户 ID 列表，返回每个用户的订单总数。

实现方式

Java 循环调用函数（N+1）
PL/pgSQL 循环查询（N+1）
SQL 函数 + unnest（批量）
纯 SQL（无函数）

测试环境

PostgreSQL 15
10,000 用户，平均每人 50 订单
查询 1,000 个用户

结果（模拟）

 渲染错误: Mermaid 渲染失败: No diagram type detected matching given configuration for text: barChart title 不同实现方式的执行时间（毫秒） x-axis 实现方式 y-axis 时间（ms） series “Java N+1” ： 4500 “PL/pgSQL N+1” ： 3200 “SQL 函数批量” ： 120 “纯 SQL” ： 90

💡 结论：批量处理比循环快 30~50 倍！函数本身开销很小，关键在于数据访问模式。

十二、总结与建议 ✅

优化 PostgreSQL 函数与存储过程的核心在于：

选择合适语言：简单逻辑用 SQL 函数，复杂逻辑用 PL/pgSQL，极致性能考虑 C。
正确设置波动性：IMMUTABLE / STABLE 能极大提升优化器效率。
杜绝 N+1 查询：始终以集合思维处理数据，利用 unnest、JOIN、LATERAL。
减少上下文切换：合并操作，避免循环内 SQL。
善用监控工具：EXPLAIN、pg_stat_user_functions 是你的朋友。
Java 集成优化：批量传递参数，减少网络往返。
警惕陷阱：类型转换、锁竞争、递归爆炸。

最后记住：数据库不是万能的。过度将业务逻辑放入函数可能导致：

难以测试和调试
版本控制困难
应用与数据库耦合过紧

在“性能”与“可维护性”之间找到平衡，才是工程之道。🎯

🔗 延伸阅读：

PostgreSQL Functions Documentation

Performance Tuning Guide

PL/pgSQL Best Practices

Happy coding, and may your queries always be fast! 🚀

🙌 感谢你读到这里！
🔍 技术之路没有捷径，但每一次阅读、思考和实践，都在悄悄拉近你与目标的距离。
💡 如果本文对你有帮助，不妨 👍 点赞、📌 收藏、📤 分享给更多需要的朋友！
💬 欢迎在评论区留下你的想法、疑问或建议，我会一一回复，我们一起交流、共同成长 🌿
🔔 关注我，不错过下一篇干货！我们下期再见！✨

松山湖开发者村综合服务平台

助力广东及东莞地区开发者，代码托管、在线学习与竞赛、技术交流与分享、资源共享、职业发展，成为松山湖开发者首选的工作与学习平台

更多推荐

梳理 Spring Boot Web 开发的几个概念

本文梳理了Spring Boot Web开发中的核心概念对比：Servlet/WebFlux、Tomcat/Netty、HttpServletResponse/ServerHttpResponse，以及spring-boot-starter-web/spring-boot-starter-webflux。Servlet采用同步阻塞模型，基于Tomcat容器；WebFlux采用响应式非阻塞模型，基于

松山湖开发者村综合服务平台

CNN 卷积神经网络：从直观理解到代码实践（含可视化）

CNN卷积神经网络通过多层特征提取实现图像识别，其核心流程为：输入像素→卷积提取边缘纹理→组合局部零件→识别整体物体→分类输出。关键点包括：1）卷积核滑动扫描实现特征检测；2）权值共享减少参数；3）池化层降维保留强特征；4）全连接层完成分类。该过程模拟生物视觉机制，具有平移不变性优势，是计算机视觉的基础架构。

松山湖开发者村综合服务平台

GCC编译(7)链接脚本LinkerScripts

松山湖开发者村综合服务平台

所有评论(0)

查看更多评论

Jinkxs

@qq_41187124

已为社区贡献26条内容

PostgreSQL - 函数与存储过程的性能优化技巧

Jinkxs

文章目录

PostgreSQL - 函数与存储过程的性能优化技巧 🚀

一、函数 vs 存储过程：理解差异是优化的前提 🔍

执行模型对比

二、函数语言的选择：性能差异巨大 ⚡

1. SQL 函数（最快）

2. PL/pgSQL（最常用）

3. C 函数（极致性能）

4. 其他语言（PL/Python、PL/Java 等）

建议

三、函数属性（Volatility）对性能的影响 🧪

错误设置的后果

正确设置示例

四、避免 N+1 查询：批量处理是关键 📦

反面教材

优化方案：批量 JOIN

更进一步：使用 LATERAL 或 WITH

五、减少上下文切换：内联 vs 外部调用 🔄

场景分析

优化：纯 SQL 实现

Java 调用示例

六、利用缓存与预编译：减少重复工作 🗃️

1. 动态 SQL 的陷阱

2. 避免在函数内创建临时对象

3. 结果缓存（应用层 or 数据库层）

七、监控与诊断：用工具发现问题 🔧

1. EXPLAIN (ANALYZE, BUFFERS)

2. pg_stat_user_functions

3. 日志分析

八、Java 应用集成最佳实践 ☕

1. 使用 CallableStatement 调用存储过程

2. 批量调用函数（减少网络往返）

3. 正确处理返回结果集

4. 连接池配置

九、高级技巧：分区、并行与 JIT 🚄

1. 分区表 + 函数剪枝

2. 并行查询支持

3. JIT 编译加速（PostgreSQL 11+）

十、常见陷阱与规避策略 🚫

1. 隐式类型转换

2. 锁竞争

3. 无限递归

十一、性能对比：可视化分析 📈

实现方式

测试环境

结果（模拟）

十二、总结与建议 ✅

所有评论(0)

Jinkxs

更进一步：使用 `LATERAL` 或 `WITH`

1. `EXPLAIN (ANALYZE, BUFFERS)`

2. `pg_stat_user_functions`

1. 使用 `CallableStatement` 调用存储过程