考虑下面的示例表（假设SQL Server 2005）：
create table product_bill_of_materials ( parent_product_id int not null, child_product_id int not null, quantity int not null )
我正在考虑一个复合主键，该主键包含两个product_id列（我肯定会想要一个唯一约束），而不是一个单独的唯一ID列。从性能的角度来看，问题是该主键是否应该集群？
我是否还应该在每个ID列上创建一个索引，以便更快地查找外键？我相信该表在读取方面比在写入方面会受到更多的打击。
正如其他一些人已经说过的那样，这取决于您如何访问表。但是请记住，那里的任何RDBMS都应该能够使用聚簇索引来按单个列进行搜索，只要该列首先出现即可。例如，如果您的聚集索引位于（parent_id，child_id）上，则不需要其他单独的索引位于（parent_id）。
最好的选择可能是（parent_id，child_id）上的聚集索引，它也恰好是主键，而（child_id）上有一个单独的非聚集索引。
最终，应该在了解如何访问数据库之后再解决索引问题。如果可以，请提供一些标准的性能压力测试，然后使用性能分析工具（SQL Server的SQL Profiler）分析行为并从那里进行性能调整。如果您不具备提前完成此任务的专业知识或知识，请尝试发布（希望是受限制的）应用程序，收集性能指标，并查看需要在哪些方面提高性能并找出哪些指标将有所帮助。
如果操作正确，则应该能够捕获有关数据库访问方式的“典型”配置文件，然后您可以在尝试各种索引方法时在测试服务器上一遍又一遍地重新运行该配置文件。
在您的情况下，我可能只是将一个群集PK放在（parent_id，child_id）上，然后仅在看到性能问题可以帮助它时才添加非群集索引。
