Question

我有以下查询：

SELECT t.*, a.hits AS ahits 
                FROM t, a 
                WHERE (t.TRACK LIKE 'xxx')
                AND a.A_ID = t.A_ID
                ORDER BY t.hits DESC, a.hits DESC

经常运行。表格t有大约15M +行，a大约有3M +行。

当我在上面的查询中做了EXPLAIN时，我收到一条说明，它总是创建一个临时表。我注意到基于上面的查询创建临时表花了很长时间。并且，这是在充足的时间完成的。

因此，我想知道我是否使用上述说法创建了一个视图：

CREATE VIEW v_t_a 
SELECT t.*, a.hits AS ahits
FROM t, a
WHERE a.A_ID = t.A_ID

将我的代码更改为：

SELECT * FROM v_t_a WHERE TRACK LIKE 'xxx' ORDER BY hits DESC, ahits DESC

它会改善表现吗？它会删除创建临时表时间吗？

非常感谢您的建议！

Answer 1

如果你认为MySQL会像更高级的数据库系统一样优化你的VIEW，这是非常危险的。与子查询和派生表相同，MySQL 5.0将失败并在许多方面执行效率非常低。

MySQL有两种处理VIEWS的方式 - 查询合并，在这种情况下，VIEW只是作为宏或临时表扩展，在这种情况下，VIEW具体化为临时表（没有索引！），后来在查询执行中进一步使用。似乎没有对用于从外部查询创建临时表的查询应用任何优化，而且如果您使用多个连接在一起的临时表视图，则可能会出现严重问题，因为此类表未获取任何索引。

因此，请务必在应用程序中实现MySQL VIEW，尤其是需要临时表执行方法的MySQL VIEW。 VIEW可以在非常小的性能开销下使用，但仅限于谨慎使用它们。

MySQL可以通过正确优化的VIEW获取查询。

Answer 2

在视图中执行完全相同的操作比在查询中执行操作更有效率。

视图更多的是管理查询的复杂性而不是性能，它们只是在后端执行与查询相同的操作。

一个例外是具体化的查询表，它实际上为查询创建了一个单独的长期表，以便后续查询更有效。我不知道MySQL是否有这样的东西，我自己就是一个DB2人： - ）

但是，如果查询的性能存在问题，您可以自己实现这样的方案。

这在很大程度上取决于表的变化率。如果数据经常变化，那么无论如何都必须重新生成具体化的查询，这将是不值得的。

Answer 3

VIEW内部每次你查看时都会加入两个表...... !!

要防止这种情况，请创建MATERIALIZED VIEW ...

It is a view that is more of a TABLE ...You can query it directly as other table..

但是如果任何基础TABLE数据发生变化，你必须编写一些TRIGGERS来自动更新它......

请参阅：http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views

我应该一直使用CREATE VIEW而不是JOIN

3 个答案: