MySQL不建议把业务逻辑下沉到存储过程中，因其破坏应用层可控性与数据库职责单一性，导致维护难、扩容难、隐性故障多；执行引擎不擅复杂逻辑，版本控制失效，跨库迁移困难，且云数据库常禁用。
MySQL 不建议把业务逻辑下沉到存储过程中 —— 核心原因是它会打破「应用层可控」和「数据库职责单一」的平衡，反而让系统更难维护、更难扩容、更容易出隐性故障。
存储过程让数据库承担不该承担的计算压力
MySQL 的执行引擎不是为复杂逻辑设计的：没有原生数组、循环靠 WHILE + REPEAT 模拟、异常处理只有 DECLARE HANDLER 这种弱抽象。一旦业务需要分页聚合、状态流转判断、多表条件跳转，SELECT + IF + CURSOR 套三层之后，单次调用就可能锁住行数分钟，而应用层用连接池+异步可以轻松拆解。
- 高并发下，存储过程执行线程会挤占
innodb_thread_concurrency资源，导致普通查询排队 - 执行计划固化：
EXPLAIN看不到存储过程内部 SQL 的真实执行路径，optimizer_trace也只到外层调用为止 - 无法利用应用层缓存（如 Redis）做短路：哪怕只是查个用户状态，也得走一遍 DB 全链路
业务逻辑写在数据库里 = 版本控制失效 + 团队协作断点
存储过程代码藏在 mysql.proc 表里，不进 Git，不能 git diff，不能 Code Review，也不能 CI 自动校验。一个 ALTER PROCEDURE 执行完，没人知道改了哪一行逻辑，更没法回滚到上一版。
- 多人同时修改同一存储过程时，
CREATE OR REPLACE PROCEDURE会直接覆盖，无合并提示 - 上线前无法做单元测试：没有类似 JUnit 的数据库过程测试框架，只能靠人工构造数据跑通
- DBA 和开发权责模糊：开发想改逻辑要提工单等 DBA 执行，DBA 又不熟悉业务语义，容易误操作
跨库迁移和分布式分片场景下几乎不可用
MySQL 存储过程语法和 Oracle/PostgreSQL 差异极大，连最基础的变量声明（DECLARE v_id INT DEFAULT 0 vs DECLARE v_id INTEGER := 0）、空值判断（IS NULL vs IS NULLS FIRST）都不兼容。一旦要做多源适配或分库分表，所有存储过程都得重写。
- ShardingSphere 或 MyCat 等中间件不解析存储过程，
CALL proc_user_stat()会被路由到单个物理库，无法跨分片聚合 - 读写分离架构下，从库默认不执行写逻辑，但存储过程里混着
INSERT和SELECT，主从延迟会放大副作用 - 云数据库（如阿里云 RDS、腾讯云 CDB）通常限制创建存储过程权限，或禁用
log_bin_trust_function_creators导致无法启用
真正需要“靠近数据”的场景，有更轻量的替代方案
不是所有数据库端逻辑都要一刀切禁止，但优先选侵入性更低、可观测性更强的方式：
- 用
VIEW封装常用多表关联，避免重复写 JOIN；视图可版本化、可索引、可授权 - 用
GENERATED COLUMN自动计算字段（如full_name VARCHAR(100) AS (CONCAT(first_name, ' ', last_name)) STORED） - 简单原子操作用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO替代带事务的存储过程 - 定时统计类任务交给应用层调度器（如 XXL-JOB）+
SELECT ... INTO OUTFILE导出，而非长期驻留 DB 的过程
真正难的是把「哪些逻辑必须下推」和「哪些其实只是偷懒图省事」区分开——多数所谓“性能瓶颈”，本质是索引没建好、查询没拆解、连接没复用，而不是非得靠存储过程硬扛。
