MySQL 有什么更好的方法来加速一个具有数百万行的表或管理多个表？

Question

我正在处理现有的 PHP/MySql/JS/Ajax Web 应用程序，该应用程序为用户处理大量表行。以下是该页面当前的工作方式。

1. 用户上传了一个 LARGE csv 文件。我正在使用的测试有 400,000 行（每行有 5 列）。
2. Php 为此数据创建一个全新的表并插入数十万行。
3. 然后页面以有用的方式对这些数据进行排序/处理/显示给用户。处理包括搜索、按日期和其他行排序并重新显示它们而无需大量加载时间（这就是 JS/Ajax 的用武之地）。

我的问题是，这个应用程序应该为每次上传将数据放入一个新表中，还是将每个文件的 id 放入一个大表中？我认为原始开发人员出于速度目的添加了单独的表格。速度对此非常重要。

有没有更快的方法？有没有更好的捕鼠器？有没有人对此感到厌烦？

请记住，每个 .csv 都可以包含数十万行，并且每天可以上传数百个 .csv 文件。虽然它们可以在最后一次使用后大约 24 小时被删除（我在想 cron 工作有什么意见吗？）

谢谢大家！

基于cmets的一些笔记：

• 所有数据对每个用户都是唯一的，并且会发生变化，因此用户不会在几个小时后重新访问这些数据。只有当他们不小心关闭窗口然后又回来时，他们才会真正重新访问相同的 .csv。
• 不需要外键所有 csv 对每个用户都是私有的，不需要交叉引用。

Answer 1

我不愿将所有数据放入一个表中，原因很简单，因为您无法更改数据结构。

由于无论如何都会删除数据，并且您不需要组合来自不同负载的数据，因此没有明显的理由将数据放入单个表中。另一个论点是应用程序现在可以工作。您是否真的想在您完成工作之后发现一些要求在之后使用单独的表格？

如果您决定使用单个表，请使用表分区。由于每个用户都在使用自己的数据，因此可以使用分区将每个用户加载到单独的分区中。虽然对分区有限制（比如没有外键），但这会让访问单个表中的数据和访问原始数据一样快。

Answer 2

假设每天有 10⁵ 行和 10² 个 CSV，您每天查看 1000 万行（并且您说您会定期清除这些数据)。对于一个体面的数据库来说，这看起来并不可怕（特别是考虑到您可以在表内索引，而不是跨多个表）。

显然，最常用的 CSV 可以很容易地保存在内存中以提高访问速度 - 甚至可能全部保存（如果您每 24 小时以上刷新一次，基于几乎没有数据的一个非常简单的计算给我一个 1Gb 的数字. 1Gb 现在不是不合理的内存量）