不少程序员都在纠结：写存储过程到底好不好，到底算不算防御性编程？今天咱就来唠唠这个面试中产隔壁问到的关于存储过程的优缺点有哪些问题。

存储过程在公司开发规范中的现状

现在很多公司都把禁止使用存储过程写进了开发规范里，一旦发现有人用，那可是要严肃处理的。为啥会这样呢？我就有切身体会。之前我接手过一个项目，好家伙，里面的存储过程多得吓人，大大小小得有几十个。这些存储过程，有长有短，逻辑也是有简单有复杂。而且项目里Java代码量不算多，好多复杂业务逻辑都被写进了存储过程里。

我印象特别深刻，有个存储过程居然长达1000多行。里面各种判断条件、计算公式，还有些代码看着像“火星文”一样，让人摸不着头脑。就算有注释，也很难理解它到底是干啥的。关键是还没办法断点调试，要是让改其中一小段逻辑，根本就不知道从哪儿下手，我当时都不敢轻易去动它。以前觉得Java代码写得乱糟糟的就是“屎山”了，看到这个存储过程，才知道啥叫“王者级屎山”。

存储过程的定义及实际问题

从定义上来说，存储过程就是在关系型数据库里存一段能重复执行的代码。这段代码里可以有SQL查询语句、条件判断语句，还能写循环，主要用来执行一系列数据库操作。听起来好像挺方便，但实际上这里面有“坑”。要是真把业务逻辑一股脑全写进存储过程里，那这个存储过程除了注释，基本就没啥可读性了。遇到复杂逻辑的时候，连个日志都打不了，更别提debug调试了，后期维护简直就是噩梦。

打个比方，你就把存储过程想象成一个密封的黑盒子，你只知道它能干活，但具体怎么干的，出了问题怎么修，完全摸不着头脑。不像我们写Java代码，出了问题还能一步步调试找原因。

存储过程在扩展性和性能调优方面的局限

存储过程在扩展性方面也不太给力，调优空间有限。比如说，当用户量增加，系统性能下降，需要做优化的时候，在Java代码里，我们可以用缓存、消息队列，或者像ES（Elasticsearch）这种降级方案来提升性能。但存储过程就只能依赖数据库自身的性能，可选择的优化手段少之又少。

存储过程并非一无是处

不过话说回来，存储过程也不是一点儿优点都没有。把一堆SQL语句打包在数据库层面一起执行，确实能减少应用程序和数据库之间的交互次数，在一定程度上提高了效率。这也算是它为数不多的闪光点了。

写存储过程很难简单地定义为防御性编程。虽然它有提高执行效率的优点，但从维护难度、扩展性等方面来看，弊端也很明显。在实际开发中，大家还是得根据项目的具体情况，慎重决定要不要使用存储过程。要是你对这方面还有啥疑问，欢迎在评论区留言，咱们一起讨论讨论！