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