函数在只读且确定性场景下比存储过程轻量，但含查询的函数会导致逐行执行、性能骤降；存储过程适合事务控制与批量操作，但开销来自上下文创建、长事务锁表及连接占用；二者均不能替代索引与高效sql设计。
存储过程执行开销比函数高，但函数不能直接修改数据
MySQL 中 FUNCTION 在多数只读场景下确实比 PROCEDURE 轻量——它被设计为可内联计算、支持在 SELECT 表达式中直接调用，而 PROCEDURE 必须用 CALL 显式执行，且无法嵌入 SQL 语句。但这个“轻量”有严格前提：函数必须是 DETERMINISTIC 或至少声明为 READS SQL DATA；若声明为 MODIFIES SQL DATA，不仅不能用于查询字段，还会触发额外权限校验和事务上下文检查，实际开销可能反超简单存储过程。
函数在 SELECT 里调用会严重拖慢查询性能
哪怕是一个看似简单的 GET_USER_LEVEL(uid) 函数，只要内部含 SELECT ... FROM users，MySQL 就会在每一行结果上重复执行该查询（即 row-by-row 执行），无法自动优化为 JOIN 或物化。常见错误现象是：原本 0.1 秒的 SELECT * FROM orders，加上 SELECT ..., GET_USER_LEVEL(user_id) AS level 后变成 5 秒以上。
- 能用
JOIN或子查询替代的，绝对不要用函数封装单表查 - 纯计算类函数（如日期偏移、字符串截取）无 I/O，性能影响小
- 函数体内若含临时表、循环或多次
SELECT，务必加EXPLAIN FORMAT=TREE看执行计划
存储过程适合封装多步操作，但要注意事务与连接生命周期
PROCEDURE 的核心价值不在“快”，而在“可控”：它可以显式管理事务（START TRANSACTION/ROLLBACK）、复用游标、批量处理数据，且支持 OUT 参数返回多个值。但它的开销来自三处：每次 CALL 都要新建执行上下文；若未显式 COMMIT，长事务会锁表；在连接池环境下，长时间运行的过程可能占用连接不释放。
- 避免在存储过程中做大量循环 + 单条
INSERT，改用批量INSERT ... VALUES (...), (...) - 涉及更新多张表时，优先用存储过程统一控制事务边界，别拆到应用层
- 调试时注意：
SHOW PROCEDURE STATUS查最近执行时间，INFORMATION_SCHEMA.PROCESSLIST看是否卡在某一步
二者都不能替代索引和合理 SQL 设计
很多人试图用函数封装复杂逻辑来“简化应用代码”，结果发现 WHERE status = GET_ORDER_STATUS(id) 完全走不了索引——因为 MySQL 无法对函数返回值做索引下推。同理，存储过程里写 SELECT * FROM huge_table WHERE col LIKE '%abc%' 再怎么封装也救不了性能。
- 函数返回值参与
WHERE或JOIN条件时，基本等于放弃索引 - 存储过程里嵌套多层
IF/WHILE不会提速，反而增加解析和跳转成本 - 真正影响性能的从来不是“用过程还是函数”，而是底层数据访问路径是否高效
函数和存储过程的边界模糊点往往在权限配置和调用链路上：应用直连数据库时，函数更容易被滥用；用中间件或 ORM 时，存储过程反而因调用方式受限而使用率下降。这些隐性成本，比执行毫秒级差异更值得提前评估。
