fra*_*cca 45 sql indexing performance
我正在使用的团队决定使用varchar主键创建一个表.此表由此主键上的另一个表引用.
我有习惯按照我在大学学到的东西来创建一个整数主键.我已经读过使用整数主键可以提升性能.
问题是我不知道创建整数主键的任何其他原因.你有什么建议吗？
Rem*_*anu 44
VARCHAR与INT并没有多大关系.什么是访问模式.
从绝对意义上讲,更宽的密钥总是比窄密钥更差.这种类型绝对不重要,重要的是宽度.虽然与INT相比,很少有类型可以在狭窄的范围内击败INT,因此INT通常仅通过4字节宽的事实赢得该参数.
但真正重要的是群集密钥的选择.与主键经常被混淆,这两个代表不同的概念,并且不重叠必需的.这是更详细的讨论我应该设计一个主键为varchar或int的表吗？集群密钥的选择只是表格设计中最重要的决定,而机械上应用INT identity(1,1)它可能只是人们可能犯的最大错误.以下是访问模式的问题:
总的来说,有许多访问模式可以通过使用INT IDENTITY集群密钥来破坏.因此,在开始应用cookie切割器解决方案之前,可能需要进行一些分析......
更一般的指导原则:
您看到没有主键设计指南,因为主键不是存储设计的问题,而是建模问题,完全是域驱动的.
Mar*_*ers 40
主键应该表示行的标识,不应随时间变化.
我假设varchar是某种自然键 - 例如实体名称,电子邮件地址或序列号.如果您使用自然键,则有时可能会发生密钥需要更改,例如:
通过使用代理键,可以避免因必须更改主键而导致的问题.
one*_*hen 25
我有点失望,因为我习惯于创建一个整数主键(遵循一些老师在大学告诉我的).我已经阅读了很多关于使用整数主键提升性能的文档.
有一个术语:确认偏见:
"也称为确认性偏见或偏见偏见"是人们倾向于支持确认其先入之见或假设的信息,而不管它们是否属实.这导致人们选择性地收集新证据,以偏见的方式解释证据,或选择性地回忆记忆中的信息."
当然,你的第一反应就是说,"但那不是真的!" 是的,你会说'因为你有偏见;)[舌头紧紧地嵌在脸颊]
这是一个典型的例子:说你的动物学教授告诉你所有的天鹅都是白色的,当然,你和你的朋友遇到的所有天鹅都是白色的.现在让我们说晚年生活中一位同事表达了这样一种观点,即也许有一种黑天鹅这样的生物.什么？!这不是你所教的.你的世界震撼了!你立即出去进行天鹅调查,你就会计算出1000只白天鹅和零天鹅.证明!如果你发现了10,000只白天鹅,那么假设"所有天鹅都是白色的"将是十倍真实,对吧？
一种不同的方法是暂时忘记白天鹅并试图寻找黑天鹅.也许在阳光明媚的Dawlish海边度假？
我真的不是故意不尊重; 你承认读了很多关于你被告知的事情,这确实赢得了我的尊重.所以这是一个挑战:尝试找到不必在表中添加整数列的情况.
以下是一些提示和破坏者:未被其他表引用的表; 单列'所有键'查找表; '小'表没有被查询太多:)
以下是您可能要调查的其他一些相关主题:
"主键"中的"主要"一词是否具有很多含义,或者给定表中的所有键是否相等？
"好"钥匙的特质是什么？(例如,一个键的值是不可变的还是一个稳定'好'足够？)
是一个整数列作为人工键添加到表中(perhpas因为可用的自然键不够"好")或作为代理键(可能是为了提高其他'好'自然键的性能)？
当代理键在性能方面被添加到表中时,这是实际测量的效果还是仅仅是感知效果(即过早优化)？
代理键是否应出现在逻辑业务模型中,还是仅用于实现？
总是做一些事情是一个好主意(例如,将一个整数列添加到表格中),而不是每次都吸引大脑？;)
[免责声明:我是一个天生的主要倡导者并避开代理人.对我而言,它们就像非规范化一样:只有在必要时才会这样做,通常是针对性能问题(具体和可证明的),故障存在于其他地方(糟糕的SQL产品版本,此时无法修复的逻辑设计缺陷等) ).代理人不应该出现在逻辑商业模式中.我有时需要一个人工识别器,甚至暴露他们逻辑商业模式.]