Postgresql 中的 id 列位置重要吗？答案

【问题标题】：Is id column position in Postgresql important?Postgresql 中的 id 列位置重要吗？
【发布时间】：2018-04-15 15:56:21
【问题描述】：

我正在测试删除主键列 id 的迁移（我想使用外键作为主键）。当我运行并恢复迁移时，我看到我的表的状态是相同的，除了 id 列现在是最后一个。

它会以任何方式改变我的数据库的行为吗？我是否应该费心恢复迁移还原代码中的列顺序？

【问题讨论】：

列的相对位置应该对性能基本没有影响。由于字段对齐，可能会有一些小问题。
@GordonLinoff 这看起来像是一个答案。另外，您能否澄清一下这些次要考虑因素是什么？
。 .我对 Postgres 的页面布局不是很熟悉。我不知道它是否根据字段的对齐来优化列排序（例如，消除间隙）。我希望对具体的了解更多的人来回答。
数据库的行为不会改变，但是一些使用该数据库的设计不佳的应用程序可能会崩溃 - 这些应用程序使用 SELECT * 检索数据而不是显式声明列列表 SELECT col1, col2, ... 和这些使用INSERT INTO TABLE VALUES (1,2,3,...) 而不是明确声明字段名称INSERT INTO (col1, col2 ...) VALUES (1,2,3,...)。列的“默认”顺序将更改，应用程序将失败。无论如何，这不是你的数据库的问题，而是应用程序设计者的问题。

标签： sql postgresql primary-key

【解决方案1】：

理论上一切都应该没问题，但总有你的代码可能失败的情况。

例如：

a)blind insert:

 INSERT INTO tab_name
 VALUES (1, 'b', 'c');

盲插入是指 INSERT 查询未指定哪些列接收插入的数据。

为什么这是一件坏事？

因为数据库架构可能会改变。列可以移动、重命名、添加或删除。当它们是时，至少三件事之一可以发生：

查询失败。这是最好的情况。有人从目标表中删除了一个列，现在没有足够的列要进入的插入，或者有人更改了数据类型和插入的类型不兼容，等等。但至少你的数据没有得到损坏，您甚至可能知道问题的存在是因为错误信息。

查询继续工作，没有任何问题。这是一个中间最坏的情况。您的数据没有损坏，但怪物还是躲在床底下。

查询继续工作，但现在一些数据被插入到它不属于的地方。您的数据已损坏。

b)ORDER BY oridinal

SELECT *
FROM tab
ORDER BY 1;

【讨论】：