在视图中使用select *安全吗？

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

并且仅在SELECT情况下使用post_info，或者：

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

当需要额外的值时，在SELECT中使用JOIN post_info和post？

请分享你对此的见解和想法。我想听听你对每个解决方案的优点和缺点的看法。也可以是我没提过的。

Answer 1

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

由于缺乏更好的表达方式，我将重新生成the manual

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

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

对于UNDEFINED，MySQL选择要使用的算法。

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

因此，答案是:如果您的视图没有使用ALGORITHM = TEMPTABLE 和定义，如果包装查询不阻止MERGE算法的使用，那么使用SELECT *而不使用额外的JOIN的版本会更好。

否则，如果不使用MERGE，第二种解决方案可能会更好。

顺便说一句，为了解决您提到的用例，更好的选择是让应用程序层在插入时用profile.publish中的值填充post.publish，并去掉JOIN和视图。或者，可以通过在桌子上放置合适的触发器来实现相同的效果。