在学习mysql的过程中，我了解到在mysql表中添加列时可以执行以下语句：
ALTER TABLE contacts ADD email VARCHAR(60) AFTER name;
或
ALTER TABLE contacts ADD email VARCHAR(60) FIRST;
您希望何时执行此操作？列顺序可以用于查询优化目的吗？ longblob 是否应该是优化空间消耗的最后一列？或者这些命令是否存在其他原因？
【问题讨论】：
这个问题与关系模型或 SQL 无关。这是一个性能问题。
在某些数据库中，由于执行磁盘访问的方式，以特定方式对列进行排序会更有效。是否有显着优势也取决于平台。这是与底层存储的设计方式和引擎访问它的方式有关的低级 i/o 问题。专有引擎提供商通常通过其教育和培训部门提供此信息。
我认为您必须与了解特定平台上 MySQL 的存储模型和 i/o 方法的基本细节的人或在您的平台上对此进行过基准测试的人交谈以获得答案.
他们完全有可能以优化的方式将其放在磁盘上，并对您隐藏该列的顺序。
【讨论】：
不过，这会影响select * from mytable 中结果的顺序。
这就是为什么您应该始终在 select 语句中命名列，例如select col1, col2 from mytable。但是如果您知道该应用程序正在使用*，那么您在添加列时必须小心。
否则，请按最符合逻辑的方式对列进行排序。如果它影响性能，则意味着您已经处于数据库性能调整的阴暗面，并且您可能在其他地方遇到了问题。
【讨论】：
是的，列顺序确实很重要。但是，如果您希望进行优化，您最有可能的选择（在 90% 的情况下）是添加索引。 MySQL 官方文档只讨论了添加索引上下文中的优化（来源：Dev.MySQL.com: How MySQL Uses Indexes）。
但是对于这个问题——列顺序绝对重要。这实际上完全取决于 链式行 和内存块在 MySQL 引擎中的工作方式。在 The Secrets of Oracle Row Chaining and Migration 的一篇文章中引用 Martin Zahn，an Oracle-certified professional...
链式行对我们的影响不同。在这里，这取决于我们需要的数据。如果我们有一个包含两列的行，分布在两个块上，查询：
SELECT column1 FROM tablecolumn1 位于块 1 中，不会导致任何«table fetch continue row»。它实际上不必获取 column2，它不会一直跟随链接的行。另一方面，如果我们要求：
SELECT column2 FROM table并且由于行链接，column2 在 Block 2 中，那么您实际上会看到一个«table fetch continue row»
这清楚地给我们的印象是，如果我们选择 column2 多于选择 column1，那么我们应该对列重新排序以优化我们的数据库查询。
我在 HP Enterprise 论坛上找到了 2002 年的旧帖子，在搜索后至少有一百个帖子重新复制了该帖子。这里关于如何进行列排序的建议似乎与专业人士的详细解释相匹配。所以，差不多 20 年后，我不得不说：谢谢，Bill Thorsteinson！
要优化查询，请根据以下规则对列进行排序：
- 主键列优先。
- 接下来是外键列。
- 接下来是经常搜索的列。
- 以后经常更新的专栏。
- 可空列最后。
- 使用频率最低的可空列排在最常使用的可空列之后。
- 自己的表中存在 Blob，其他列很少。
来源：HP Forums
【讨论】：
关系模型没有行内列排序的概念，也没有表内行排序的概念。
【讨论】：
不应该没关系。规范化的数据库也不应该对列顺序有限制。
【讨论】：
列顺序无关紧要。这纯粹是一个方便的功能。只是为了让您在创建数据库表后以您喜欢的方式重组它。
【讨论】：
“你想什么时候使用它”而不是性能问题。
如果主从之间的列顺序不同并且列类型不兼容（错误 1677），基于行的复制将中断。
ALTER TABLE contacts MODIFY email VARCHAR(60) AFTER name;
将是解决此问题的一种方法。
【讨论】：
我认为它与性能无关，但在某些情况下 - 当您使用索引时。
示例。
我用过连接表：
| category_id | user_id |
两列分别为unsigned int (10) 和primary key ( category_id, user_id )
注意列的顺序。当我开始使用where user_id = ? 从该表中进行选择时 - 性能很低。
在我更改列的顺序（首先设置 user_id）后，它开始选择时间更快。
【讨论】：