处理视图的MySQL临时表算法

如果Temp Table算法将被重命名为Unscalable算法，那将会很好。在视图定义中看到它时，它可能会给开发人员提供更多的警告 - 类似于在解释结果中使用临时表时。大多数情况下，这只是一个唾手可得的要求，但对于不知情的人来说真的可能是灾难性的。处理视图的MySQL临时表算法

问题是如果你在你的视图定义中做了某些事情，它会从理性合并算法切换到绝望效率低下的临时表算法。如果涉及的数据很小，这不是什么大问题。但是随着数据的增长，这些将会导致性能下降。

尽管如何处理这个问题呢？这是一个问题，因为观点是在5年前实施的，我不知道有什么努力来解决它。其他常用数据库系统中是否存在这种问题？

向下滚动，在下面的链接，在那里讨论了当合并算法不能用，看看是什么原因导致的MySQL沦为使用可怕的临时表算法： http://mysql2.mirrors-r-us.net/doc/refman/5.1/en/create-view.html

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

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

所以你可以想象这里所涉及的，当你有一个视图定义像50万行的表中的地狱 - 愚蠢的例子，但你明白了吧：

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个小时后，结果返回...

那么如何最好地应对这个局面？

来源

2010-05-28 Khorkrak

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

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的访问量肯定不吸

来源

2011-04-15 17:34:14 Johan

处理视图的MySQL临时表算法

回答

相关问题