Question

我非常喜欢CREATE VIEW的用处。例如，它允许我通过COALESCE(post.publish, profile.publish)获取全局和特定值，这样如果publish为NULL，则会获取全局值。

从性能和逻辑角度来看，我有点好奇，我应该如何在现有表格旁边使用它。让我们说我有一张桌子：

CREATE TABLE post (
    id INT,
    profile_id INT,
    name VARCHAR,
    publish ENUM('TRUE', 'FALSE') NULL
)

CREATE VIEW最适合如下：

CREATE VIEW post_info AS
SELECT post.*, COALESCE(post.publish, profile.publish) AS publish
FROM post
INNER JOIN profile
ON post.profile_id = profile.id

仅在post_info个案例中使用SELECT，或者：

CREATE VIEW post_info AS
SELECT post.id, COALESCE(post.publish, profile.publish) AS publish
FROM post
INNER JOIN profile
ON post.profile_id = profile.id

当需要额外值时，<{{JOIN post_info post SELECT {/ 1>}

请分享您对此的见解和想法。我想听听您对每个解决方案的正面和缺点的意见。也可以是我没有提到过的。

Answer 1

这实际上取决于您将如何使用这些视图。值得一提的是，MySQL有两种方法可以处理引用视图的查询，所使用的方法取决于视图声明的ALGORITHM子句。

由于缺乏更好的措辞，我将重现the manual：

对于[ALGORITHM =] MERGE，引用视图和语句的语句的文本   视图定义被合并，以便视图定义的各个部分   替换声明的相应部分。

对于TEMPTABLE，视图中的结果将被检索到   临时表，然后用于执行语句。

对于UNDEFINED，MySQL选择使用哪种算法。

MERGE算法通常允许更快地处理最终查询，但是在很多情况下MySQL无法使用它（有关详细信息，请参阅链接的手册页）。

答案是：如果您的视图未使用ALGORITHM = TEMPTABLE 和定义，如果换行查询不会阻止使用MERGE算法，那么带{的版本{1}}，如果没有额外的SELECT *，则会更好。

否则，如果未使用JOIN，则第二种解决方案可能更好。

作为旁注，为了解决您提到的用例，更好的选择是让您的应用层在插入时让MERGE填入post.publish中的值，并摆脱profile.publish以及视图。或者，通过在桌子上放置合适的触发器可以实现相同的效果。

在视图中使用select *是否安全？

1 个答案: