在日常开展 MySQL 运维工作的过程中，常常会碰到这样一种状况。
研发部门的同学总是感到疑惑，他们经常问的一个问题是：
为什么在 Oracle 以及 Sql Server 这两种数据库里都能够使用存储过程，可一到 MySQL 这儿，却压根不让用了呢。
向 DBA 询问原因时，得到的回复往往只是说性能不行，但从来都没有详细地解释过具体是出于什么样的缘由才导致这样的情况出现。
要知道，存储过程在很多时候都起着重要的作用，它常常被用于封装业务逻辑，不仅有助于提升性能，而且还能让权限管理变得更加简便。
不过，就 MySQL 数据库而言，存储过程却没能得到广泛的应用。
接下来，这篇文章将会针对 MySQL 存储过程效率偏低的原因展开详细的剖析，同时也会对 Oracle 和 Sql Server 在实际运用当中存储过程的使用情况进行一番比较。
MySQL存储过程低效的原因
执行方式
MySQL 所采用的存储过程执行模式是逐行进行解释执行的，并非像某些其他数据库那样先经过编译然后再运行。
也就是说，在其存储过程当中的每一条 SQL 语句，都得在实际运行的过程中按顺序逐步地去进行解析以及执行操作，正是这样的执行方式，致使它在性能方面与那些预编译的存储过程相比，存在着较大的差距，性能表现要差很多。
优化器
MySQL 配备的查询优化器存在一定的局限性，具体表现为它没办法针对存储过程里包含的多条 SQL 语句开展全局优化工作，而仅仅只能对每一条 SQL 语句进行单独的处理。
这种特性使得存储过程在面对较为复杂的业务逻辑时，很难充分发挥出高效的作用，没办法达到理想的性能优化效果。
内存
当存储过程运行的时候，服务器需要对额外的一些状态信息进行维护，而且随着存储过程被调用的频率不断升高，就很有可能造成服务器内存方面的消耗变得过大，进而对整个系统的整体性能产生不良影响，使得系统的运行效率有所下降。
功能不足
MySQL 的存储过程在功能方面相对比较薄弱，它并没有配备丰富多样的错误处理机制，同时在高级编程能力方面也有所欠缺，例如在高级的事务控制以及动态 SQL 支持等这些方面都是缺失的。
由于存在这些功能上的不足，导致其在复杂的应用场景之中，很难展现出良好的应对能力，表现得有些力不从心。
调试工具
MySQL 在存储过程的开发与调试工具方面存在欠缺，没有一套完善的相关工具。而缺少这些工具的支持，使得开发人员在对复杂逻辑进行开发调试的时候会面临诸多困难，这种情况进一步对存储过程在实际应用当中的推广和使用造成了阻碍。
Oracle和Sql Server能否大量使用存储过程
Sql Server
存储过程称得上是性能优化方面极为重要的一个工具。Sql Server 为存储过程给予了很不错的支持，在其存储过程执行之前，系统会预先将它编译成为高效的执行计划。在实际的应用场景里，Sql Server存储过程有着颇为广泛的应用，具体体现如下：
- 复杂业务逻辑封装：把涉及数据操作的相关逻辑汇聚到服务器端进行统一处理，如此一来，能够有效削减应用层代码所具有的复杂程度。
- 减少网络传输：借助一次调用便可以完成那些较为复杂的操作，进而使客户端和服务器之间在通信方面所产生的开销得以降低。
- 增强安全性：利用存储过程能够把底层表结构以及敏感数据隐藏起来，以此增强整体的安全性。
- 易于维护：由于存储过程是进行集中管理的，所以当需要对业务逻辑做出更新时，操作起来会更加高效便捷。
Oracle
PL/SQL 具备强大的功能且有着极为广泛的应用范围。
PL/SQL 属于一种功能十分强大的存储过程语言，在众多企业级应用场景里都有着广泛的运用，具体体现如下：
- 企业级事务管理：其存储过程融合了高级的事务控制功能，这种特性使其特别契合高并发的金融、银行这类对事务处理要求严苛的应用场景，能够很好地应对其中复杂的事务管理需求。
- 复杂数据处理：当面临大数据量的计算任务以及需要进行批量操作时，PL/SQL 所展现出来的性能优势以及操作灵活性，是其他语言很难与之相媲美的，它可以出色地完成各类复杂的数据处理工作。
- 工具支持丰富：Oracle 为 PL/SQL 提供了一整套完善的相关工具，涵盖了调试工具、用于性能优化的工具以及各类开发工具等，这些工具的存在大大降低了开发人员使用存储过程的难度，让使用过程变得更加便捷高效。
对比
建议
简单业务逻辑
倘若业务逻辑仅仅牵涉到较为简单的 SQL 调用，并且只需要进行少量的逻辑方面的处理工作，那么比较推荐的做法是直接在应用层对相关逻辑进行封装，而不是依靠存储过程来完成此项工作。
复杂逻辑与高性能需求
在 Sql Server 以及 Oracle 这两种数据库环境当中，要是遇到需要封装复杂逻辑的情况，存储过程会是优先选择的方案。特别是处于高并发的应用场景之下时，存储过程在性能优化以及保障安全性这两个方面所展现出来的优势是相当显著的。
MySQL 的替代方案
就 MySQL 数据库而言，建议采用应用层代码以及经过优化的 SQL 查询来取代存储过程。要是存在数据分析方面的业务需求，那么可以考虑把数据同步到那些更契合大数据分析的平台或者工具上去，例如 TiDB、Hadoop、ClickHouse 等等。 标签：存储,Sql,Server,SQL,MySQL,过程 From： https://www.cnblogs.com/gdjgs/p/18611509