打开帖子直接一张醒目的图，是阿里巴巴的Java开发手册对Mysql相关的要求。
存储过程没有版本控制，版本迭代的时候要更新很麻烦。存储过程如果和外部程序结合起来用，更新的时候很难无感升级，可能需要停服。存储过程不利于将来分库分表。存储过程的功能不一定够强大，业务扩展之后可能会发现无法继续用存储过程实现了。存储过程可能无法和许多中间件、ORM库一起使用。某些特殊的兼容MySQL的实现可能根本就不支持存储过程，那就更不用说了。
这也不绝对，在微软的时候就有项目是反过来的，所有业务都需要用存储过程写在SQL Server里面，查询全写成视图，业务代码只允许使用视图和存储过程，只要SELECT和EXECUTE权限就够了；修改业务只需要登服务器改存储过程。这属于思路不同。
吴啊
任何技术都要分使用场景，阿里这种互联网高并发的场景，很多数据都是分库分表的，而且要求高度可扩展，原则是对db的保护做到最大化，能减少db压力的就减少db压力，尽量把运算逻辑拉到代码里面。存储过程的优点在于封装性好，直接让db进行运算，但是缺点在于难以维护，而且大大增大db压力。所以开发过程中禁止使用存储过程也是阿里多年经验积累出来的。
孤尽[《阿里巴巴JAVA开发手册》主要作者]
解释一下这个事情：曾经写过近1200行的存储过程，没有办法断点，下层数据结构只是稍微变动，根本无法找到出错点，只是提示一下说：ERROR:1064啥的。在数据库迁移的时候，由于数据库版本变更，居然存储过程无法执行。另外，业务上需要扩展一下，那就是灾难性的啊。没想到，我觉得毫无争议的这一条，反而成了一个最大的争议点。存储过程只是单机时代的产物，并不适合互联网时代。
陈曦
小公司还好，大公司对db把控很严格。分别说下：调试：线上调试一般就是打日志，在应用层，日志可以在任何一步打，但是存储过程的话，日志没法跟踪详细的执行过程。扩展：譬如你的 产品购买流程 要增加一个动作，这时候就要修改存储过程到db里，你这时候要直接操作db，而在大公司，直接操作db只能有dba来进行，其他都要审批后使用公司自己开发的工作来进行，且只能是简单的crud。移植：你用mysql写的存储过程，到了sqlserver不一定能直接用。但是在应用层的话，程序里的crud的基础sql基本上通用的，修改下连接串一般就ok了。
