我听说在编写SQL命令时使用SELECT *通常是不好的做法，因为选择您特别需要的列会更有效。
如果我需要选择表中的每一列，我应该使用
SELECT * FROM TABLE
or
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下，效率真的重要吗?如果你真的需要所有的数据，我认为SELECT *在内部会更优，但我这么说并没有真正理解数据库。
我很好奇在这种情况下最好的做法是什么。
更新:我可能应该指定，我真正想要执行SELECT *的唯一情况是，当我从一个表中选择数据时，我知道总是需要检索所有列，即使添加了新列。
然而，鉴于我所看到的反应，这似乎仍然是一个坏主意，由于我曾经考虑过的许多技术原因，SELECT *不应该被使用。
当前回答
我发现，如果其他开发人员可能会使用代码，或者数据库可能会更改，那么列出列名就特别重要，这样您就可以始终获得一致的数据。
其他回答
在性能方面，具有特定列的SELECT可以更快(不需要读入所有数据)。如果您的查询确实使用了所有列，那么带显式参数的SELECT仍然是首选。任何速度差异基本上都是不明显的，并且接近恒定时间。总有一天你的模式会改变，这是预防由此产生问题的好保险。
同时也要记住变化。今天，Select *只选择您需要的列，但明天它可能还会选择我刚刚添加的varbinary(MAX)列，而您现在还可以检索所有3.18 gb的二进制数据，这些数据昨天不在表中。
总之，至少在PostgreSQL中，选择所有带*和不带*的列的性能几乎是一样的。
在PostgreSQL中，我创建了包含10个id_x列和1000万行的测试表，如下所示:
CREATE TABLE test AS SELECT generate_series(1, 10000000) AS id_1,
generate_series(1, 10000000) AS id_2,
generate_series(1, 10000000) AS id_3,
generate_series(1, 10000000) AS id_4,
generate_series(1, 10000000) AS id_5,
generate_series(1, 10000000) AS id_6,
generate_series(1, 10000000) AS id_7,
generate_series(1, 10000000) AS id_8,
generate_series(1, 10000000) AS id_9,
generate_series(1, 10000000) AS id_10;
然后，我交替运行以下2个查询共20次。*每个查询总共运行10次:
SELECT * FROM test:
SELECT id_1, id_2, id_3, id_4, id_5, id_6, id_7, id_8, id_9, id_10 FROM test;
结果> <
| Select all columns with * | Select all columns without * | |
|---|---|---|
| 1st run | 12.792 seconds | 12.483 seconds |
| 2nd run | 12.803 seconds | 12.608 seconds |
| 3rd run | 12.537 seconds | 12.549 seconds |
| 4th run | 12.512 seconds | 12.457 seconds |
| 5th run | 12.570 seconds | 12.487 seconds |
| 6th run | 12.508 seconds | 12.493 seconds |
| 7th run | 12.432 seconds | 12.475 seconds |
| 8th run | 12.532 seconds | 12.489 seconds |
| 9th run | 12.532 seconds | 12.452 seconds |
| 10th run | 12.437 seconds | 12.477 seconds |
| Average | 12.565 seconds | 12.497 seconds |
选择所有列的平均值:
*是12.565秒。 没有*是12.497秒。
为应用程序中期望获得的每一列命名还可以确保如果有人更改表，只要您的列仍然存在(以任何顺序)，应用程序就不会崩溃。
在某些情况下，SELECT *适用于维护目的，但一般情况下应该避免使用。
These are special cases like views or stored procedures where you want changes in underlying tables to propagate without needing to go and change every view and stored proc which uses the table. Even then, this can cause problems itself, like in the case where you have two views which are joined. One underlying table changes and now the view is ambiguous because both tables have a column with the same name. (Note this can happen any time you don't qualify all your columns with table prefixes). Even with prefixes, if you have a construct like:
选择A.， B. -您可能会遇到客户端现在难以选择正确字段的问题。
一般来说，我不使用SELECT *，除非我在做一个有意识的设计决策，并指望相关的风险很低。
