使用PLpgSQL函数逐行查询表值是否为不良设计？性能如何？

性能与设计合理性 #

• 性能差距显著：逐行调用myfunc相当于把原本可以批量处理的JOIN拆成了N次独立查询（N是外层结果的行数），这会带来大量额外开销——重复的查询解析、执行上下文切换，还没法利用数据库对JOIN的批量优化（比如哈希连接、高效嵌套循环）。如果外层数据集规模大，性能会直接崩盘。
• 属于不良设计（多数场景）：如果只是为了“代码整洁”就这么做，完全是舍本逐末。SQL的核心优势就是声明式批量处理，强行用函数拆成逐行逻辑，等于主动放弃数据库最擅长的优化能力。

查询计划器能不能优化成JOIN？ #

不行。PLpgSQL函数对查询计划器来说是个黑盒——它不知道函数内部到底执行了什么查询逻辑，根本没办法把函数调用和外层查询合并成等价的LEFT JOIN。哪怕是纯SQL函数，也只有满足“不可变/稳定”、逻辑足够简单能被内联展开的条件，才有可能被优化，PLpgSQL函数基本做不到这一点，尤其是涉及表查询的函数。

PLpgSQL的正确打开方式 #

不是说PLpgSQL不能用，而是要用到刀刃上：

• 处理纯SQL搞不定的复杂逻辑：比如多步业务判断、循环操作、事务控制这类场景。
• 封装复用逻辑时，尽量做集合式处理：比如接受数组/集合参数，直接返回批量结果，而不是逐行调用。
• 只有当外层数据集极小（比如只有几行），性能差异可以忽略时，才考虑逐行调用的方式。

隐藏的使用风险 #

• 性能随数据量暴降：数据越多，函数调用的开销线性增长，后期要优化就得彻底重构，成本极高。
• 调试排查难：函数内部的逻辑不会出现在外层查询的执行计划里，排查性能瓶颈时根本找不到问题点。
• 维护成本高：函数和外层查询分离，后续修改逻辑容易出现不一致，不如直接写JOIN直观易懂。

内容的提问来源于stack exchange，提问作者Cesco2142