虚拟表（或视图）的性能与运行查询本身的性能完全相同（甚至可能稍差）。
性能故障排除是一个很大的主题，如果看不到任何代码（包括后端和sql），我们就无法猜出为什么这样做很慢。
我建议你看看；
1-缓存结果，如果它们不需要完全是最新的
2-检查表上的索引，确保它们有支持索引
3-检查后端代码与数据库的接口是否正确
过帐后编辑查询：
好吧，这里有很多问题；

select a.*, b.* from events as a
join users as b on a.userid = b.id
join groups as c on a.id = c.eventid
join likes as d on a.id = d.eventid
where a.created_at > [some-x-date]
and c.group IN (..,..,..)
group by a.id
order by a.created_at desc

你选择了a和b中的所有字段，但也按a.id分组-这对我来说没有意义。。。它也不允许有效地使用索引，因为所有字段都将被拉出。你真的需要所有的田地吗？？你为什么要用群比？
在a.userid、a.created\u at和c.group上有索引吗？

首先要做的是优化您的查询-您可以发布特定的sql并在这里进行解释。一般来说，在现代硬件上，sql数据库可以毫无问题地处理数百万行。如果可以使用索引，则连接不会导致显著的性能问题。一旦遇到大量并发用户，通常会遇到一些挑战；这通常需要缓存和/或延迟加载（见下文）。
看看您的模拟查询，没有理由认为这样做会很慢——连接在主键和外键上，where子句使用高度可索引的列。在现代硬件上，所有表中都有（数千万）行，我希望它在几秒钟内返回。
在评论中，你提到页面速度已经减慢，因为你有很多流量。最简单和最便宜的解决方案是购买更多的硬件-额外的ram为您的数据库服务器，更快的硬盘。几乎可以肯定，您遇到了某种硬件瓶颈，如果您的数据库查询是最佳的，那么非规范化不太可能产生重大影响。
高流量的网站使用大量的缓存，所以他们不会为每个页面请求从数据库中检索新闻，而是缓存结果。这可以极大地提高性能和可伸缩性—几乎每个web框架都有一个缓存解决方案。
配置缓存是一个判断和实验的问题——你必须用性能和可伸缩性来换取“新鲜感”。如果您的峰值负载是1000个并发用户/分钟，则缓存数据库查询1分钟可将数据库的负载减少999个请求，而代价是1分钟的“新鲜度”延迟。这很可能是可以接受的。
您还可以构建一个解决方案，其中发布新的新闻文章刷新缓存，刷新后的第一个请求将重建缓存；所有后续请求都会读取缓存，直到它再次刷新。这提高了“新鲜度”，而代价是1个可能较慢的页面请求。
第三，“延迟加载”：高性能网站倾向于使用ajax或类似技术异步获取内容。在一个超级简单的级别上，它们将为静态html提供带有占位符的新闻提要框，并在数据返回时运行异步javascript调用来替换占位符。通常，“延迟加载”只加载用户可见的内容（从而减少了查询的数量和加载到页面中的数据量）。