我建议启用慢速查询日志，并从记录需要超过5秒的查询开始。应该对日志中的查询进行性能分析。然后再转一圈4，3，2，1秒。做了这个分析后别忘了切换日志。
如果您的速度仍然很慢，那么您可以考虑一下您的硬件—它是一个速度慢的san，还是一个普通的硬盘，还是一个sd？在这之后你可以想想你的公羊。。。你需要更多吗，因为系统一直在交换？最后但并非最不重要的是想想你的cpu。。。但也许你是在一个树莓皮-这通常是缓慢的；-）

“表是完全规范化的”--既然有“过度规范化”这样的事情，让我们看看 SHOW CREATE TABLE 为了table。
事实表上有很多索引（有5亿行的那一个）会造成伤害 INSERT 性能。
不应规范化连续值（日期、日期时间、数字）。当您需要搜索一系列这样的值时，规范化会带来很大的伤害。
“我了解到，如果查询速度慢，问题来自于处理能力、ram、磁盘或服务器的数量。”——这是老生常谈。通常有一些方法可以改进查询和/或模式的索引和/或公式（如上所述）。
你熟悉“综合”指数吗？
“你能用儿童语言告诉我云计算或负载平衡或添加ram/cpu电源/磁盘如何帮助将查询响应时间从7秒增加到1秒吗？”回答：“这些都没有帮助。”mysql在一个cpu中执行一个查询，服务器上的i/o也可能是单线程的。并行性（你提到的）在mysql中不存在；当它这样做了，它是由用户编写的代码，然后感叹，它没有帮助预期。
“那么最好将这些数据迁移到mongodb或任何其他nosql db中”--您没有抓住要点。如果你需要读500米（甚至1米）的行，这需要时间。没有什么灵丹妙药可以让i/o更快。
很抱歉说得含糊不清，但是有几十条原则可以显著加快处理500米行的速度。
数据仓库的一大帮助是“摘要表”。他们通常把事情做得快10倍。但它们需要你建造和维护它们(同样，由于缺乏关于您的用例的详细信息，我的说法含糊不清。）
“99%的案件都是在stackoverflow上发生的，不是吗”--也许只有98%。
关于唯一的硬件修复，可以给你2倍的加速是更换一个旋转驱动器与ssd。CPU在18年中没有太大的改进。当您有64个连接时，64核会有帮助，但当您为1个连接的延迟计时时，64核就没有帮助了。当所需数据可以跨多个服务器分离时，最好进行分片。