mysql 7columns pk vs. 1列md5唯一约束

Question

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

该表基本上是NOT NULL INTEGERS的集合（某些介质有些INT很小） 这需要对一组7列（表中的列数更多）具有唯一约束，这对于每个插入计算非常昂贵，并且因为我从未通过它检索而更加增加索引文件的大​​小我宁愿放弃它，不知何故md5 /也许是简单的连接值...还不知道。

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

Answer 1

直到mysql获得分区修剪，我建议（ gulp ）将你的表非规范化为假分区。做一些事情，比如取第一个值的模32并制作32个表。

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

Answer 2

如果你能找到一个与你的记录查找匹配的好哈希，那么在每个分区上应用你的唯一约束不应该是那么大的交易。较小的分区大小将使您的独特约束更便宜。 （如果我错了，这里有人会教我，我确定。）

我坚持使用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分区，它将更强大，对您的应用程序的影响更小。