存储过程的本质是使用逻辑控制语句组合n个SQL语句，封装成一个组件。
使用场景：
较多复杂的数据操作和较大开发系统项目。如果在该情景下不适用存储过程，需要多次数据库连接。
优势：
1.调用存储过程只需要一次数据库连接。
2.缩短响应时间，减少网络传输流量（节省了多次数据库连接所需要的网络连接和等待时间）。
3. 提高系统稳定性。程序容易出现BUG，而存储过程，只要数据库不出现问题，基本上是不会出现什么问题的。
4.提高执行效率（存储过程只要编译一次，一般 SQL 语句每执行一次就编译一次）
5.安全性更高。只有用户获得存储过程授权，才可以执行。
当面试官问你有没有用过存储过程的目的
数据量小的，或者和钱没关系的项目不用存储过程也可以正常运作。mysql 的存储过程还有待实际测试。如果是正式项目，建议你用 sql server 或 oracle 的存储过程。数据与数据之间打交道的话，过程会比程序来的快的多。面试官问有没有用存储，实际上就是想知道前来面试的程序员到底做过数据量大的项目没。如果是培训出来的，或者小项目小公司出来的，对存储肯定接触的少了。
所以，要想进大公司，没有丰富存储过程经验，是不行的。
但是又不是万事要存储过程（缺点）
1. 运行速度：大多数高级的数据库系统都有statement cache的，所以编译sql的花费没什么影响。但是执行存储过程要比直接执行sql花费更多（检查权限等），所以对于很简单的sql，存储过程没有什么优势。2. 网络负荷：如果在存储过程中没有多次数据交互，那么实际上网络传输量和直接sql是一样的。
3. 团队开发：很遗憾，比起成熟的IDE，没有什么很好存储过程的IDE工具来支持，也就是说，这些必须手工完成。
4. 安全机制：对于传统的C/S结构，连接数据库的用户可以不同，所以安全机制有用；但是在web的三层架构中，数据库用户不是给用户用的，所以基本上，只有一个用户，拥有所有权限（最多还有一个开发用户）。这个时候，安全机制有点多余。5. 用户满意：实际上这个只是要将访问数据库的接口统一，是用存储过程，还是EJB，没太大关系，也就是说，在三层结构中，单独设计出一个数据访问层，同样能实现这个目标。
6. 开发调试：一样由于IDE的问题，存储过程的开发调试要比一般程序困难（老版本DB2还只能用C写存储过程，更是一个灾难）。
7. 移植性：算了，这个不用提，反正一般的应用总是绑定某个数据库的，不然就无法靠优化数据库访问来提高性能了。
8. 维护性：的确，存储过程有些时候比程序容易维护，这是因为可以实时更新DB端的存储过程，但是在3层结构下，更新server端的数据访问层一样能实现这个目标，可惜现在很多平台不支持实时更新而已。
原则：
所有数据访问在应用层封装为数据访问层，在那里，如果SQL简单的话，直接用SQL；如果SQL复杂，或者数据交互多且中间数据最后不会用到，使用存储过程。本文取自于一下博客，以自己的角度做了适当的文字编辑：
http://blog.csdn.net/defonds/article/details/4349922
http://blog.csdn.net/jackmacro/article/details/5688687
http://blog.csdn.net/zy1691/article/details/3742780