处理MySQL视图的临时表算法

Question

如果临时表算法被改名为不可扩展算法，那就更好了。这样一来，在视图定义中看到这个算法时，它会向开发人员提供更多的警告 - 类似于在解释结果中使用临时表时的警告。这只是一个玩笑请求，但对于不知情的人来说，它确实可能会造成灾难性后果。

问题在于，如果在视图定义中执行某些操作，它将从合理的合并算法切换到完全无效的临时表算法。如果涉及的数据很少，这并不是什么大问题。但是随着数据的增长，这种情况将极大地影响性能。

如何处理这个问题？自从5年前引入视图以来，这一直是一个问题，我不知道有没有任何努力来解决它。其他流行的数据库系统中是否存在这种问题？

在下面的链接中向下滚动，查看何时无法使用合并算法以及导致MySQL退化为使用糟糕的临时表算法的原因：http://mysql2.mirrors-r-us.net/doc/refman/5.1/en/create-view.html "我需要翻译以下内容，涉及编程方面。请在保留HTML标签的前提下，将以下文字翻译成中文：'What's so bad about it? The temp table algorithm works like so: Run the view "AS IS" in the view definition without merging the query's where clause criteria into it. Dump the resulting data into a temp table. Filter the data in the temp table based on the query's where clause criteria - no indexes here either.' 这里是需要翻译的内容："

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' 

两个小时后，结果将会返回...

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

- Khorkrak

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视图确实很糟糕。

- Johan