设计数据库时是否有列排序的最佳实践？顺序会影响性能、空间或 ORM 层吗？
我知道SQL Server - 列顺序重要吗？。我正在寻找更一般的建议。
我不认为列顺序一定会影响性能或空间。为了提高性能，可以在表上创建索引，索引中定义的列的顺序会影响性能。
我见过表的字段按字母顺序以及“逻辑”顺序（以对所表示的数据有意义的方式）排序。总而言之，我可以看到两者的好处，但我倾向于选择“逻辑”方法。
在 Oracle 中，如果您的表有许多可为 NULL 的列，并且您将可为 NULL 的列放在列表的末尾，则可以显着节省存储空间。行尾的 NULL 值不占用空间。 例如想象一下这张桌子：
(id NOT NULL, name VARCHAR2(100), surname VARCHAR2(100), blah VARCHAR2(100, date_created DATE NOT NULL)第
(100, NULL, NULL, NULL, '10-JAN-2000')行需要存储值 100，需要一些空间来存储三个 NULL，后跟日期。
或者，同一张表但顺序不同：
(id NOT NULL, date_created DATE NOT NULL, name VARCHAR2(100), surname VARCHAR2(100), blah VARCHAR2(100))行
(100, '10-JAN-2000', NULL, NULL, NULL)仅需要存储值 100 和日期 - 完全省略尾随的 NULL。
通常这没什么区别，但对于具有许多可 NULL 列的非常大的表，可以显着节省 - 使用的空间更少可以转化为每个块更多的行，这意味着查询表所需的 IO 和 CPU 更少。
我认为这不会影响性能，但从开发人员的角度来看，阅读经常更新的前几列比尝试在最后扫描整个表以查找该字段更容易。
RDBMS 服务器在内部针对查询优化此类内容，因此我怀疑这并不重要。
如果您的索引处于打开状态（姓氏、名字）并且您始终搜索姓氏，那么即使您不包含名字也可以继续搜索
如果您的索引如下所示（名字，姓氏）并且您的 where 子句是
where lastname like 'smith%'
那么你必须扫描整个索引
不同的 DBMS 会以不同的方式实现这些事情。
但是，聪明的 DBMS 会实现内部结构，这样列排序就不会产生影响。
因此，我会安排我的专栏对人类读者来说是直观的。
但是，我稍后不会重新排列列以支持更逻辑的分组。