老大说不要在项目中使用存储过程

小伙伴想精准查找自己想看的MySQL文章→ MySQL专栏目录 | 点击这里

说在前面，本文不属于教学贴，属于技术讨论贴，对这个问题，我也持学习态度。本文在存储过程技术使用方面不进行赘述，需要声明的是，任何技术都是双刃剑，不能搞一刀切。
农历2022年的第一篇文章，给大家拜个年。虎年大吉，一起暴富！祝冬奥会顺利落幕，中国加油！

其实这些问题在使用之前我都了解，在（下面我统称为手册）中也有提到，坚持使用倒不是为了显摆，而是对存储过程到底我还有些想不通。我对待技术选型，坚持以实际业务场景为依据，不能一刀切，在我们项目中存在15%左右的业务逻辑有强相关属性，有一定并发度，这里引入存储过程我认为并不失礼。如果揉在一起，在实际应用中连接次数会明显增高，一定程度上影响效率，当然也避免了同事们不想看到的问题。

作为技术人，我不愿看到因为xxx问题而直接拒接xxx技术这种情况，该篇文章是网上多方技术人针对这个问题的一些见解，我挑选了一些比较高赞或有效的回答，做个分享，能耐心看完的同学，我相信你会留下自己的看法。

• 灵剑

存储过程没有版本控制，版本迭代的时候要更新很麻烦。存储过程如果和外部程序结合起来用，更新的时候很难无感升级，可能需要停服。存储过程的功能不一定够强大，业务扩展之后可能会发现无法继续用存储过程实现了。存储过程可能无法和许多中间件、ORM库一起使用。某些特殊的兼容MySQL的实现可能根本就不支持存储过程，那就更不用说了。

这也不绝对，在微软的时候就有项目是反过来的，所有业务都需要用存储过程写在SQLServer里面，查询全写成视图，业务代码只允许使用视图和存储过程，修改业务只需要登服务器改存储过程。这属于思路不同。

• 精致的喷火住

10年前刚刚毕业，上班的时候，视图、存储过程、外健，能用的都用。。。现在数据库只存数据，其他啥也不干。

• 不悟正业

这是针对互联网企业的规则。单次请求涉及数据少，数据关系简单，但是更新频率高；

工程的迭代速率高，数据关系随时可能扩展修改。

ERP开发面对的情况是经常要大批量的处理数据，表都很大，表关系也复杂，十几个表关联不是什么大不了的情况。数据处理流程长，不用存储过程只会让事情更加复杂。

ERP中对数据库请求量相比互联网企业来说是非常低的，相对不用太关心数据库压力问题，这种时候把一些操作放到数据存储过程里可以兼顾效率和开发成本。

• 孤尽[《阿里巴巴JAVA开发手册》主要作者]

解释一下这个事情：曾经写过近1200行的存储过程，没有办法断点，下层数据结构只是稍微变动，根本无法找到出错点，只是提示一下说：ERROR:1064啥的。在数据库迁移的时候，由于数据库版本变更，居然存储过程无法执行。另外，业务上需要扩展一下，那就是灾难性的啊。

没想到，我觉得毫无争议的这一条，反而成了一个最大的争议点。存储过程只是单机时代的产物，并不适合互联网时代。

• 阿里云云栖号

任何软件开发语言都是一种“绑定”或者说“限制”，一旦使用了一种语言开发出来的应用，就会很难迁移到另一种语言。虽然并非绝对，大部分情况下如此。

回到问题本身，“Java开发手册”就注定了已经绑定在Java语言上了。但是你的应用要绑定多少中语言呢了“Java”之外，是否还要绑定另外一种语言，比如用来写存储过程的各种“XXSQL”/p>

一旦使用了存储过程，至少有三种潜在的“技术债务”是要考虑的：

1. 多绑定了一种语言，因此无法容易的迁移到另一种数据库上，例如Oracle的存储过程就无法用于MySQL
2. 多了一种程序语言，技术栈就提升了复杂度，对调试、测试、集成等等就会增加工作量和复杂度
3. 存储过程和Java不是一种类型的语言，因此需要有专业的知识（和人员，以及人员带来的支出）来维护这部分程序最重要的是，存储过程不是面向对象的，Java和存储过程都精通的人不好找，就算有，也很贵。

• 暴疯

抛开场景谈规范都是耍流氓。

以我的经验管理超过3000张表，使用周期超过20年的库、数据库逻辑、包括外键 、强制约束、存储过程接口是完全必须合理的。

一个大库很多公司用，你指望应用层约束就是搞笑。天天说换db，我看到是 pb vb asp java 各个几年就变了，公司在不在还不一定呢。

同样的逻辑过程里写一份就好了，各种语言都能用。

大量数据分析，把数据从数据库读出去，在写回去累不累会调试、不会写就去多练练。过程一样可以写的很优雅，水平问题而已。

来源：_陈哈哈