SQL视图无法直接参数化，需封装为表值函数：PostgreSQL/SQL Server支持原生实现，MySQL需变通；函数中ORDER BY和分页逻辑易出错；跨库需统一COALESCE、CURRENT_TIMESTAMP等，并注意执行计划差异。
SQL 视图逻辑没法直接当函数用，得包装成表值函数
PostgreSQL 和 SQL Server 支持 CREATE FUNCTION ... RETURNS TABLE，MySQL 则不行——它没原生表值函数。想复用视图逻辑又不想重复写 SQL？绕不开这层封装。视图本身不能接受参数，而带参数的逻辑必须靠函数兜底。
常见错误是把视图名直接塞进 SELECT * FROM my_view WHERE id = ?，结果报错：ERROR: function my_view(integer) does not exist。这不是语法错，是根本没定义可调用接口。
- PostgreSQL：用
CREATE OR REPLACE FUNCTION my_logic(id INT) RETURNS TABLE(...) AS $$ SELECT ... FROM ... WHERE $1 = id $$ LANGUAGE sql; - SQL Server：用
CREATE FUNCTION dbo.my_logic(@id INT) RETURNS TABLE AS RETURN (SELECT ... FROM ... WHERE id = @id); - MySQL：只能退回到存储过程 + 临时表，或改用应用层拼接（不推荐），或升级到 8.0+ 后用内联表值函数模拟（需配合
JSON_TABLE或预编译视图逻辑）
视图转函数时，ORDER BY 和 LIMIT 很容易被忽略
视图里加 ORDER BY 是无效的（SQL 标准规定），但函数里加就真会生效——尤其在 PostgreSQL 中，ORDER BY 会固化输出顺序，影响上层 OFFSET/FETCH 或分页逻辑。反过来，MySQL 存储过程中若漏写 LIMIT，函数返回可能爆炸式膨胀。
典型坑：把一个带 ORDER BY created_at DESC LIMIT 10 的视图，原样抄进函数体，却忘了函数调用时没传参控制范围，结果每次查都只返回固定 10 行，掩盖了真实数据分布。
- 函数内部慎用
ORDER BY，除非你明确需要它参与后续分页或游标逻辑 - 涉及分页场景，优先把
OFFSET/LIMIT提到函数调用侧，而不是硬编码在函数体里 - SQL Server 函数中不允许出现
TOP+ 变量（如TOP @n），必须用OFFSET-FETCH替代
跨数据库复用视图逻辑，字段别名和 NULL 处理差异最大
同一个视图逻辑，在 PostgreSQL 里 COALESCE(col, 'N/A') 没问题，放到 SQL Server 可能因字段类型隐式转换失败；MySQL 更麻烦，IFNULL 和 COALESCE 对空字符串、NULL、零值的判定边界不一致。
更隐蔽的是字段别名：视图里写 SELECT user_id AS id，函数里若漏掉 RETURNS TABLE(id INT) 的声明，PostgreSQL 会静默丢掉别名，返回列名变成 user_id，导致下游应用报 column "id" does not exist。
- 函数的
RETURNS TABLE(...)必须显式声明所有列名和类型，不能依赖 SELECT 推断 - 统一用
COALESCE而非方言函数（如ISNULL、IFNULL），并在各库做兼容性测试 - 对时间字段，避免直接
now()，改用CURRENT_TIMESTAMP保证跨库语义一致
函数性能比视图差？关键看是否支持内联展开
PostgreSQL 12+ 对简单 SQL 函数默认内联（inlining），表现接近视图；SQL Server 的内联表值函数（ITVF）也会被优化器展开，和视图几乎无差别；但 MySQL 的存储过程函数无法内联，每次调用都是独立执行计划，加索引也救不了。
最容易误判的情况：给函数加了复杂 CTE 或子查询，结果发现执行计划里多了一层嵌套，IO 翻倍。这不是函数本身慢，是优化器放弃了展开。
- 函数体尽量保持单个
SELECT，避免 CTE、变量赋值、循环 - PostgreSQL 中用
STABLE或IMMUTABLE标记函数，有助于优化器决策是否缓存或内联 - 上线前务必用
EXPLAIN ANALYZE对比视图与函数的实际执行计划，别只看代码长度
真正难的不是写函数，是让同一段逻辑在不同数据库里既跑得通，又不出性能抖动——字段类型对齐、NULL 语义收敛、执行计划可控，这三块最容易在交接或迁移时突然冒出来。
