我已经经历过 数据库设计：复合键与一列主键
对于永远不能被任何其他表引用为外键的表，单列/简单主键与多列/复合主键在插入和更新方面有何优缺点？
是的，多列主键仍然是一个糟糕的选择，如果：
因为：
因此：如果您有一个大小为 200 字节的复合主键，并且表上有一些非聚集索引，那么您将在 SQL Server 上浪费大量内存 - 而不仅仅是在 SQL Server 上（相对便宜的）磁盘，但也在 SQL Server 主内存中（通常不那么便宜）。
除了浪费空间之外，您的性能也会滞后，因为较大的索引意味着相同操作需要更多的磁盘 I/O。
一般来说：仅如果您从不需要引用该表（实际上永远不需要，甚至将来也不需要），并且该表上没有其他非聚集索引，则在表上使用复合主键。
你怎么可能绝对确定你的密钥“永远不会被 FK 引用”？
您的属性组合确实是唯一的（否则您不会考虑将其设为“主键”）。
因此，您的属性组合是识别表中描述的现实世界事物的有效方法。
说 FK 永远不会引用这一点，就等于说“关于此类事物的额外信息永远不会与业务相关”。你怎么可能知道？
业务需求（数据完整性要求）应该是实施哪些密钥的决定因素。对一个属性强制唯一性显然与对多个属性强制唯一性不同，因为在一种情况下允许的重复项在另一种情况下则不允许（当然，除非您实现 both 键）。
请注意，marc 的答案仅适用于聚集索引，不适用于主键。它们不是同一件事。他的回答也是针对 SQL Server 的。
在这个问题上有两种相互竞争的哲学。
我本人坚定地支持对某些表使用复合主键。
当我设计数据库时，我使用 ER 建模将信息需求收集到一个地方。数据库提供的每个值都是属性的实例，并且每个属性描述主题实体或两个或多个主题实体之间的关系。外键不会进入分析阶段。
在开始数据库设计之前，我从应用程序的角度决定如何识别每个实体。这些将给我我的主键。每个描述实体的表都有一个简单的主键，即实体的标识符。简单关系（二元、多对一）不需要自己的表。每个描述复杂关系的表都会有一个由参与实体的主键组成的复合主键。
外键以明显的方式插入。嗯，至少对我来说是显而易见的。这提供了 3NF 甚至更高的初始表设计。表设计可能会通过进一步规范化或与规范化不兼容的其他设计模式（所谓的非规范化）来更改。但这是餐桌设计的第一次。
这种设计实践在性能和数据完整性方面与现行实践产生了不同的结果。普遍的做法是将一个名为“id”的自动编号列作为每个表的第一列。该列成为主键。
本质上，这种做法使用 SQL 表结构来模仿数据的图模型，即使它看起来像关系模型。 id 列本质上是行地址的代理。数据的图模型有优点也有缺点。如果需要的话，可以详细了解这一点。