@
bleepbloop >存储过程也能拆吧，DBA 和后端配合好就行啊。
存储过程再怎么拆也是在同一台数据库主机上运行吧？
业务代码可以拆分为单个服务，在不同节点上运行。
>于你说的业务代码可以熔断，使用存储过程的时候业务代码为什么做不到熔断？
存储过程中如果如果跑复杂逻辑处理，导致数据库主机 CPU/IO 跑满了的时候，整个 DB 基本就挂了，业务熔断和不熔断意义已经不大了。
但是如果把业务处理流程交给业务代码进行，某部分的处理流程挂起时，通过熔断的方式，还能避免其余业务同时被挂起。
加上#51 所提到的，当你需要使用数组 map 之类的，存储过程中只能通过临时表来解决，临时表的创建 /销毁等开销 无疑也是增加了数据库的负担吧？
>阿里说的不一定就是对的吧？维护移植性不好这一点我也没看明白。
其实很多东西没对错只有是否适合，阿里说的也仅仅是对于他们。对我们只有参考性。
维护不好维护这点应该好理解吧，业务代码我可以通过热重载来进行更新。也可以通过基于版本号访问来进行。我需要改动的只有业务代码这块；
如果通过存储过程，如何实现这部分？
mysql 集群场景下，存储过程好像不会自动分发吧？(这个我没把握，不清楚。
然后移植性不好这点，就更容易理解了吧？
比方去 IOE，当初如果存储过程是通过 oracle 编写的，
数据库换为 MYSQL，存储过程是否需要做兼容 /重写？
但是业务代码中，只要 SQL 代码不使用某数据库的特性来进行，数据库怎么换(常规数据库)，基本业务代码部分也不需要修改。
当然了，上述提到的问题不全面，也有可能并非所有项目都会遇到这种场景，
但是该发生的还是会发生，既然存在缺点，优点又不太明显，为何不放弃这种做法呢？
-------------------------------------------------
另外我看过的一般都是.net 的 C/S 架构会使用 sqlserver 的函数进行一堆业务处理居多。
C/S 架构不是我强项我不讨论，上述提到的基本是基于 B/S 架构下的情况。