我听说在编写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 *(想象有许多列并执行JOIN…)查询可能会变得很糟糕)。然后，测量。与显式列出列名的查询进行比较。
不要猜测业绩，要衡量业绩!
当你有一些包含大数据的列(比如一篇文章的主体)，并且在给定的查询中不需要它时，显式列表是最有用的。然后，通过在应答中不返回它，DB服务器可以节省时间、带宽和磁盘吞吐量。您的查询结果也会更小，这对任何查询缓存都是有利的。
当我们需要所有列时，我认为select *比所有列都快。
对服务器来说，指定列名肯定更快。但是,如果
性能不是大问题(例如，这是一个网站内容数据库，每个表中有数百行，可能是数千行，但不是数百万行);和 你的工作是使用公共框架创建许多小型的类似应用程序(例如面向公众的内容管理网站)，而不是创建一个复杂的一次性应用程序;和 灵活性很重要(为每个站点定制大量的db模式);
那么你最好坚持使用SELECT *。在我们的框架中，大量使用SELECT *允许我们将一个新的网站托管内容字段引入到一个表中，赋予它CMS的所有好处(版本控制、工作流/审批等)，同时只在几个点上修改代码，而不是几十个点。
我知道DB专家们会因此而恨我——请继续，投我反对票——但在我的世界里，开发人员的时间是稀缺的，而CPU周期是丰富的，所以我相应地调整我所节省的和浪费的。
