MYSQL 视图对比 Select 性能和延迟
MYSQL View vs Select Performance and Latency
我发现的关于此主题的所有文献都表明使用视图的优势在于它使代码更加简洁。我想知道的是，如果我一个接一个地触发多个选择，延迟（Apache 到 MySQL 到 Apache 多次）是否会比使用复杂视图高得多。我有一个场景，我可以采用以下两种方法之一：
- 使用单独的查询。据我了解，即使我使用视图，这也是 MySQL 所做的。但是会不会有 latency 问题，因为我将执行一个查询，在 PHP 后端解析它以获取下一个查询的过滤器，然后将该查询发送到MySQL 服务器（依此类推，比如 1 到 4 次之间的任何地方，即我将 运行 总共查询 2 到 5 次）？
也就是说，Query1->PHP->Query2->PHP->...
- 构建复杂的视图。因为我很可能在一个 table 中有元素而在另一个中没有相应的条目，所以最终视图可能有多个 UNIONS 或 JOINS，即使它是由两个 table 创建的。但是既然这里没有延迟的问题，所有的处理和过滤都是在MySQL服务器端完成的，那么性能会不会有提升？
什么可以帮助我更快地向用户提供页面？
欢迎任何基于实际观察或经过验证的文档的帮助。
谢谢。
SR
视图不会修改数据库的性能。性能与它包含的 select 相同。视图不用于提高性能或更快地交付页面，它们用于两件事：
- 视图的使用让您可以向不同 table 上的用户授予权限，这样他们就不会看到 table 中的所有信息（他们只能看到您想要的内容和方式你想要）
- 如果您在代码的不同位置使用相同的 select 查询，如果您需要修改它，您可以只修改视图而不是代码中的每个查询
视情况而定。
一方面，简单查询的 90% 是开销（通信、解析等）。因此，与服务器的往返次数越少越好。
另一方面，过于复杂的查询（有或没有 VIEWs）的效率可能低于将其分解为简单步骤的效率。
我说 VIEWs 是语法糖，不是性能优势。 （@nacho 说得更好。）
我构建了许多复杂的页面，其中有 40 个查询。性能不错。我找到任何 "slow" 查询（SlowLog 对此很方便），然后优化它们。
我还发现最好构建一个包含额外信息的页面，而不是强迫用户单击某些内容以打开另一个页面。也就是说，将 SELECTs 的数量加倍（花费几毫秒）可以导致更好的 UI.
我发现的关于此主题的所有文献都表明使用视图的优势在于它使代码更加简洁。我想知道的是，如果我一个接一个地触发多个选择，延迟（Apache 到 MySQL 到 Apache 多次）是否会比使用复杂视图高得多。我有一个场景，我可以采用以下两种方法之一：
- 使用单独的查询。据我了解，即使我使用视图，这也是 MySQL 所做的。但是会不会有 latency 问题，因为我将执行一个查询，在 PHP 后端解析它以获取下一个查询的过滤器，然后将该查询发送到MySQL 服务器（依此类推，比如 1 到 4 次之间的任何地方，即我将 运行 总共查询 2 到 5 次）？ 也就是说，Query1->PHP->Query2->PHP->...
- 构建复杂的视图。因为我很可能在一个 table 中有元素而在另一个中没有相应的条目，所以最终视图可能有多个 UNIONS 或 JOINS，即使它是由两个 table 创建的。但是既然这里没有延迟的问题，所有的处理和过滤都是在MySQL服务器端完成的，那么性能会不会有提升？
什么可以帮助我更快地向用户提供页面？
欢迎任何基于实际观察或经过验证的文档的帮助。
谢谢。
SR
视图不会修改数据库的性能。性能与它包含的 select 相同。视图不用于提高性能或更快地交付页面，它们用于两件事：
- 视图的使用让您可以向不同 table 上的用户授予权限，这样他们就不会看到 table 中的所有信息（他们只能看到您想要的内容和方式你想要）
- 如果您在代码的不同位置使用相同的 select 查询，如果您需要修改它，您可以只修改视图而不是代码中的每个查询
视情况而定。
一方面，简单查询的 90% 是开销（通信、解析等）。因此，与服务器的往返次数越少越好。
另一方面，过于复杂的查询（有或没有 VIEWs）的效率可能低于将其分解为简单步骤的效率。
我说 VIEWs 是语法糖，不是性能优势。 （@nacho 说得更好。）
我构建了许多复杂的页面，其中有 40 个查询。性能不错。我找到任何 "slow" 查询（SlowLog 对此很方便），然后优化它们。
我还发现最好构建一个包含额外信息的页面，而不是强迫用户单击某些内容以打开另一个页面。也就是说，将 SELECTs 的数量加倍（花费几毫秒）可以导致更好的 UI.