为什么MySQL不建议使用存储过程mysql不建议存储过程

一、为什么MySQL不建议使用存储过程mysql不建议存储过程

为什么MySQL不建议使用存储过程？

存储过程是一段可以被调用的SQL语句集合，可以实现复杂的业务逻辑和数据操作。然而，在MySQL中，存储过程并不是一种被广泛使用的数据处理方式，反而被建议避免使用。那么，为什么MySQL不建议使用存储过程呢？

存储过程需要在数据库中编写和存储，相比于应用程序的代码，存储过程的执行效率相对较低。这是因为存储过程的执行需要经过多次判断和查询，而且每次执行都需要从数据库中读取存储过程的定义。因此，如果存储过程的执行非常频繁，会给数据库带来较大的负担和性能瓶颈。

另外，存储过程的执行计划也可能得不到优化。数据库引擎在执行存储过程时，无法像对待普通SQL语句那样生成优化的查询计划，导致存储过程的执行效率较低。而且在存储过程中使用大量的代码也会导致性能降低。

存储过程的代码与应用程序代码不同，它们通常是在数据库端进行维护和升级。当业务逻辑发生变化时，需要修改存储过程的代码，并在数据库中重新定义。与应用程序相比，这种操作比较繁琐，可能导致维护困难。

此外，存储过程的修改也会对数据库的操作带来影响。新的存储过程可能需要重新编译和执行计划优化，这将占用数据库的大量资源，影响其它用户的操作。如果存储过程的代码出现严重的错误，可能会导致数据库服务的崩溃，影响应用程序的正常运行。

存储过程需要在数据库中定义和存储，这就意味着它们与数据库的权限和安全设置相关。如果存储过程的权限设置不当，可能会导致数据库的安全风险。例如，存储过程中可能包含敏感信息的读取和修改操作，如果存储过程的调用者权限设置不当，可能会发生数据泄露或操作不当的情况。

另外，存储过程也容易受到SQL注入的攻击。因为存储过程实际上是一种SQL语句集合，如果存储过程中存在SQL注入漏洞，攻击者可以直接调用存储过程获取或修改数据库中的数据，破坏数据库安全。

虽然存储过程具有一些优点，如能够减少网络传输、提高程序可重用性等，但在MySQL中，存储过程的使用并不被建议。除非应用场景需要使用存储过程，否则应该尽量避免使用。在实际开发过程中，可以通过其他方式来实现复杂的业务逻辑和数据操作，例如使用JOIN语句、视图等。这样既能保证程序的性能和可维护性，也能保障数据库的安全。

以下是一个简单的MySQL存储过程示例：

CREATE PROCEDURE GetCustomer(IN customerId INT, OUT customerName VARCHAR(50))

SELECT name INTO customerName FROM customers WHERE id= customerId;

二、mysql 存储过程执行太慢怎么优化

1.当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断

2.通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存.但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate，Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（没什么卵用的意思）。

3.如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析

4.解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlr.jar。这个就是专门做语法解析的工具.因为在Hibernate里面有HQL，它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道.

5.得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等...

6.预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化

7.查询优化器，是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT* FROM USER WHERE USERNAME= toby AND PASSWORD= 1,它会怎么去执行?它是先执行username= toby还是password= 1?每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快.这一步是MySQL性能中,最关键的核心点,也是我们的优化原则.我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据.MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样.

8.这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username= toby还是password= 1

9.这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.(优化就是制定一个我们认为最快的执行方案,最节省IO,和执行最快)

10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。

三、为什么MySQL不推荐存储过程mysql不推荐存储过程

1、MySQL作为一种开源的关系型数据库管理系统，广泛应用于企业、政府、个人等各个领域。虽然MySQL支持存储过程，但在实际使用中，却并不推荐使用存储过程。本文将从性能、安全和可维护性三个方面来解释这一现象。

2、在MySQL中，存储过程一般会比对应的SQL语句执行得慢。这是因为存储过程需要在执行前进行编译，而编译时间对于大型应用来说可能非常长。此外，存储过程还需要耗费额外的内存空间来存储过程体。如果过程体非常大，那么这个开销可能会变得非常显著。

3、还有一个性能问题是存储过程的调用开销。每次调用存储过程时，MySQL都需要创建一个新的会话，并在会话中执行过程。这个过程需要切换上下文，增加了额外的开销。

4、存储过程可以将SQL代码封装起来，从而保证SQL的安全性。不过，这并不是一个完美的保证。一个熟练的黑客可以通过运行存储过程来攻击系统。如果存在不良意图的开发人员，则也可以通过存储过程来恶意操纵数据。

5、此外，存储过程也有可能存在漏洞。因为存储过程的编写需要一定的编程技巧，如果开发人员对此不熟悉，就很容易写出易受攻击的存储过程。这就需要很高的安全意识和相关技能来保证存储过程的安全性。

6、存储过程的可维护性非常差。因为存储过程中的代码是封装在数据库中的，所以难以进行版本控制。此外，存储过程的代码也不便于调试，因为它通常是在数据库中运行的。

7、此外，存储过程的代码也不便于重构。如果存储过程中的某些部分需要修改，那么开发人员需要重新编写整个存储过程，这显然会增加开发和维护的复杂度。

8、综合来说，虽然MySQL支持存储过程，但在实际应用中不推荐使用。存储过程对于性能、安全性和可维护性都有一定的隐患。如果开发人员有必要使用存储过程，那么需要非常谨慎地考虑它们的使用场景，以及正确处理相关的性能、安全性和可维护性问题。

9、CREATE PROCEDURE get_product_price(IN product_id INT, OUT price DECIMAL(10,2))

10、 SELECT price FROM products WHERE id= product_id INTO price;

11、SELECT price FROM products WHERE id= 1;

12、上面的两个代码片段都实现了获取商品1的价格的功能。但是存储过程代码相对复杂，而且执行效率不如SQL语句高。因此，SQL语句在实际应用中更为广泛。