处理视图的 MySQL 临时表算法

Question

如果将临时表算法重命名为不可扩展算法就好了。也许当开发人员在视图定义中看到这一点时，它会向开发人员提供更多警告 - 类似地，当它在解释结果中使用临时表时。大多数情况下这只是一个半开玩笑的请求，但实际上这对于不知情的人来说可能是灾难性的。

问题在于，如果您在视图定义中执行某些操作，它将从正常的合并算法切换到效率低下的临时表算法。如果涉及的数据很小，这没什么大不了的。但这是随着数据增长而降低性能的因素之一。

但如何最好地处理这个问题呢？自从 5 年前实施视图以来，这一直是一个问题，我不知道有任何解决方案。其他流行的数据库系统是否也存在这样的问题？

在下面的链接中向下滚动到讨论何时无法使用合并算法的地方，以查看是什么导致 MySQL 退化为使用糟糕的临时表算法： http://mysql2.mirrors-r-us .net/doc/refman/5.1/en/create-view.html

这有什么不好呢？临时表算法的工作原理如下：

1. 在视图定义中“按原样”运行视图，而不将查询的 where 子句条件合并到其中。
2. 将结果数据转储到临时表中。
3. 根据查询的 where 子句条件过滤临时表中的数据 - 这里也没有索引。

所以你可以想象当你有一个 5000 万行的表和一个像这样的视图定义的地狱时 - 愚蠢的例子，但你明白了：

create view last_order_date as 
    select max(order_date) last_date, username from orders group by username;

用户可能会写：

select * from last_order_date where username = 'joejoe22' 

2小时后返回结果......

那么如何最好地处理这种情况？

Answer 1

编写一个返回结果集的存储过程。

DELIMITER $

CREATE PROCEDURE DoViewMyData(Param1 INT)
BEGIN
  SELECT 
    field1 as x
    ,field2 as y
    FROM table
    WHERE field1 = Param1;
END$

DELIMITER ;

现在调用该过程，它将返回其中的 select 语句的结果集。

CALL DoViewMyData(1);

OUTPUT:
+------+-------------------+
| x    | y                 |
+------+-------------------+
| 1    | balabablabla      |
+------+-------------------+

只需执行 CALL，不要执行不起作用的 SELECT CALL。
您也可以不在另一个 SELECT 语句中使用CALL。
当然，您可以指示存储过程将输出放入临时表中，然后在另一个 SELECT 中使用它。

存储过程将使用正确的索引，并且您的 select 语句已准备好。
另外，您可以在前面的语句中准备一些内容，从而加快时间关键的查询。

不过你是对的：
MySQL 视图确实很糟糕