一、什么是存储过程

存储过程（Stored Procedure）是在数据库中，一组为了完成特定功能的SQL 语句集，它存储在数据库中，一次编译后永久有效，用户通过指定存储过程的名字并给出参数（可选）来执行

存储过程的优点

  • 预编译SQL，提升执行效率
  • 可以隐藏执行逻辑，只暴露名称和参数
  • 相较于程序来说，修改起来更加便捷

存储过程的缺点

  • 随着SQL行数的增加，维护复杂度呈线性提升
  • 无法调试，迭代过程中风险较高

二、存储过程的使用思路

提升交付效率

这也是以为存储过程的优点：保存在数据库中，当逻辑需要修改的时候，只需要连接到数据库，修改保存即可，如果逻辑写在程序中，那么就需要编译、打包，部署，尤其是部署的过程会比较麻烦，如果是单台服务器，那么发布的过程中可能会影响用户的使用，如果是多台服务器，那么还需要一台台发布。

对比下来，修改存储过程比修改程序可能要节省30分钟以上的时间

面向数据库开发

关系型数据库中都有完备的用户权限系统，在较为早期ToB的软件系统中，会将有一定商业价值的逻辑以存储过程的方式提供，在软件中只存在存储过程的名称跟参数，软件的开发人员以及甲方的二次开发、对接人员是不接触相关逻辑的，而且这个存储过程还是加密的（SQL Server、Oracle是支持的），程序中只能访问执行存储过程，而且程序中访问数据库的账号，也只有存储过程的执行权限，没有其他权限

这样也可以通过DBA跟Developer的分工，加快开发速度，不过，这已经是过去式了，现在ToB的系统，基本上都已经上云了。

三、到底要不要用存储过程

简单业务系统

如果你开发的是个小系统，没多少业务流程，整体项目只有1个站点或者软件，这个系统的用户量、数据量都很少（例如：个人博客、企业网站、工单系统等），那么把逻辑写在存储过程中，如果碰到问题，可以快速修复，那么在大部分情况下是利大于弊的

复杂业务系统

如果你开发的是有较多业务流程的系统，无论是ToC的电商系统，还是ToB的ERP、CRM、HRM，无论系统承载数据量如何，我都不建议使用存储过程来实现业务逻辑，因为这样的系统业务流程较多，如果将大部分业务逻辑写在存储过程中，随着系统和业务的发展，十几行的存储过程，可能会发展成几十行，几百行甚至上千行，那么为维护，谁头秃~

很简单，存储过程没有现成的调试功能，如果在更新过程中，语法出错，SQL设计器会帮你拦截，但是语法没问题，逻辑出了问题，保存之后，那就会产生一堆脏数据，
就修复数据，就能让人崩溃，更别提造成了业务损失，那可是真金白银就没了

另外，随着系统的发展，如果你是单库单表，随着用户量的增长，单一数据库表无法支撑业务，那么就要做数据库的水平拆分，到时候存储过程全部需要修改测试，就算修改测试通过了，没出问题，那么以后多个库要在同一时间保证存储过程都是一样的逻辑，怎么办？

四、总结

我坚决反对在商业项目中使用存储过程执行业务逻辑

虽然存储过程有诸多优点，在简单业务系统中也可以提高交付效率，但是这在我看来是饮鸩止渴，因为业务和系统总是要发展的，一旦业务和数据量发展到一定程度，贼船难下，为时已晚

如果你真的想在项目中使用存储过程，那就祈祷写存储过程的人都很靠谱，写出来的SQL都很易读，也不会在存储过程中写过于复杂的逻辑，也还好祈祷这个业务/系统不要发展的太好，不然，头发迟早不够用的~

如果是你的个人项目，用不用数据库都无所谓无所谓

永远不要和魔鬼做交易