数据库：表开头的主键列

是否影响在表的开头有所有主键列？数据库：表开头的主键列

我知道部分索引读取最有可能涉及表格扫描，将整行带入缓冲池进行谓词匹配。我很想知道在表顶部有主键会带来的性能增益。

来源

2013-02-20 Arun Srini

在Oracle中，表的列顺序对性能影响不大。

原因在于一行中的所有列通常包含在一个块中，并且查找块中的第一列和最后一列之间的时间差异是无限小的，与查找/读取块。

此外，当您到达数据库块以读取一行时，主键可能不是最重要的列。

这里有一些例外情况列顺序可能会产生影响：当你在你的表> 255列

，该行将在两块（或更多）进行拆分。访问前255列可能比访问其余列要便宜。
如果行的最后一列是NULL，则最后一列需要占用0个字节的空间。因此，如果可能的话，包含许多NULL值的列最好留在行的末尾，以减少空间使用并因此减少IO。一般情况下，由于其他NULL列每个需要1个字节，所以影响将最小，因此节省的空间很小。
启用压缩时，压缩效率可能取决于列顺序。一个好的经验法则是，应该对具有极少不同值的列进行分组，以增强压缩算法将合并它们的机会。
当您使用Index Organized Table（IOT）和overflow clause时，您应该考虑列的顺序。有了这个条款，确定的分隔列之后的所有列都将被存储为非行，并且访问它们将会产生额外的成本。主键始终物理存储在IOT行的开头。

来源

2013-02-20 16:28:55

实际上，如果你在末尾放置了'NON NULL'列（如pk），所有可为空的列都将分配它们的空间。这种行为出现在varchar2中，而不是编号。我不知道其他类型。 – Plouf 2013-02-20 18:06:27

@Plouf - 这假定RDBMS不重新排列列（在实际存储中，而不是在定义中），以便所有非空列首先出现 - 这是一个简单的优化。现在，首先知道_which_nullable列是重要的，根据哪些列最常被填充... – 2013-02-20 23:13:43

@ Clockwork-Muse是的，但是Oracle并没有这样做_trivial optimization_，所以我觉得值得一提的是它。 http://sqlfiddle.com/#!4/438ff/2 – Plouf 2013-02-21 10:10:47

至少在SQL Server中，根据表中的列，主键的顺序，没有性能优势。将主键列放在列表顶部的唯一好处是组织性。有点像有一个表与这些列Id，FirstName，LastName，Address1，Address2，City，State，Zip。按顺序比地址2，州，名，身份证，地址1，姓，邮编，城市要容易得多。我对Oracle或DB2了解不多，但我相信它是一样的。

来源

2013-02-20 16:26:57

在DB2中（我认为其他数据库管理器系统的答案应该检查答案），那些修改较少的列应该位于每行的开头，因为执行更新时需要从第一个修改列直到行的末尾，在事务日志中写入。

它只影响更新操作，插入，删除或选择没有问题。其影响是IO略微减少，因为如果只写最后一列，则应写入更少的信息。在大行记录很多的表格上执行更新时，这可能很重要。如果第一列被修改，DB2将写入整行。

排序列，以尽量减少更新日志：http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0024496.html

来源

2013-02-20 20:30:55 AngocA

（对于Oracle）它是公平地说，那么，任何和所有主键列，即使只是1，应该是当中的第一或前几列连续排列。此外，在行的END上标记它们是不好的做法，特别是在一系列可能的/可能的空属性字段之后？

因此，一排这样的：

pkcol（S），ATT1，ATT2，ATT3，VARCHAR2（2000）

是上面比

ATT1，ATT2陈述的所有原因，更好地组织，att3，varchar2（2000），pkcol（s）

为什么我问？好吧，不要判断，但是我们正在简化一些表格的PK，开发人员很高兴地将新的GUID pk（不要判断＃2）标记到行的末尾。我很困扰这个，但需要一些反馈来证明我的恐惧。对于SQL Server来说，这也是如此吗？

来源

2015-04-22 12:28:43 Allen

数据库：表开头的主键列

回答

相关问题