mysql函数必须返回单个标量值且不可修改数据，存储过程则通过out参数或结果集返回数据并支持事务；函数用于计算求值，过程用于执行操作。
MySQL 函数必须返回值，存储过程不能直接返回标量
函数在调用时必须有 RETURN 语句，且只能返回单个值（如 INT、VARCHAR、DATE），它被设计成可嵌入 SQL 表达式中使用——比如写在 SELECT 的字段列表、WHERE 条件或 ORDER BY 子句里。
存储过程则不支持直接 RETURN 标量值；它靠 OUT 或 INOUT 参数传回数据，或者用临时表、结果集输出，但无法像函数那样“算出一个值就塞进查询里”。
- 错误写法：
SELECT my_proc(123) FROM dual;→ 报错ERROR 1305 (42000): PROCEDURE my_proc does not exist（MySQL 会把它当函数查） - 正确调用函数：
SELECT CONCAT('id=', my_func(456)) AS label; - 正确调用过程：
CALL my_proc(@out_val); SELECT @out_val;
函数受严格限制：不能修改数据，也不能调用存储过程
这是硬性安全约束。MySQL 函数被要求是“确定性且无副作用”的，因此不允许出现 INSERT、UPDATE、DELETE、DROP 等任何 DML/DLL 语句，也不允许 CALL 其他存储过程。一旦违反，创建时就会报错 ERROR 1418 (HY000)（除非显式加 DETERMINISTIC + SQL SECURITY DEFINER，但依然拦不住 DML）。
- 常见误踩坑：想在函数里记录日志（
INSERT INTO log_table）→ 直接失败 - 替代方案：把写操作移到存储过程中，函数只做纯计算；需要组合逻辑时，用过程封装整个流程，函数仅作子计算单元
- 注意：函数里连
SELECT ... INTO变量都允许，但目标表不能是被修改的对象
存储过程支持事务控制，函数完全不支持
如果你需要原子性地执行多条 DML（例如转账：扣 A 账户、加 B 账户、记流水），必须用存储过程，并显式使用 BEGIN ... START TRANSACTION、COMMIT、ROLLBACK。函数里哪怕只写一条 INSERT 都非法，更别说事务了。
- 典型场景：
CALL transfer_money(1001, 1002, 500.00);内部含START TRANSACTION和异常处理 - 函数里想模拟“尝试更新并返回影响行数”？不行——
ROW_COUNT()可读，但你根本不能触发更新 - 性能提示：函数因无事务开销，执行更快；但别为了这点速度强行把业务逻辑塞进函数里
权限与部署粒度不同：函数属于表达式上下文，过程属于会话/服务级操作
函数常被用在视图定义、生成列（GENERATED COLUMN）、分区表达式中，这些地方只接受“能求值”的东西；而存储过程更适合做定时任务调度、ETL 初始化、批量维护等需显式触发的后台动作。
- 权限差异：执行函数只需
EXECUTE权限；调用过程同样，但若过程内含DROP TABLE，调用者还需对应对象的DROP权限 - 调试难度：函数出错难定位（尤其嵌在复杂
SELECT中）；过程可用SELECT中间变量、加SELECT 'debug: step1'辅助排错 - 兼容性提醒：MySQL 8.0+ 支持窗口函数和 CTE，很多过去靠过程拼接的逻辑现在可改用标准 SQL 实现，别一上来就写过程
