我听说（从一位同事那里听到的，他是从另一位开发人员那里听到的）VARCHAR 列应该始终放在 MySQL 中表定义的末尾，因为它们的长度是可变的，因此可能会减慢查询速度。
然而，我对堆栈溢出所做的研究似乎与此相矛盾，并表明列顺序很重要，而对于这在多大程度上适用于 VARCHAR，存在不同的共识。
他没有具体说明存储引擎，也没有说明这是否只适用于不经常访问的 VARCHAR 列。
问有关“MySQL”的问题没有任何帮助，因为 MySQL 将存储委托给存储引擎，并且它们以非常不同的方式实现存储。对于任何单独的存储引擎来说这个问题都是有意义的。
在MEMORY引擎中，不存在可变长度数据类型。 VARCHAR 会默默地更改为 CHAR。在您的问题的上下文中：将 VARCHAR 放在表定义中的位置并不重要。
在 MyISAM 引擎中，如果表没有任何可变长度数据（VARCHAR、VARBINARY 或任何 TEXT 或 BLOB 类型），则它是 MyISAM 的 FIXED 变体，即记录具有固定字节长度。这可能会对性能产生影响，尤其是在重复删除和插入数据的情况下（即表不是仅追加的）。一旦任何可变长度数据类型成为表定义的一部分，它就会成为 MyISAM 的 DYNAMIC 变体，并且 MyISAM 会在内部将除最短 CHAR 类型之外的任何类型内部更改为 VARCHAR。同样，CHAR/VARCHAR 的位置甚至定义并不重要。
在InnoDB引擎中，数据存储在16KB大小的页中。页面具有带有校验和的页脚、页眉以及页面目录等。页目录包含每行该行相对于页开头的偏移量。页面还包含可用空间，所有 I/O 都在页面中完成。
因此，只要页面中有可用空间，InnoDB 就可以就地增长 VARCHAR，并在页面内移动行，而不会产生任何额外的 I/O。此外，由于所有行都被寻址为（页号，页目录条目），因此页内行的移动被本地化到该页并且从外部不可见。
这也意味着对于 InnoDB 来说，行内列的顺序根本不重要。
这是 MySQL 最常用的三种存储引擎，列的顺序对于这三种引擎中的任何一个都无关紧要。可能存在其他更奇特的存储引擎，但情况并非如此。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
