标量函数在select中被逐行调用n次导致性能线性下降，因其无法被优化器下推或缓存，每次调用均触发独立上下文切换和潜在嵌套查询，i/o与cpu开销放大；正确解法是绕过调用，改用生成列、应用层预计算或内联表达式。
自定义函数慢，不是函数逻辑本身有多复杂，而是它被调用的方式和数据库执行模型共同导致的——每次调用都是一次独立上下文切换，且优化器几乎无法干预。
为什么标量函数在SELECT里调用N次就等于慢N倍
数据库对 SELECT 列表里的标量函数（比如 dbo.CalculateTax）是「逐行求值」：结果集有 10 万行，函数就被调用 10 万次，哪怕函数体只有一行 RETURN @Amount * 0.1。这不是数据库偷懒，而是 SQL 引擎必须保证语义正确性——函数可能依赖会变的状态（如 GETDATE()、NEWID()），所以不敢缓存或提前计算。
- 实测中，一个休眠 2 秒的模拟函数，在 8 行结果上就耗时 16 秒
- 如果函数内部还包含
SELECT查询（比如查配置表），那每次调用都会触发一次嵌套查询，I/O 放大效应更明显 - SQL Server 和 MySQL 都一样，只是错误表现不同：SQL Server 显示高 CPU 占用，MySQL 则常伴随
type: ALL的全表扫描
WHERE 或 JOIN 中用函数等于主动放弃索引
把函数写进 WHERE 条件（如 WHERE calc_status(order_id) = 'done'）或 JOIN 条件（如 ON u.id = f_get_user_id(o.owner)），本质上是在告诉优化器：“别管索引了，老老实实扫一遍再算”。因为函数输出不可下推，优化器无法预估选择率，只能退化为嵌套循环 + 每次调用。
- JOIN 场景更危险：驱动表 1 万行 × 被驱动表 5 千行 → 最坏调用 5000 万次函数
- 即使函数声明为
DETERMINISTIC，只要实际行为不满足（比如读了系统变量或调了UUID()），MySQL 仍拒绝下推，且可能引发主从不一致 - Oracle 中若函数标记为
PRAGMA AUTONOMOUS_TRANSACTION，还会额外开事务，进一步拖慢
替代方案优先级：生成列 > 应用层预计算 > 内联表达式
不要试图“优化函数本身”，而要绕过函数调用这个动作。真正有效的解法，是让计算发生在数据写入时、或查询发起前，而不是查询执行中。
- MySQL 5.7+ 支持
GENERATED COLUMN：把status和order_id组合逻辑固化为虚拟列，再对该列建索引，WHERE就能走索引 - 应用层预计算：订单创建时就存好
tax_amount字段，查询直接取，避免运行时计算 - 实在要保留函数逻辑，至少展开成内联表达式：
order_amount * 0.1替代CalculateTax(order_amount)，让优化器有机会合并、裁剪、并行 - SQL Server 可考虑
SCHEMABINDING+WITH RETURNS NULL ON NULL INPUT提升确定性，但仅限纯计算场景，不解决 I/O 类函数问题
最隐蔽的性能陷阱，往往不是函数有多慢，而是你根本没意识到它被调用了多少次——尤其当它藏在视图、CTE 或报表 SQL 的深层嵌套里时。上线前用 EXPLAIN（MySQL）或 SET STATISTICS IO ON（SQL Server）看真实调用频次，比看函数代码本身更有价值。
