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