MySQL 中的视图可能很棘手。例如，它们不支持from子句中的子查询。
对于大多数数据库，我会提倡使用视图。使用 MySQL，情况有点棘手，因为您可能无法轻松地将所需的查询表达为视图。
使用临时表有一定的优势。您可以为给定的查询添加适当的索引。表的大小很好理解（如果你碰巧有一个基于统计的查询优化器）。在某些环境中，临时数据库可能位于比原始数据更快的磁盘上。而且，临时表可能适合原始表不适合的内存。这可能会对更新产生巨大影响。
因此，您可以尝试查看它是否适用于您的情况。由于视图的限制，它不一定涵盖所有情况。而且，临时表很有可能实际上会表现得更好。
您的措辞建议您考虑在每次需要“加利福尼亚商店”列表时从表中提取行子集（例如）stores并将其复制到表中（例如）（例如）的选项。此选项可能比视图更昂贵，而且充其量是无用的。storesInCalifornia
我写了“可能更昂贵”，因为实际上有可能在从视图中读取时（或者更确切地说，在将视图中的记录与其他表或视图组合时），内部会创建一个临时表（参见TEMPTABLEalgorithm）。
我想您宁愿考虑storesInCalifornia每次都不会重建的配置。一个触发器stores可以使两者同步。
这个解决方案可能更可取，我想它会比在常规表上读取的视图执行得更好（主要原因是表中的行较少，因此索引更小，等等）。现在您仍然需要确定这种收益是否值得对更新产生负面影响。这取决于您的应用程序使用情况，并且没有正确答案。
现在有一个结合了两全其美的解决方案。分区。stores您可以按州和/或国家/地区进行分区，并在其上创建一个视图。唯一的缺点（但主要的一个）：分区不支持外键。