一个表共12个字段，现在需要将6个字段同时设置为Primary Key时，这样组合字段primary key的值才是唯一，请问对于要将接近一半的字段设置为primary key的表，现在有以下问题请教，谢谢！
1.太多字段做primary key是否对查询没有太大的帮助？
2.上面的例子是否用自增的字段做primary key比用上述6个段做primary key还好呢?
3.若2中的假设正确，那么primary key的字段不超过表中总字段的时候可以用多个字段做primary key才能发挥到primary key的查询的效率呢？
------解决方案--------------------
1.太多字段做primary key是否对查询没有太大的帮助？
不一定有帮助.看实际情况
2.上面的例子是否用自增的字段做primary key比用上述6个段做primary key还好呢?
决定用哪个做主键,一般与业务逻辑有关系.象你这种情况我会选择用自增ID
3.若2中的假设正确，那么primary key的字段不超过表中总字段的时候可以用多个字段做primary key才能发挥到primary key的查询的效率呢？
一般最多四个字段做联合主键
------解决方案--------------------
一般不一般没法解决特定问题
看查询需求决定
------解决方案--------------------
1.太多字段做primary key是否对查询没有太大的帮助？
个人看法：主键是为了保持数据的唯一和可标识性，一般来说它不涉及性能问题。你完全可以把聚集索引移到别的列而不使用默认模式。
2.上面的例子是否用自增的字段做primary key比用上述6个段做primary key还好呢?
个人看法：这个看业务需要，如果加上一个毫无意义的ID，却导致6个字段有重复值，反而给后续使用带来麻烦
3.若2中的假设正确，那么primary key的字段不超过表中总字段的时候可以用多个字段做primary key才能发挥到primary key的查询的效率呢？
个人看法：这个没有所谓的“最佳实践”
------解决方案--------------------
首先科普一下:
1.一个表只能有一个主键和一个聚集索引.
2.默认情况下,主键字段等于聚集索引字段.
3.聚集索引决定表数据页在磁盘上的存储顺序.
建议:
如果该表新增的数据是按该6个字段顺序递增的,可以将主键设为聚集索引.
若不是顺序递增的,用自增列做聚集索引,主键仍为该6个字段即可.
------解决方案--------------------
楼主的问题没有绝对的答案。
例如，太多字段做primary key。何谓太多，6个bit数据类型的字段，一点都不算多呀。
其次，这6个字段组成的索引就已经覆盖了频繁查询的所有字段，就对查询有益，因为不用去找数据页。
另外，还跟数据量有关，哪果只是几百条数据，查询分析器可能直接就去扫描数据页。