sql - select * from (select a,b,c ...) 结果列的保证顺序？

Question

我最近在代码审查中有一条评论:

it's better to enumerate the fields explicitly. "select *" doesn't guarantee an order

在这种情况下，对于像 select * from (select a,b,c ...) 这样的查询，情况是否如此？我无法想象一个数据库引擎会重新排序结果中的列，但我的想象比某些数据库引擎更合乎逻辑。

Answer 1

针对select *的建议主要用于直接查询表。

在某些数据库中，可以在表的中途插入一个新列，例如表 t (a, b)成为表格 t (a, c, b) . PostgreSQL(还)不支持这个，但它仍然可以追加列，它可以从任何地方删除列，所以你仍然可以得到 t (a, c)如果你添加 c并放下 b .

这就是为什么使用 * 被认为是不好的做法的原因在生产查询中，尤其是当您的应用程序依赖于序号列位置来读取结果时。但实际上，这仅适用于您未在查询的其他位置指定字段的情况。

在您的情况下，您在子查询中这样做。所以*非常安全，IMO 完全可以接受这种用法。

这个:

select * from (select a,b,c ... from t)

很好。

这个:

select * from t

或

select * from (select * from t)

是有问题的，因为它们给应用程序留下了未定义的列顺序。即便如此，如果您的应用程序采用列顺序而不检查查询元数据，这只是一个问题。

就个人而言，大多数时候我更喜欢完全限定我的专栏，但确实有很多时候 *是最具可读性的选项。

它也是，IMO，使用起来非常好 select *当客户端应用程序按名称而不是序号读取列时。如果您的应用从不关心 c 是否存在是第 2 列或第 3 列，因为它使用结果元数据来构建行字典(就像 Perl 的 DBI 或 Python 的 psycopg2 可以做的那样)那么没有真正的理由不只使用 * .

SELECT * 可能会产生性能成本但是，当您只需要一部分列时。错失了使用仅索引扫描的机会，不必要地获取离线 TOAST 数据，以及因不需要的值而浪费的带宽等等。所以大多数时候这仍然不是一个好主意。