存储过程与在代码里写逻辑的区别？大牛指教下

[clions]

办公室一帮人特别推崇在数据库里写存储过程，各种快，各种效率；但是在项目开发中也没怎么见过有写存储过程的，指点下目前的存储过程真的有那么优秀？需要点亮这个技能点不？

[xvx]

我不是大牛。

有些逻辑，存储过程能实现的，程序代码里面中是实现不了的……而且效率会比较高。
一般比较核心的逻辑，都是用存储过程实现的。我现在运维这个项目是这样的，其他的就不知道了。

[whx20202]

我不太懂数据库哈，随便讲讲，可能很多都是错的
存储过程我个人理解 最突出的两点：
1. 什么句法分析啊，执行计划啊 编译啊这些能又有点 /缓存 /省略之类的，能快一点
2. 流量逻辑之类的问题，可能一大堆数据得捞回来，代码里逻辑处理，再对数据库进行操作，而有了存储过程你可以直接在数据库端操作

但是我觉得现在 mysql 为例，第一点来说，普通 sql 执行， mysql 已经能缓存一大堆东西了，第二点存储过程可能还是有优点的。

所以是否真的需要还得看需求

另外有些公司用的是数据库平台，比如阿里巴巴的 idb ，或者因为搞了什么分库分表的系统（里面有路由啥的），有可能支持不好（我不说阿里支持不好）甚至要手动操作，或者增加使用成本；还就是有可能搞了存储过程后，迁移数据库不知道有没有成本

[brucewzp]

不写存储过程 dba 哪来 kpi

[kier]

最好别搞存储过程，否则到迁移数据的时候就麻烦了

[Numbcoder]

区别就是一个把逻辑写在数据库中，一个写在代码中
存储过程不好调试，不好维护，没有特殊需求尽量不要也没必要使用存储过程，如果你非要装逼，那我也拦不住你

[beginor]

一个是使用数据库服务器的运算能力，一个是使用应用服务器的计算能力。一般来说，应用服务器更容易横向扩展，所以应该更加倾向于在代码中写逻辑。

话说我上家就是全部把逻辑写在 SQL 中的，有 800 多个存储过程， 40%是超过 4000 行的，大家体会下这酸爽 😂

[zhangmiaoCHN]

代码更加易读一些，这点很重要。

[wmzt]

阿里是禁用存储过程的。原因是难以扩展，调试，没有移植性以及可读性差

[alqaz]

现在的项目就是很多逻辑写在存储过程里，刚开始接触也是一脸懵逼，说下感觉的唯一一个比较大的好处，热更新。至于说的调试问题，我们用的 mssql.调试倒没有不方便。

[wweir]

存储过程所谓的效率高、方便之类的话，都是基于单机这个情况来说的。
实际中，越核心的东西，越是难以做到水平拓展，即使拓展了，效率也是大打折扣。

应用层的东西可以轻松实现水平拓展，数据库想实现水平拓展却是一件非常困难的事。
所以，自己玩的、轻负载的项目，咋样都行。重型、高压力的项目，强烈建议应用层实现逻辑。

[pynix]

+ 降低数据库负载，纯存储。

+ 方便测试

+ 方便 scale

[kevin100702]

我目前的这个项目应该没少 2000 个存储过程，有空时统计一下

[huobazi]

存储过程不好做源代码管理

[zxiso]

放弃存储过程，通过业务服务器来写逻辑更容易降低数据库服务器的压力。毕竟随着数据量的变大，数据库服务器本身压力就不小了。。还要执行逻辑。。雪崩

[snnn]

小项目可以用。大数据库会压垮

[ryd994]

哪门子的快和效率？谁应用服务器是单点的？能并行化就能加钱解决。能加钱解决的，那都不是事。
只有特殊情况才值得考虑：在数据库里做，能显著降低输出的数据量的。不过真到了这一步你不考虑上缓存上反范式么？或者离数据库就近做个中间层也好啊

[bombless]

存储过程里面有一份逻辑之后这部分逻辑不在一个地方，以后业务改了得额外更新也是一种风险

[mingyun]

工作这么几年 未用过存储过程