我有一个非常大的表，目前大约有70M行，并且每天都有数千个增长，这个模式现在每天都在翻转，所以我正在转移到分区表并重新设计ddl。
该表基本上是NOT NULL INTEGERS的集合（某些介质有些INT很小） 这需要对一组7列（表中的列数更多）具有唯一约束，这对于每个插入计算非常昂贵，并且因为我从未通过它检索而更加增加索引文件的大小我宁愿放弃它，不知何故md5 /也许是简单的连接值...还不知道。
问题是唯一可以容纳如此大的唯一数字的列类型是varchar我在质疑这个PK是否真的会更好？ 因为我将有一个PRIMARY KEY'part_key'（site_id，id），我将不得不这样做 在分区的设计中采取独特的约束，总结一下...... 我确定这不是一个新问题，但我无法找到任何比较这两个的基准/文件，有没有人有这个问题的经验？ 问题是真的应该PK是整个8个字段（记住这个表可能有超过100M行）当我没有通过pk检索或只是唯一字段的散列值 P.S：检索主要由7列中的两列完成 磁盘大小不是问题 谢谢。
答案 0 :(得分：0)
直到mysql获得分区修剪，我建议（ gulp ）将你的表非规范化为假分区。做一些事情，比如取第一个值的模32并制作32个表。
更新：显然mysql 5.1.6及更高版本支持修剪（http://dev.mysql.com/doc/refman/5.1/en/partitioning-pruning.html）所以我更强烈的建议是升级，然后允许mysql为你处理分区，可能使用您的7列之一的哈希值。
答案 1 :(得分：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分区，它将更强大，对您的应用程序的影响更小。