SQL表的性能设计

Question

我正在为一个网站设计一个数据库，在那里性能是最重要的。

关键功能基于两个表。

这张桌子上有很多关系船。

为了分割这一点，我添加了一个额外的表Table1_Table2，然后根据每个关系保存两个tabl'e主键的组合。

我把所有的车都放在汽车桌上，所有的颜色都放在彩色桌子上

CarTable

ID(PK) -名称

1._

2成品率成品率

(三)再转轨-转轨

4/4-直接性-转轨性- AUdi

ColorTable

ID(PK) -颜色

1._

2.商品

第三次再转轨制

第四条

对于许多人的关系，我做过这样的事：

Car_ColorTable

ID(PK) - CarID - ColorID

1-2

2

3

4

5

6

7

这是一个很好的设计考虑到：

1)性能是重中之重。

2)这些表将拥有大量的数据(两个表中都有100多万个记录，您可以想象在Car_ColorTable中将有多少行结束。

如果上面的设计不是解决方案，我该如何设计呢？

Answer 1

应该是Car_ColorTable

CarID (PK) - ColorID (PK)

你不想看到id列，

主键应同时包含两列

您可以创建类似的非聚集索引，列的顺序为oposite，这意味着(ColorID，CarID)

就这样

Answer 2

这是最好的方式来描绘这种关系。只需确保您知道通常尝试从哪个对象获取关系，并将聚集索引放在该列上即可。

您也可以选择创建一个组合PK，但是您不能使用任何重复的PK。

Answer 3

您可能是想说，选择性能是最重要的。但是，不能让SELECT性能优于数据完整性。快速得到错误的答案从来不是一个好的要求。

如果使用代理键(整数)，则主键应该是primary key (car_id, color_id)。附加的代理键"ID“在这里是无用的，通常会损害SELECT性能。(更多列、更宽的行、磁盘上每个数据页的行数更少、磁盘I/O更多)

您应该使用自然键(汽车名称和汽车颜色)和代用品键进行测试。代理键对于每个查询都需要两个联接；自然键不需要连接。使用代理键(汽车、颜色)的表仍然需要对名称进行唯一的约束。您以后不会想知道“蓝色”有13个不同的ID号。

用一两个小时编写一个脚本，生成有和没有代理键的几百万行，并比较性能。