是否有任何理由担心表中的列顺序?

我知道你可以用FIRST和AFTER来改变MySQL的列顺序,但你为什么要打扰呢? 由于好的查询在插入数据时显式地命名列,是否真的有理由关心你的列在表中的顺序?

列顺序对我调整的一些数据库有很大的性能影响,包括Sql Server,Oracle和MySQL。 这个职位有很好的经验 :

  • 主键列首先
  • 接下来是外键列。
  • 下一个频繁search的列
  • 以后经常更新列
  • 可空列最后。
  • 在使用更多的可空列之后,最less使用可为空的列

性能差异的一个例子是索引查找。 数据库引擎根据索引中的一些条件find一行,并取回一个行地址。 现在说你正在寻找SomeValue,它在这张表中:

SomeId int, SomeString varchar(100), SomeValue int 

引擎必须猜测SomeValue的起始位置,因为SomeString的长度是未知的。 但是,如果您将订单更改为:

  SomeId int, SomeValue int, SomeString varchar(100) 

现在引擎知道SomeValue可以在行开始之后find4个字节。 所以列顺序可能会有相当大的性能影响。

编辑:SQL Server 2005存储固定长度的字段在行的开始。 每行都有一个对varchar开始的引用。 这完全否定了我上面列出的效果。 所以对于最近的数据库,列顺序不再有任何影响。

更新:

MySQL ,这可能是有原因的。

由于variables数据types(如VARCHAR )在InnoDB以可变长度存储,因此数据库引擎应该遍历每行中的所有先前列以找出给定偏移量。

20列的影响可能高达17%

在我的博客中查看这个条目了解更多详情:

  • select列顺序

Oracle ,后面的NULL列不会占用空间,这就是为什么你总是把它们放在表的最后。

同样在OracleSQL Server ,如果行较大, ROW CHAINING可能发生ROW CHAINING

ROW CHANING正在拆分一个不适合一个块的行,并将其跨越多个块,并与一个链表相关联。

读取不适合第一个块的尾部列将需要遍历链接列表,这将导致额外的I/O操作。

请参阅此页面以查看OracleROW CHAINING

这就是为什么你应该把你经常使用的列放到表的开头,你不经常使用的列或者往往是NULL列到表的末尾。

重要的提示:

如果你喜欢这个答案,并希望投票支持,也请投票支持@Andomar的回答 。

他回答同样的问题,但似乎没有理由低估了。

在之前的Oracle培训工作中,我们的DBAbuild议把所有不可为空的列放在可为空的列之前是有利的…虽然TBH我不记得详细的原因。 或者,也许这只是那些可能会得到更新应该在最后? (如果扩展的话也许会推迟行)

一般来说,它不应该有任何区别。 正如你所说,查询应该总是自己指定列,而不是依靠“select *”的顺序。 我不知道任何数据库允许他们被改变…嗯,我不知道MySQL允许它,直到你提到它。

一些写得不好的应用程序可能依赖于列顺序/索引而不是列名。 他们不应该,但它确实发生。 改变列的顺序会破坏这样的应用程序。

当你input以下内容时输出的可读性:

 select * from <table> 

在你的数据库pipe理软件?

这是一个非常虚假的原因,但目前我不能想到别的。

不,SQL数据库表中列的顺序是完全不相关的 – 除了显示/打印的目的。 对列进行重新sorting没有任何意义 – 大多数系统甚至不提供这种方式(除了删除旧表并使用新的列顺序重新创build表)。

渣子

编辑:从关系数据库维基百科条目,这是相关的部分,我清楚地表明,列顺序应该永远不会担心:

关系被定义为一组n元组。 在math和关系数据库模型中,一个集合是一个无序的项目集合,尽pipe一些DBMS对他们的数据施加了一个顺序。 在math中,一个元组有秩序,并且允许重复。 EF Codd最初使用这个math定义来定义元组。 后来,这是EF Codd的一个很好的见解,即在基于关系的计算机语言中,使用属性名称而不是sorting会更加方便(通常)。 这种见解今天仍在使用。

我能想到的唯一原因就是debugging和灭火。 我们有一张桌子,名字列出现在名单上的第十位。 当你从(1,2,3)中的id表中快速select*,然后你必须滚动查看名字,这是一个痛苦。

但是这是关于它的。

通常情况下,最大的因素是下一个必须在系统上工作的人。 我尝试首先使用主键列,然后使用外键列,然后按照对系统重要性/重要性的降序排列其余列。

除了显而易见的性能调优外,我只是遇到了一个重新sorting列导致(以前的function)的SQL脚本失败的情况。

从文档“TIMESTAMP和DATETIME列没有自动属性,除非它们被明确指定,但有以下例外:默认情况下,第一个TIMESTAMP列同时具有DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP,如果没有明确指定” https://dev.mysql .COM / DOC / refman / 5.6 / EN /时间戳initialization.html

所以,一个命令ALTER TABLE table_name MODIFY field_name timestamp(6) NOT NULL; 如果这个字段是表中的第一个时间戳(或date时间),将会工作,但不是。

显然,你可以修改alter命令来包含一个默认值,但是由于列重新sorting而停止工作的查询使得我的头受到伤害。

唯一需要担心列顺序的是如果您的软件特别依赖于该顺序。 通常,这是由于开发人员懒惰并做了select * ,然后通过索引而不是按名称在结果中引用列。

如果你打算使用UNION,那么如果你有一个关于sorting的约定,它会使匹配的列更容易。

一般来说,在通过Management Studio更改列顺序时,SQL Server中会发生什么情况,它是使用新结构创build临时表,将数据从旧表移动到该结构,然后删除旧表并重命名新表。 就像你想象的那样,如果你有一张大桌子,这对性能来说是一个很差的select。 我不知道我的SQL是否也一样,但这是我们许多人避免重新sorting列的一个原因。 由于select *决不能在生产系统中使用,因此最后添加列对于devise良好的系统来说不是一个好现象。 表格中列的顺序不应该混淆。

如上所述,有许多潜在的性能问题。 我曾经在一个数据库上工作,如果你没有在查询中引用这些列,那么在最后加上非常大的列可以提高性能。 显然,如果一条logging跨越了多个磁盘块,数据库引擎一旦获得所有需要的列,就可以停止读取块。

当然,任何性能影响都不仅取决于您使用的制造商,还取决于版本。 几个月前,我注意到我们的Postgres不能使用索引来进行“类似”的比较。 也就是说,如果你写了“像'M%'这样的列',那么跳到M就不够聪明了,find第一个N就退出了。我打算改变一堆查询来使用”between“。 然后我们得到了一个Postgres的新版本,它处理类似的智能。 很高兴我永远不会改变查询。 显然这里并不直接相关,但我的观点是,任何你为了效率考虑而做的事都可能在下一个版本中被淘汰。

列顺序几乎总是与我非常相关,因为我经常编写读取数据库模式以创build屏幕的通用代码。 就像,我的“编辑logging”屏幕几乎总是通过阅读架构来获得字段列表,然后按顺序显示它们。 如果我改变了列的顺序,我的程序仍然可以正常工作,但显示对用户来说可能很奇怪。 喜欢,你希望看到名称/地址/城市/州/邮编,而不是城市/地址/邮编/名称/状态。 当然,我可以把列的显示顺序放在代码或控制文件中,但是每次我们添加或移除列时,都必须记得更新控制文件。 我喜欢说一次。 而且,当编辑屏幕纯粹是从模式构build的时候,添加一个新表格可能意味着编写零行代码来为其创build编辑屏幕,这很酷。 (好吧,在实践中,通常我必须在菜单中添加一个条目来调用通用编辑程序,而且我通常会放弃generics“select要更新的logging”,因为有太多例外可以实现。)