MySQL：需要连接的大型表，如何拆分以进行优化？

案例：

我一直在开发一个web应用程序，在其中我存储来自不同自动化数据源的数据。目前，我正在共享LAMP服务器上使用MySQL作为DBMS和PHP作为编程语言

我使用几个表来标识数据源，并使用两个表进行数据更新。数据源位于三级层次结构中，更新带有时间戳

一个表包含层次结构的两个较高级别（地理位置和仪器），加上时间戳和“更新ID”。另一个表包含更新ID、层次结构的第三级（米）和值

大多数查询都涉及到该表与表之间的联合语句

目前，第一个表包含近250万条记录（290MB），第二个表包含超过1500万条记录（1.1GB），每小时有近500条记录添加到第一个表中，3000条记录添加到第二个表中，我预计这一数字还会增加。我不认为这些数字太大，但我遇到了一些性能缺陷

大多数查询涉及查找最近的过去活动（每个站点、每个站点组和每个工具），这没有问题，但有些查询涉及每日、每周和每月活动的摘要（每个站点和每个工具）。加载页面需要几秒钟，有时超过服务器的超时时间（30秒）

自动更新似乎也受到这些超时的影响，导致连接失败

问题：

有没有合理的方法来拆分这些表以便查询执行得更快？ 或者我应该尝试不涉及拆分表的其他类型的优化吗

---

（我认为这些表被正确地索引了，我知道一个可能的答案是转到一个专用的服务器，可能运行的是MySQL以外的其他东西，但是我还不能做这个动作，任何优化都会有助于这个场景。）

< P>如果慢的查询是历史摘要查询，那么您可能需要考虑一个。只要历史数据是相对静态的，预先计算事务性摘要数据通常不会有太大风险

---

数据仓库和为商业智能（BI）报告设计模式是一个非常广泛的主题。您应该仔细阅读，并询问您可能遇到的任何特定BI设计问题。

如果您正在执行的查询不必从整个表中获得结果，而只需要从特定范围（例如特定的一天）中获得结果，您可以尝试对表进行分区。但这与其说是永久性的缓解，不如说是一种变通方法（最多），而且您可以拥有的分区数量有限。从长远来看，您可能需要考虑更具可伸缩性的分片策略。任何数据库迁移都应该尽快完成。