1

我有一个非常大的表，目前大约有 70M 行，并且每天增长数千，这个模式现在每天都在翻转，所以我正在移动到一个分区表并重新设计 ddl。

该表基本上是 NOT NULL INTEGERS（一些中等一些 INT 一些很小）的集合，它们需要对一组 7 列（表中的列更多）具有唯一约束，每次插入计算成本非常高，并且增加索引文件的大​​小要大得多，因为我从不检索它，我宁愿删除它，并且以某种方式 md5/也许简单地连接值......还不知道。

问题是唯一可以容纳如此大的唯一数字的列类型是 varchar 我在质疑这个 PK 是否真的会更好？另外，因为我将有一个 PRIMARY KEY 'part_key' (site_id,id) 我将不得不在分区的设计中采用唯一约束，总结一下......我确信这不是一个新问题，但我不是'无法找到比较两者的任何基准/文档，有人对这个问题有任何经验吗？问题是，当我从未通过 pk 检索或只是唯一字段的散列值 PS 时，PK 是否应该是整个 8 个字段（请记住，此表可能有超过 100M 行）：检索主要是由 7 列中的两列完成磁盘大小不是问题，谢谢。

4

2 回答 2

0

在 mysql 进行分区修剪之前，我建议（gulp）将您的表非规范化为假分区。做一些事情，比如取第一个值的模 32 并制作 32 个表格。

更新：显然 mysql 5.1.6 及更高版本支持修剪（http://dev.mysql.com/doc/refman/5.1/en/partitioning-pruning.html）所以我更强烈的建议是升级，然后让 mysql 处理为您进行分区，可能使用您的 7 列之一的哈希值。

于 2009-10-14T19:42:33.417 回答
0

如果您可以找到与您的记录查找匹配的良好哈希，那么在每个分区上应用您的唯一约束应该没什么大不了的。较小的分区大小将使您的唯一约束更便宜。（如果我错了，我敢肯定这里有人会教我）。

我被困在 MySQL 5.0 上。我正面临手动分区几个超过 40M 行的表。我有一个可以在我的应用程序中散列的文档 ID floor(docID/10)%100：. 这可以给我 100 个分区，这应该会显着降低我的索引大小。我对表进行了查询，并通过哈希计算了行数：

select count(docID), floor(docID/10)%100 as partno
from documents 
group by partno

幸运的是，我在第一次尝试时发现了一个非常均匀的分布。你自己的公式会有所不同，我不知道你的分布是什么样的。您是否担心面对分区时您的唯一约束无法成立？

如果您可以利用 MySQL 分区，它将更强大，并且对您的应用程序的影响更小。

于 2009-11-05T05:29:52.103 回答