程序员过关斩将--你为何还在用存储过程？

存储过程

存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，它存储在数据库中，一次编译后永久有效，用户经过指定存储过程的名字并给出参数（若是该存储过程带有参数）来执行它。存储过程是数据库中的一个重要对象。

优点

1. 能够减小程序在调用DB时候的信息传输量（其实减小的只有Request的时候）
2. 存储过程是预先优化和预编译的，节省每次运行编译的时间，因此通常状况下认为存储过程的性能是优于sql语句的。
3. 对调用者能够隐藏数据库的复杂性，将数据组装的过程封装。
4. 参数化的存储过程能够防止SQL注入式攻击，并且能够将Grant、Deny以及Revoke权限应用于存储过程。
5. 若是业务开发中，数据人员和业务代码人员是分离的，业务人员能够不用关心数据，直接调用存储过程，更加面向分层开发设计理念。

劣势

1. 存储过程这种“一次优化，屡次使用”的策略节省了每次执行时候编译的时间，但也是该策略致使了一个致命的缺点：可能会使用错误的执行计划。
2. 存储过程难以调试，虽然有些DB提供了调试功能，可是通常的帐号根本就没有那种权限，更况且线上的数据库不可能会给你调试权限的，再进一步就算能调试效果也比程序的调试效果要差不少。
3. 可移植性差，当碰到切换数据种类的时候，存储过程基本就会歇菜。
4. 若是业务数据模型有变更，存储过程必须跟着业务代码一块儿更改，若是是大型项目，这种改动是空前的，是要命的。

不推荐存储过程

以上存储过程的优缺点，你随便一下网络就可能查到，表面看来存储过程的优点仍是很多的，这也说明为何老一辈程序员有不少喜欢写存储过程。可是随着软件行业业务日益复杂化，存储过程如今在复杂业务面前其实有点有心无力。

菜菜在业务中并不推荐使用存储过程,辩驳请留言

1. 采用存储过程操做数据在网络数据量传输上确实比直接使用sql语句要少不少，但这一般并非操做数据系统性能的瓶颈，在一次操做数据的过程当中，假设用时100毫秒，采用存储过程节省数据传输时间0.5毫秒（就算是5毫秒），我以为这点时间基本能够忽略。
2. 存储过程是只优化一次的，这有时候偏偏是个缺陷。有的时候随着数据量的增长或者数据结构的变化，原来存储过程选择的执行计划也许并非最优的了，因此这个时候须要手动干预或者从新编译了，而何时执行计划不是最优的了这个平衡点，预先没法知晓，这就致使了有些应用忽然会变慢，程序员处于懵逼的状态。
3. 存储过程确实能够对调用方隐藏数据库的细节，可是这种业务代码人员和数据库设计人员是两个团队的状况又有多少呢，若是真是两个团队，那业务就须要两个团队来理解和沟通，我想沟通的成本也必定很高，并且分歧更容易产生。

菜菜认为数据库就应该作它最擅长的事情：存储相关。我不止一次的看过把业务写在存储过程的状况，程序代码层面真是薄薄的贫血层，就是一个数据的透传。我不赞同这种写法，由于我就接手过这样的程序，令我头疼的不是业务，而是看着好几千行的存储过程熟悉业务，关键尚未调试的权限（线上更不能调试）。

一个业务系统的设计每每须要你从数据库的层面抽离出来，把主要精力放在业务模型的设计上，在程序层面体现业务逻辑，而不是把业务逻辑都交给数据层面的管理者。前几天我排查过一个“Bug”：存储过程是输入参数是一个主键id的列表字符串，长度竟然是 nvarchar（max），主要功能是根据id列表查询数据。我想说的是就算你是max的长度，也有超长的可能性发生，由于业务方传输什么参数，参数什么长度是你DB没法控制的，因此这类的业务必定要放在程序中作处理，而不是怀着侥幸内心丢给DB。

若是是抱着存储过程性能高的心态的话，我到时觉你这是误入歧途，菜菜认为存储过程历来都不是提升性能的关键，反而系统的架构，缓存的设计，数据一致性更是系统关键问题。

存储过程一般是一种解决方案，可是一般状况下不是惟一的解决方案，在选择存储过程做为方案前，请确保他们是正确的选择。

最后秀一波存储过程吧

---

添加关注，查看更精美版本，收获更多精彩