PostgreSQL中函数内SQL变慢主因是上下文切换开销。PL/pgSQL执行SQL时需切换至SQL引擎，循环调用、嵌套函数或隐式调用会累积切换成本；优化应减少切换次数，优先用集合操作替代循环，将逻辑尽量留在SQL层实现。
在PostgreSQL中，函数内部调用SQL语句有时会比直接执行相同SQL慢，这背后常涉及“上下文切换”（context switch）的开销。理解这一点需要从PL/pgSQL的执行机制和PostgreSQL的架构设计入手。
什么是上下文切换
当在PL/pgSQL函数中执行SQL语句时，控制权需要从过程语言处理器（如PL/pgSQL）切换到SQL执行引擎。这个过程称为“上下文切换”。每次函数中出现SQL语句（如SELECT INTO、INSERT、UPDATE等），都会触发一次或多次上下文切换。
虽然单次切换的开销很小，但在循环中频繁调用SQL时，累积效应会导致显著性能下降。
为何函数内SQL可能变慢
以下几种情况容易暴露上下文切换带来的性能问题：
- 循环中执行SQL：在FOR或WHILE循环中每轮都执行一条SQL，会导致大量上下文切换。例如逐行插入数据，远不如批量INSERT ... SELECT高效。
- 多次函数调用嵌套SQL：一个函数调用另一个函数，而后者又执行SQL，这种嵌套加深了上下文切换的层次。
- 表达式中隐式调用函数：在SQL语句的WHERE或SELECT子句中调用PL/pgSQL函数，可能导致函数被反复执行（每一行一次），加剧切换开销。
如何减少上下文切换影响
优化这类问题的核心思路是减少SQL与过程代码之间的来回切换次数，尽量让SQL一次性完成更多工作。
- 用集合操作替代循环：能用一条UPDATE或INSERT ... SELECT完成的，就不要写循环逐行处理。
- 批量处理数据：使用RETURN QUERY EXECUTE配合参数化查询，或利用数组批量操作。
- 将逻辑移回SQL层：复杂逻辑尽量用CTE、窗口函数或LATERAL连接实现，避免拆分到函数中。
- 使用PERFORM而非忽略结果：在PL/pgSQL中调用仅需副作用的SQL时，用PERFORM明确表示不关心结果，避免误解。
实际例子对比
比如要为每个用户生成一条日志：
低效写法（循环+上下文切换）：
CREATE OR REPLACE FUNCTION log_users_slow() RETURNS void AS $$DECLARE r RECORD;
BEGIN
FOR r IN SELECT id FROM users LOOP
INSERT INTO logs(user_id, action) VALUES (r.id, 'login');
END LOOP;
END;
$$ LANGUAGE plpgsql;
高效写法（单条SQL）：
CREATE OR REPLACE FUNCTION log_users_fast() RETURNS void AS $$BEGIN
INSERT INTO logs(user_id, action)
SELECT id, 'login' FROM users;
END;
$$ LANGUAGE plpgsql;
后者不仅代码更短，执行速度通常快几个数量级。
基本上就这些。关键不是“函数一定慢”，而是“频繁切换上下文会拖累性能”。合理组织逻辑，让数据库以集合理论的方式工作，才能发挥PostgreSQL的最大效率。
