存储过程真的是洪水猛兽吗？

[liuidetmks]

很多开发者一提到 SQL 就“谈此色变”，觉得难以调试、难以定位 bug
最后就是一句话，就是这个东西碰不得，是邪教。

---

存储过程这个东西存在这么久，不可能一无是处吧

有没有可能，像 TypeScript 转译为 JavaScript 一样，有一种高级语言可以：

• 编译成各类数据库支持的 SQL （比如 PostgreSQL 、SQL Server 等）；

• 根据目标数据库的特性自动优化生成对应代码；

• 如果使用了目标数据库不支持的语法，比如在目标是 PostgreSQL 时用到了 SQL Server 的专有语法，那么编译器应能直接报错并给出明确提示；

  最好还能在开发阶段提供类型检查、智能提示和跨平台兼容性检查。

[cxe2v]

出来多少年的 ORM 框架不就是你要的东西

[lpxxn]

100%洪水猛兽

[zhanlanhuizhang]

没有吧，公司里面所有的系统都用了。

[Debug1998]

我维护过离职人员写的存储过程，这个东西的使用，我有两个问题：1. 执行出了问题，只能写表记录异常、错误信息？ 2. 存储过程和 Java 等语言实现相同的功能，在代码上存储过程是否更不易理解。

[zjsxwc]

有
就是全球最大的 ERP 软件，德国思爱普 SAP 的 abap 语言。

abap 就是进阶版本的 SQL 语言，这个 sql 语言不但能操作数据库，还能用来描述用户交互界面。

[MuSeCanYang]

存储过程的逻辑，在我们这占了最起码 30%
稍微复杂一点的数据交互，不用存储过程，慢的要死。

[spritecn]

甚至 xml 都是洪水猛兽,超过 5 行根本看不懂,存储的语法和 bat,shell 有得一比,一般人看不懂,不像 java,python 那么直接

[felixcode]

有学习门槛的东西，都有可能被找借口躲避

[xiangbohua]

不会用不好管理而已，实际上用的好的话，性能很不错

[cheng6563]

当项目管理起来还行，不管理直接上数据库随便改那就是洪水猛兽。

[sanmaozhao]

存储过程还有一个问题：可移植性差
如果需要支持不同的数据库，一般就没法用存储过程了

[msg7086]

不同的东西有不同的使用场景啊。
说是邪教的，无非是因为他们的使用场景不适合用存储过程罢了。
给你一台 1TB 内存 128 核心的服务器跑 Oracle 数据库，用户数量就 1 万人，业务逻辑常年不多变，你告诉我为啥不用存储过程。

[iugo]

如果存储过程和后端的业务逻辑是两班人马写, 并且 存储过程 可以静态分析, 那么 存储过程 才可以接受.

性能问题, 更应该用别的方式优化, 比如调整结构, 异步, 分布式, 缓存等.

[SupperHobby]

银行都是存储过程

[forbreak]

个人觉得存储过程的问题，主要还是团队人数太多的时候，管理不善带来的。 新旧人员交接，互相关联的业务多个存储过程和代码里面的业务交叉影响等。 存储过程本身倒是没什么大问题。

[sagaxu]

哪个高级语言没有操作 DB 的 DSL ？完全满足你这几个要求。

谈 SQL 色变，那是因为不熟悉，系统性学过 SQL 的开发者很少，给存储过程加过断点的更少。

[eraserrain]

你好是的，debug 和版本管理简直灾难，虽然有时候设一些 sp 和 trigger 还蛮好用的

[lujiaxing]

看情况. 对于互联网企业来说, 存储过程本身就是没必要的. 互联网企业本身业务非常简单, 几乎无外乎 CURD.
但是对于 SAP, 用友, 久其, 任我行那些 ERP 系统, 以及四通一达的那些 WMS 系统来说, 存储过程就是解决复杂需求的利器. 哦对, 也包括电信运营商与银行. 它们的存储过程更加复杂, 但存储过程对他们来说也往往是必然的选择.


业务逻辑越是复杂, 存储过程的就越是有存在的必要.

哦对, 铁路的 TRS 后面的业务逻辑全都是存储过程.

[totoro52]

等你维护到几百个储存过程的古老项目就知道了，每天写代码都感觉自己在学习黑魔法

[xdzhang]

我这里还有一套系统全是视图存储过程触发器，其中有些看都不想看。

[roundgis]

當然不是

大把內部系統就是兩層架構

客戶端直連數據庫 邏輯就是存儲過程

[Mrun]

因为国内大部分公司的业务就是 MySQL 撑起来的，绝大多数程序员写了十几年的代码，都极少接触 MySQL 之外的数据库。
稍微复杂的公司业务，比如银行电信，特别是 ERP 之类的，核心业务系统谁没事用 MySQL 这种弱鸡数据库

[roundgis]

@totoro52 也不容易被炒

[fffq]

不是，学习成本罢了

[yvyvyv]

感觉是时代变化了，我进的第一家公司就有大量的存储过程，函数，触发器。那些基本上都是 08-12 年间留下来的代码。后来的观念就是重视程序，尽量不依赖数据库处理逻辑。现在所在的公司已经完全没有数据库层面的逻辑了

[skydcnmana]

我不用它完全是觉得这玩意就是石器时代工具，连关系数据库都是过于原始了。

[pkoukk]

你司有一大群 DBA 么？没有就别用
上面说某些行业有用的，你看看他们有多少 DBA ，或者每年花多少钱从 Oracle 买 DBA 服务

[wetalk]

一个是难维护，另外难以横向扩展，说人话就是不容易通过加机器解决性能瓶颈

[carytseng]

主要是维护困难，假如你是接手的程序，出了数据问题让你排查，给你一段过千行的 sql ，重新阅读理解排查，那滋味儿酸爽

[zbatman]

我认为存储过程不是优势，而是无奈

[bk201]

并不那么绝对吧，一切技术的应用都看场景，但是一般情况下，都没有必要使用存储过程。

[dlmy]

存储过程就是洪水猛兽。

大学刚毕业进了某头部保险公司，做的项目是收付系统，核心业务是 “核算 核销 对账”，这些核心功能全部由 Oracle 存储过程实现，SQL 总行数在 5w 行左右，涉及到 90 多张表，其中最大的一张表 495 个字段。

当领导安排我来核算几亿条保单数据的收付情况时，面对上万行的存储过程，我人直接傻了，恨不得马上离职，这也成为了我职场上一辈子的心理阴影......

[werls]

写的时候是非常的开心，但是不要叫我维护，或者解决 bug 。那可不行

[dlmy]

@totoro52 同意，我曾经维护过 5w 多行存储过程，涉及到 90 多张表，最大的表 495 个字段

[cenbiq]

存储过程 极度违反 存储与业务分离

[pipixiarwksb]

@sanmaozhao #11 这句话是真的 迁移的过程能多混几个工作日可能都不止

[Felldeadbird]

存储过程也不是洪水猛兽，没有 DBA 的公司，开发者写存储过程后，他离职了没人记得这玩意。后面接手的人可能永远不知道这玩意存在。

[tanhui2333]

不要开历史倒车

[sumu]

项目中整了几个，多年维护下来：极其的好用，极其的反人类

[back0893]

不知道 这有文档么?
没有文档前提下能有代码容易看懂么?

[lujiaxing]

@tanhui2333 这个不是开历史倒车. 是有些场景下只有存储过程合适. 在大并发高一致性高实时性的场景. 比如银行. 你不可能说这边支付完了过了好几秒余额才减掉吧.

[Rickkkkkkk]

你都招不到会用这个东西的人。

[idragonet]

我们 MES 都是存储过程，6-7K 个。 无所谓了，职场都有工具人。

[frankies]

看行业的，比如银行、ERP 系统、财务管理系统这些，存储过程是大量使用的。而互联网行业，我认为如无必要坚决不使用存储过程。

[xiaomushen]

你自己写的时候，绝对不会认为是洪水猛兽。
等接手的人维护修改时候，绝对会喷这是洪水猛兽

所以，是不是洪水猛兽，要看站在谁的角度

[leonhao]

数据量大，业务逻辑复杂，存储过程非常好用

[yangzzzzzz]

之前公司的架构师设计的前端直接掉存储过程，设想非常好，实际应用中 一个简单的见面掉几十上百个过程 ，前端人都麻了

[ericguo]

到 2025 年为止，我还找不到一个编程语言，除了存储过程，能够在 0.5 秒内改变系统的逻辑，不用发布，不用测试，走任何流程，不留下任何记录，而且门槛极低。

如果你认为上面我说的全是优点，那显然应该用。

[xiaomushen]

@ericguo 数据库可以开 Audit ，不可能不留任何记录

[xiaomushen]

@yangzzzzzz 类似的行为艺术架构师，还是有想法的：核心人员无法被裁

[imnpc]

没有专职 DBA ，不要用存储过程

[lujiaxing]

@imnpc 不一定 好多 30 多岁的老开发, 对数据库的理解可能比 DBA 还深刻.

[shangfabao]

你要是存储过程文档很详细,用就用了,前提有 DBA

[QlanQ]

以前 维护 ERP 的时候，就是前端用的那种 我都忘记叫什么了，就是前端直接调用数据库的存储过程
整个系统主要是依赖存储过程

维护、升级特别复杂，数据库绑定，绑定到版本，数据库如果语法有修改，存储过程都要重来

现在 接口系统，都是 分布式、数据业务分离，存储过程就不合适了

[catamaran]

存储过程的一个问题是 sql 没有普通的高级语言语法丰富，导致阅读书写代码要困难一些，然后 debug 比较困难，我知道 sql server 的 sp 是可以 debug 的，不知道 oracle 行不行，mysql 是不行的。

[ymy3232]

成本低，不用招专门的大数据开发，我们之前一天百亿条数据，用 8 个 mysql 来跑存储过程，成本比用数据湖低的多

[Nanmi]

曾经刚毕业的时候，在一家做银行软件的公司，那个时候用的也是存储过程，阅读起来极其费劲，维护特别困难，当然对于高手来说，也不是啥事儿，但是如果是对于初入职场的人来说，去维护一些边角料的功能你都会觉得很恶心🤢。

记得后面离职 1 年多的时候时候，这套核心系统终于被彻底重构了，存储过程的那部分逻辑全部用 java 重写了。

[bbao]

上一次看到这个词应该还是在 2009 年刚工作的时候～～～～

[bbao]

@lujiaxing 如果认识支付宝或者微信的同学，可以做一些咨询，看看他们用不用。

[lambdaq]

存储过程 不就是个 low code

[aureole999]

@lujiaxing 也不能这么说，像我以前做证券，一样有支付什么的啊，也不用存储过程。像支付宝什么的，也不见得非要用存储过程吧。

以前存储过程确实在这方面比较好用，所以用得多，后面人们慢慢发现了缺点就用得少了。但有些项目有历史包袱还是得接着用。如今微服务什么的，用得很多，现在缺点也逐渐暴露出来，以后怎么样还不知道。每个技术都有时代的局限性。

[wxf666]

@sanmaozhao #11
@pipixiarwksb #36

有 AI 的年代，改写成不同语言，应该都不是啥问题吧。。


@dlmy #32

5W SQL 转成编程语言实现，复杂性会降低多少呢？感觉 SQL 实现一般都更简短呀。。

[layxy]

搞不明白,明明代码可以处理,非要写存储过程,搞得代码逻辑处理一半,存储过程处理一半,徒增心智负担

[jeffreyWang007]

也很好奇，存储过程应该如何做版本管理？

[lujiaxing]

@aureole999 银行的账务逻辑比证券复杂多了.

[lesismal]

很多传统企业级、FinTech 用 IOE 之类的那套，量级不那么大，安全性第一，可以、但不是必须。

其他 ToC 尤其是国内这些：
1. 海量用户海量并发的，存储过程单点性能就不太合适了
2. 业务需求的快速迭代，存储过程开发和维护都是不合适的

国内很多企业去 IOE 的过程中，存储过程也越来越少、很多团队已经消灭存储过程了。

老屎山，能不动，就不动；
新项目，能不用，就不用。

[ZGame]

并不是,很难说现在的 flinksql 大数据那一套不算另一种方式的存储过程。 最主要是如何包装和平台化，让其他非开发人员也参与进来。 并且能够妥善的维护 而不是丢到数据库里就不管了。 所以还是屁股决定脑袋,你是 dba 还是开发 可能有不同的感受

[dabao]

你是不是在找“ORM”

[ytll21]

@lujiaxing #65 银行的账务逻辑比证券复杂多了.
---------------------
无法认同。都是语言，不存在只有存储过程才能对应的业务逻辑。

存储过程当初出现的原因，是因为大型机，以及前后端分离的技术不成熟。但是随着云计算的出现，算力已经不成为问题，那么存储过程的语言问题就变成了阻碍，无法方便的重构，调试和缺少语法糖，都是影响开发效率的存在。

现在还在用存储过程的企业，只能认为是有历史包袱在，迫不得已的选择。

[ytmsdy]

如果当年没有去 IOE 的运动，估计现在还有一大波的人在写存储过程。
存储过程写起来是爽，多表关联，批量更新，效率也非常高。大约 2014 年，2015 年之前的 ERP 系统，后面的业务逻辑基本上都是存储过程，银行系统，电力系统，大型企业的内部管理系统，基本上都是存储过程。
但是维护这玩意儿也是噩梦，没日志，debug 麻烦。有时候业务提交上来一个 bug ，你定位到了 bug 是在具体哪个存储过程导致的，然后要修这个 bug 的时候，有时候是很绝望的！
之前关于存储过程不是有这么一个冷笑话么，系统出现 bug 了，一个程序猿搞了两个礼拜，然后经理说，我现在有一个好消息和一个坏消息。好消息是我定位到了 bug 是在那个存储过程里面产生的，坏消息是这个存储过程有 3000 行。

[dabao]

@lujiaxing 经常帮老开发们优化数据库性能，存储过程写的屎一般，甚至表连个索引都没有，存储过程还用来各种抓取同步耗时且大量的数据

[ytmsdy]

@jeffreyWang007
做得好的公司会和普通代码一样，导出成 SQL ，然后上传 SVN 或者 git 。
做的不好的公司就直接运行发布了，最多在存储过程里面写一下注释，把之前的逻辑注释掉，然后写新的逻辑

[realpg]

本地那种商业软件放心用 0.1QPS 都没有的 无所谓性能

你给 1KQPS+的互联网服务大众的系统数据操作都扔存储过程里 大概率卡到地球另一边

[seansong]

存储过程比直接写在应用代码里面，更难以调试，版本控制也难，同时 pgSQL 之类的数据库语言的表达能力也显著弱于应用层语言，倒不是说存储过程不能用，只是必要性越来越低，出于熟悉程度、调试之类的考虑，就慢慢被越来越淘汰了

[yingqi1]

只要弄好 单元测试 / 版本管理，什么语言都无所谓。

[nuk]

如果是复杂的存储过程我们一般都是自动转译的，sql 基本没办法调试，没必要在上面浪费人力。

[xshell]

新功能都不让使用存储过程，老代码里面有存储过程让能正常运行就行·

[lujiaxing]

@ytll21 不用存储过程, 用程序处理的话, 终归会有反复与数据库交互的过程. 十次八次的还好, 像某些银行那样的系统, 一笔交易涉及各种跨库跨表查询几十个 (尤其有不少还涉及到本地服务, 如水电气缴费, 地方分行/支行企业合作业务, 自动扣费业务/罚款等), 反复与数据库交互的这个通讯的成本是很高的. 一般来说银行的各种交易必须在几百毫秒之内结束, 而且不可以出现单据不一致的情况. 这与互联网企业的最终一致性要求是不一样的. 银行, 电信系统之类的, 要求的都是实时强一致性. 在这种需求之下, 存储过程是最好的. 至于研发难度, 反正也不是老板需要面对的事情. 有难度你们研发慢慢啃去呗.

[lujiaxing]

@ytll21 当然, 如果系统没有这么强的一致性要求, 用存储过程就纯属是给自己找不自在.

[CoderGeek]

我现在碰到的 一个业务 代码 30%基本校验 参数传递 然后调存储过程 70%逻辑在哪里 不恶心吗 真的很恶心

[ala2008]

那存储过程要代码评审吗

[liuidetmks]

@zbatman 😂，看来手势返回的那个帖子冒犯到你了

[raptor]

存储过程是历史遗迹，曾经很有用，但现在只剩缺点了……

[tohuer00]

优点非常诱人，直接消除了网络 io ；缺点也足够致命，复杂场景那就是没法维护，不知道以后是否可以用 ai 来协助。要用好还真不是三言两语能说清楚的。

有些人扯 orm 是什么情况？这特么是同一个应用场景的东西？

[min]

主要看是多少行的存储过程

现在有 ai 了，维护起来应该会比以前简单一些

[wupher]

旧时代的 CS 平台经常是这么玩的。

主要逻辑以存储过程存在于 DB 中。Client 主要用于界面展示，数据计算及各种逻辑大都使用存储过程。

优点缺点都是有的，有维护开发的人可以说道很多，现在使用这种架构的仍然不少。

到 BS 时代后，一般改用代码，也是 ORM 框架了。

你写写就知道了，一堆 CS 相关产品的公司仍然在用，去试试就好。

[drafter]

可能受 DDD 影响，觉得存储过程这种东西太依赖对应的数据库了，而数据库一般都是可替换的，涉及到核心业务就非常危险了，像你说的，如果未来与一种高级语言支持各类数据库的存储过程，用这个高级语言去编写核心业务，这个是可以接受的。

[wysnxzm]

只要不用我维护那它就最棒

[CoderGeek]

一旦换个 db 存储模式 直接爆炸 代码都不知道咋写 😄

[mappple]

银行国产化了之后也不太用了

[liyafe1997]

脱离具体业务谈这个就是耍流氓

[cubecube]

如果是单体应用，未来扩展性也基本上一个 db 能抗住，那么存储过程其实是利器。写写注释即可。

[niubiman]

@fffq 还有维护成本，这可比学习成本带来的成本高太多了

[nthin0]

接手其他人写的存储过程做维护和加功能简直酸爽，天天骂娘

[JaysonHope]

@idragonet 我接触的 mes 系统，用存储过程的还是少，有的公司真的如楼主所言，谈此色变，命令禁止。我曾经为了不写存储过程，写查询语句写了 200 多行，关联 10 多张表。

[salmon5]

这个取决于出了问题谁负责，如果谁写的谁负责，那就 OK

[xiaomushen]

@salmon5 软件行业，又不像建筑行业那样，出了问题终身刑责。写存储过程的人离职了，你怎么办？

[xiaomushen]

@tohuer00 如果学建筑业那样，终身追责，事故入刑，那难维护的问题，应该会好一些。哈哈哈

[salmon5]

@xiaomushen #97 那存储过程是个偷懒的方案，应该禁止使用

[tongjiann]

我们公司现在在翻新之前的一个系统，之前是基于.NET 开发的，里面的核心逻辑全在存储过程里面，我每天看的都想辞职了