1

我不是数据库专家,但我从一个看起来有点严重无能但偶尔会发光发热的人那里继承了相当大的生产 MySQL 数据库的一些责任。大多数问题我都能够自己解决,但是这个问题让我很困惑,我还没有看到任何地方解决它:

是否有任何理智的理由让存储过程只不过是准备好的语句的包装器?

这些方面的东西:

CREATE PROCEDURE foo_search (IN searchParam1 int, IN searchParam2 varchar(255))
BEGIN
    SET @local1 = searchParam1;
    SET @local2 = searchParam2;
    PREPARE stmt FROM 
        '...'; --Fairly complex nested select statement
    EXECUTE stmt USING @local1, @local2;
END

就是这样。我对准备好的语句的理解是,它们的好处在于清理输入(已经由我们使用的 PHP 框架处理),并减少来回通信(在存储过程中受到损害)。

这是纯粹而简单的毫无意义的疯狂,还是我错过了什么?

4

2 回答 2

0

可能有。

也许这家伙正在使用不支持准备好的语句的数据库连接库,所以他只是想获得等效的效果。

也许他想从触发器中调用该存储过程。

于 2012-10-12T23:21:08.750 回答
0

迈克列举了两个很好的理由。这里还有几个:

  1. 减少网络通信量,因为CALL foo_search(searchParam1, searchParam2)数据量比每次发送整个 SQL 语句的数据量要少。

  2. 在服务器上准备语句可能会提高性能。在对几种不同的方法进行基准测试后,我们发现对于复杂的 SQL 语句,只在服务器上准备一次语句的性能最好。这是一个例子:


CREATE PROCEDURE foo_search (IN searchParam1 int, IN searchParam2 varchar(255))
BEGIN
    SET @local1 = searchParam1;
    SET @local2 = searchParam2;
    IF ISNULL(@foo_search_prepared) THEN
        SET @foo_search_prepared = TRUE;

        PREPARE stmt FROM 
            '...'; --Fairly complex nested select statement
    END IF; 
    EXECUTE stmt USING @local1, @local2;
END
于 2012-10-13T00:02:23.607 回答