小编hex*_*rot的帖子

我正在创建存储在 MySQL 中的大量位板存档。在我的架构中，有四组链接的位板 - 为了查询 - 在四个不同的表中表示。这四组中的每一组都将有大约 100k 行，我预计这些组中大约有 35k。

我的问题是关于 SQL 服务器本身的性能影响和限制。我考虑了以下模型：

1. 35k 个数据库，每个数据库有 4 个表，每个表 100k 行
2. 1 个数据库，每个集合有四个命名表，例如 db948-a、db948-b、db948-c、db948-d

附加信息：

1. 这些表之间没有任何联系；他们不需要在任何时候加入。
2. 它们不需要在任何时候更新（对四个表中的每一个都进行一次 INSERT），从那时起只需要 SELECT。
3. 这将存储在 ReiserFS（或没有文件计数问题的类似 FS）上
4. 我希望使用 MyISAM（不需要事务支持）

所以我主要关心的是 MySQL 对表和数据库计数的限制——鉴于上述信息，是否有任何限制我会超过会取消其中一种模式的资格？

此外，3.5 万个不同的数据库或一个数据库中的 14 万个表是否会产生任何明显的性能问题？

谢谢！

我有一个 MySQL 表，我希望它有几百万行和 99% 的选择语句。我遇到的问题是想出一种有意义的方法来确定主键。（我在底部提供了一个表格转储以供参考）

对于某些背景，我正在使用二维网格，其范围在每个方向上从大约 -800000 到 +800000 不等。每行由其 X/Z 坐标标识，每个坐标可能有 1-30 个相关的位串（类型）。

我的顾虑是：

1）我缺乏一种有意义的方法来主键这个表。虽然我知道我可以id使用 auto_increment创建一个字段，但我知道实际上这个键永远不会被使用，因为100%的 SELECTS 将采用以下形式：

SELECT `type`, `offset`, `bitstring` WHERE `x` = 0 AND `z` = 0;

2）我打算通过以下方式在多列（逻辑x/z）上建立索引：

CREATE INDEX coordinate ON bitstrings(x, z)

虽然我觉得这恰当地解决了我在现实世界中的选择，但我一直担心它是索引不足，基于数十个帖子说“是的，你需要一个 PK”。这是一种可以忽略 PK 的情况，还是任意的id最终仍会提供一些非常值得增加表大小和列的幕后优化？

作为旁注，如果有任何更实用、经过验证的方法来存储此类数据，我对完全重组此表绝对没有任何限制。

CREATE TABLE `bitstrings` (
  `x` int(11) NOT NULL COMMENT 'roughly +/- 10^6 range',
  `z` int(11) NOT NULL COMMENT 'roughly +/- 10^6 range',
  `type` smallint(6) NOT NULL COMMENT 'range: 1-4096',
  `offset` smallint(6) …