sql-server – SQL Server与单列或多列主键的性能差异？

发布时间：2020-12-12 07:09:13 所属栏目：MsSql教程来源：网络整理

导读：如果主键是单列(例如,为每行生成的GUID)或多列(例如,外键GUID和偏移号),则表(在插入/更新和查询方面)性能是否有任何差异？ )？我会假设查询速度应该更快,如果有任何多列主键,但我会想象插入会更慢,因为一个稍微复杂的独特检查？我还想象多列主键的数据类型也

如果主键是单列(例如,为每行生成的GUID)或多列(例如,外键GUID和偏移号),则表(在插入/更新和查询方面)性能是否有任何差异？ )？

我会假设查询速度应该更快,如果有任何多列主键,但我会想象插入会更慢,因为一个稍微复杂的独特检查？我还想象多列主键的数据类型也很重要(例如,如果其中一列是DateTime类型,则会增加复杂性).这些只是我想要调用答案的想法.讨论(希望！)并且不是基于事实的.

我知道有some其他questions涵盖了这个主题,但我想知道性能影响而不是管理/业务问题.

解决方法

密钥的(每个)组件将受到更多的影响：(a)可变长度和(b)宽度[宽而不是窄列],而不是密钥中的组件数量.除非MS在最新版本中再次打破它(他们在2005年打破了Heaps).数据类型不会减慢速度;宽度,特别是可变长度(任何数据类型).请注意,如果将固定的len列设置为Nullable,则将其设置为可变列.索引中的变量len列是坏消息,因为必须在每次访问时执行一些“解包”以获取数据.

显然,使用固定列而不是Nullable列,尽可能缩小索引列.

就复合键中的列数而言,确保一列比七列快,但不是那么多：三个胖宽变量列比七个精简固定列慢得多.

GUID当然是一个非常肥胖的关键; GUID加上任何其他东西都非常胖; GUID Nullable是Guiness材料.不幸的是,它是解决IDENTITY问题的下意识反应,这反过来又是因为没有选择好的自然关系键.因此,建议您最好在源头修复真正的问题,并选择好的自然键;避免身份;避免GUID.

经验和性能调整,而不是猜想.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!