我想知道 InnoDB 是否是格式化表格的最佳方式？该表包含一个字段，主键，并且该表每天将获得 816k 行（估计）。这将很快变得非常大！我正在研究一种文件存储方式（这会更快吗）？该表将存储已处理的 Twitter Id 的 ID 号？
另外，SELECT min('id') 语句中的任何估计内存使用情况？任何其他想法都非常感谢！
【问题讨论】：
标签： mysql indexing twitter large-data-volumes
如果这些 ID 号单调递增，并且您的写入仅附加数据（从不修改），则使用单个文件可能会快得多。然后SELECT min('id') 就变成了读取文件的第一行，其他都是二分查找。
【讨论】：
我建议您按 ID 或日期开始 partioning 您的表。分区根据一些定义的逻辑将一个大表拆分为几个较小的表（比如按日期范围拆分），这使得它们在性能和内存方面更易于管理。 MySQL 5.1 内置了这个特性，或者您可以使用自定义解决方案来实现它。
在平面文件中实现存储，您将失去数据库的所有优势 - 您不能再执行涉及数据的查询。
【讨论】：
如果您的 id 列上有索引，则 select min(id) 应该是 O(1)，对此应该没有太多的内存要求。
如果你的主键在 twitter id 上，那么你就有一个索引。
【讨论】：
在 MySQL Dev zone 上有一个很好的存储引擎对比：
根据您的描述，我会说 MyISAM 会更好，但这在很大程度上取决于您应用程序的比较读写模式。
【讨论】：
唯一确定的答案是尝试两者并测试，看看会发生什么。
通常，MyISAM 的写入和读取速度更快，但不能同时进行。当您写入 MyISAM 表时，整个表将被锁定以完成插入。 InnoDB 的开销更大，但使用了行级锁定，因此可以同时进行读取和写入，而不会出现 MyISAM 的表锁定问题。
但是，如果我理解正确，您的问题会有所不同。只有一列，该列作为主键在 MyISAM 和 InnoDB 处理主键索引的不同方式中具有重要的考虑。
在 MyISAM 中，主键索引就像任何其他二级索引一样。在内部，每一行都有一个行 ID，索引节点只指向数据页的行 ID。主键索引的处理方式与任何其他索引都不同。
然而，在 InnoDB 中，主键是集群的，这意味着它们保持连接到数据页，并确保行内容根据主键在磁盘上保持物理排序顺序（但仅在单个数据页内，它们本身可以按任意顺序分散。）
在这种情况下，我希望 InnoDB 可能具有优势，因为 MyISAM 基本上必须做双重工作——在数据页中写入一次整数，然后在索引页中再次写入。 InnoDB 不会这样做，主键索引将与数据页相同，并且只需要写入一次。它只需要在一个地方管理数据，而 MyISAM 无需管理两个副本。
对于任一存储引擎，在索引列上执行诸如 min() 或 max() 之类的操作应该是微不足道的，或者只是检查索引中是否存在数字。由于该表只有一列，因此甚至不需要书签查找，因为数据将完全在索引本身内表示。这应该是一个非常有效的索引。
我也不会担心桌子的大小。在行宽只有一个整数的情况下，每个索引/数据页可以容纳大量行。
【讨论】：
只有一个字段作为主键，只能添加记录，这并不适合常规数据库。
首先，您需要存储两倍的信息，每个字段都进入数据表和索引。
顺便说一句，之所以称为关系数据库，是因为它们将相关数据存储在一行中；很难看出您的数据是否合格 :-) 如果您还存储其他内容，那么数据库将是值得的。
您没有提到数据是否会被多个进程同时访问 - 如果不是，那么您不需要数据库 ACID 原则赋予的所有优势。即使您确实需要 ACID，也可以在没有完整数据库的情况下实现。
我的第一个想法是构建自己的 B-tree 或 B+-tree 数据文件来存储 twitter ID 以避免数据重复。我能看到你做的唯一查询（基于问题）是：
第一个可以通过简单地将最低的存储在 B-tree 结构之外的另一个文件中来实现 O(1)（当你得到一个较低的文件时替换它）。我不确定这个的商业案例，除非它是为了快速找出某个 twitter ID 不在表中（所以在这种情况下你可能也想要 max）。
第二个是标准的树搜索技术，这是数据库通常在幕后使用的技术。
【讨论】：
我还看到一些贸易公司使用报价数据库，即。数据库+ http://kx.com/
【讨论】：