Jam*_*tig 5 mysql twitter indexing large-data-volumes
我想知道InnoDB是否是格式化表格的最佳方式？该表包含一个字段,主键,该表每天将获得816k行(est.).这将变得非常快!我正在研究文件存储方式(这会更快)吗？该表将存储已经处理过的Twitter ID的ID号？
还有,SELECT min('id')声明中估计的内存使用量是多少？非常感谢任何其他想法!
唯一确定的答案是两者都尝试一下，看看会发生什么。
一般来说，MyISAM 的写入和读取速度更快，但不能同时读取和写入。当您写入 MyISAM 表时，整个表将被锁定以完成插入。InnoDB 的开销更大，但使用行级锁定，因此读取和写入可以同时发生，而不会出现 MyISAM 表锁定带来的问题。
但是，如果我理解正确的话，你的问题有点不同。只有一列，该列作为主键，在 MyISAM 和 InnoDB 处理主键索引的不同方式中具有重要的考虑因素。
在 MyISAM 中，主键索引就像任何其他辅助索引一样。在内部，每一行都有一个行 ID，索引节点仅指向数据页的行 ID。主键索引的处理方式与任何其他索引没有不同。
然而，在 InnoDB 中，主键是聚集的，这意味着它们保持附加到数据页，并确保行内容根据主键在磁盘上保持物理排序顺序（但仅限于单个数据页内，这些数据页本身可能分散在任何订单。）
在这种情况下，我认为 InnoDB 可能有一个优势，因为 MyISAM 本质上必须做双重工作——在数据页中写入一次整数，然后在索引页中再次写入。InnoDB不会这样做，主键索引将与数据页相同，并且只需写入一次。它只需在一处管理数据，而 MyISAM 则无需管理两个副本。
对于任一存储引擎，在索引列上执行诸如 min() 或 max() 之类的操作应该很简单，或者只是检查索引中是否存在数字。由于该表只有一列，因此甚至不需要书签查找，因为数据将完全在索引本身内表示。这应该是一个非常有效的索引。
我也不会那么担心桌子的大小。如果行的宽度仅为一个整数，则每个索引/数据页可以容纳大量行。