存储过程会显著增加数据库升级与迁移风险，因其非标准、跨版本兼容性差、云厂商限制多、调试监控困难、主从同步易出错、分库分表不支持、读写分离失效、连接池无法缓存，且应用层替代方案更轻量可控。
存储过程会让数据库升级和迁移变得极其脆弱
一旦业务中大量依赖 CREATE PROCEDURE，换库或升级 MySQL 大版本时，ALTER PROCEDURE 兼容性可能直接断裂。比如 MySQL 5.7 的 DECLARE CONTINUE HANDLER 在 8.0 中行为变化，但错误不会在创建时抛出，而是在某次调用中静默失败——这种问题在线上环境极难复现。
更现实的约束是云厂商限制：阿里云 RDS、腾讯云 CDB 默认禁用存储过程（需白名单申请），华为云 GaussDB(MySQL版) 则完全不支持。这意味着你写的存储过程，在本地开发能跑，上线就报 ERROR 1370 (42000): execute command denied。
- MySQL 官方文档明确将存储过程归类为“server-side logic”，不属于 SQL 标准，各实现差异大
- 跨云迁移时，若目标库是 Aurora 或 TiDB，
CALL语句基本不可用，必须重写为应用层事务 - 即使同为 MySQL，Percona Server 和 MariaDB 对游标、异常处理的支持也存在细微偏差
调试和监控链路被切断，问题定位成本翻倍
当一个 CALL transfer_funds() 执行超时，你无法像查普通 SQL 那样从 performance_schema.events_statements_history 中拿到完整执行栈——存储过程内部的每条语句被聚合为一条 CALL 记录，耗时、锁等待、IO 统计全丢失。
日志层面同样受限：slow_query_log 只记录调用入口，不记录过程内子查询；general_log 开启后会产生大量无意义的 BEGIN/END 行，真正关键的条件分支逻辑反而被淹没。
- MySQL Workbench 自带的存储过程调试器仅支持单步，且无法 attach 到已运行的会话
- 输出参数
OUT值无法被 Prometheus + mysqld_exporter 抓取，监控告警只能覆盖“是否调用成功”，无法感知业务逻辑结果 - 线上出现死锁时，
SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK不显示存储过程名，只显示线程 ID，回溯困难
水平扩展时存储过程成为主从同步瓶颈
MySQL 主从复制默认是语句级（SBR）或行级（RBR）。但存储过程在 SBR 模式下要求主从服务器的 sql_mode、系统变量（如 time_zone）必须严格一致，否则 CALL 在从库执行结果可能不同——这直接违反数据一致性前提。
切到 RBR 模式虽可规避部分问题，但存储过程内含非确定性函数（如 NOW()、RAND()、UUID()）时，binlog 仍会退化为 SBR，导致复制中断并报错 ERROR 1592 (HY000)。
- 分库分表中间件（如 ShardingSphere、MyCat）完全不解析存储过程语法，
CALL请求会被路由到单个节点，打破分片逻辑 - 读写分离场景下，从库通常设为
read_only=ON，但存储过程内含INSERT/UPDATE时，调用会直接失败，而非自动转发到主库 - 连接池（如 HikariCP）无法对
CALL做预编译缓存，每次调用都走完整协议解析，比普通PreparedStatement多消耗约 15% CPU
替代方案其实更轻量、更可控
所谓“封装复杂逻辑”，用应用层代码配合事务控制 + 参数化查询就能达成，且具备完整可观测性。例如资金转账，与其写 CREATE PROCEDURE TransferFunds，不如在 Go/Java 中用 tx.Exec 显式控制两笔 UPDATE + 一笔 INSERT。
性能差距远没宣传中那么大：现代 ORM（如 MyBatis、GORM）的批量操作 + 连接复用，网络开销已压缩到毫秒级；而存储过程省下的那点解析时间，在 SSD+Buffer Pool 缓存充分的场景下，几乎不可测。
- 用
SELECT COUNT(*) FROM users WHERE status = ?替代CALL get_active_user_count(1)，SQL 本身可缓存、可索引、可 explain - 用应用层幂等 key + 数据库唯一索引替代存储过程里的“先查后插”逻辑，避免过程内锁竞争
- 把原计划放在存储过程里的审计日志，改用应用层统一埋点 + 异步写入 Kafka，便于后续做用户行为分析
