为什么“从表中选择*”被视为不良做法

#1 楼

考虑一下您要返回的内容，以及如何将它们绑定到代码中的变量。

现在考虑当有人更新表架构以添加（或删除）列（甚至是您自己的列）时会发生什么？ '不直接使用。

手动键入查询时使用select *很好，而不是在编写代码查询时。

#2 楼

模式更改


按顺序获取---如果代码获取列＃作为获取数据的方式，则模式更改将导致列号重新调整。
按名称获取---如果代码按名称获取列（例如foo），并且查询中的另一个表添加列foo，则此处理方式尝试获取正确的foo列时可能会导致问题。

无论哪种方式，架构更改都可能导致数据提取出现问题。

进一步考虑是否有一个列正在使用的表从表中删除。 select * from ...仍然可以工作，但是尝试从结果集中提取数据时出错。如果在查询中指定了列，则查询将出错，而不是给出问题的根源和位置的明确指示。

数据开销

某些列可以具有与它们相关的大量数据。选择*将拉回所有数据。是的，这就是您选择的1000行上的varchar(4096)，它为您提供了您可能不需要的4兆字节额外数据，但无论如何都是通过网络发送的。

模式更改时，第一次创建表时varchar可能不存在，但是现在在那里。但只需要其中的2个，就没有传达代码的意图。当查看执行*的查询时，不知道查询的重要部分是什么。我可以更改查询以使用其他计划，而不通过不包含这些列来使其更快吗？我不知道，因为查询返回的意图尚不清楚。


让我们看一些探索这些模式更改的SQL技巧。

首先，初始数据库为：http://sqlfiddle.com/#!2/a67dd/1

DDL：

create table one (oneid int, data int, twoid int);
create table two (twoid int, other int);

insert into one values (1, 42, 2);
insert into two values (2, 43);

SQL：

select * from one join two on (one.twoid = two.twoid);

返回的列是select *，oneid=1，data=42以及twoid=2。

现在，如果我在表一中添加一列会怎样？ http://sqlfiddle.com/#!2/cd0b0/1

alter table one add column other text;

update one set other = 'foo';

和以前相同的查询结果是other=43，oneid=1，data=42和twoid=2 。

其中一个表中的更改中断了other=foo的值，突然您将“ other”与int的绑定将引发错误，并且您不知道为什么。 >
如果相反，您的SQL语句是

select 
    one.oneid, one.data, two.twoid, two.other
from one join two on (one.twoid = two.twoid);

对表1的更改不会破坏您的数据。该查询在更改之前和更改之后运行相同。


索引

执行select *时，您将从所有表中拉出所有行符合条件。甚至您根本不在乎的桌子。虽然这意味着要传输更多的数据，但另一个性能问题却潜伏在堆栈的下方。

索引。 （与SO有关：如何在select语句中使用索引？）

如果要回退很多列，则数据库计划优化器可能会忽略使用索引，因为您仍需要获取所有这些索引无论如何都是列，与使用索引进行完整的表扫描相比，使用索引然后在查询中获取所有列将花费更多的时间。

如果只是选择，一个用户的姓（您需要执行很多操作，因此要有一个索引），数据库可以执行仅索引扫描（仅Postgres Wiki索引扫描，mysql全表扫描与全索引扫描，仅索引扫描）：避免表访问）。

如果可能的话，有很多关于仅从索引读取的优化。可以在每个索引页上更快地获取信息，因为您所获取的信息也更少-您没有为select * from输入所有其他列。仅索引扫描可能会以快100倍的速度返回结果（来源：Select *不好）。

这并不是说完整的索引扫描很棒，但仍然全扫描-但比全表扫描更好。一旦开始追逐select *会影响性能的所有方式，您就会不断发现新的方式。

相关阅读内容


关于在SQL中正确使用*通配符的困惑
（堆栈溢出）：select *与选择列

（堆栈溢出）：为什么SELECT *被认为有害？

#3 楼

另一个需要注意的问题：如果这是一个JOIN查询，而您正在将查询结果检索到一个关联数组中（例如PHP中的情况），则容易出错。

问题在于，如果表foo具有列id和name
如果表bar具有列id和address，
和在您的代码中，您正在使用SELECT * FROM foo JOIN bar ON foo.id = bar.id

猜测当有人在name表中添加一列bar时会发生什么。

该代码会突然停止正常工作，因为现在name列在结果中出现两次，并且如果将结果存储到数组中，第二个name（bar.name）的数据将覆盖第一个name（foo.name）！

这是一个非常讨厌的错误，因为它非常-明显。可能要花一些时间才能弄清楚，而且在表中添加另一列的人不可能预料到这种不良副作用。

（真实的故事）。

因此，不要使用*，要控制要检索的列，并在适当的地方使用别名。

#4 楼

在许多情况下，查询每一列可能是完全合法的。

并非总是查询每列。

数据库引擎需要做更多的工作，它必须反复研究内部元数据，才能确定需要处理哪些列，然后才能继续进行真正的业务。数据并将其发送回给您。好的，这不是世界上最大的开销，但是系统目录可能是一个明显的瓶颈。

网络上的工作量更大，因为当您可能只需要一个或两个字段时，您将撤回任意数量的字段。如果有人[else]加上了几十个额外的字段，所有这些字段都包含大块的文本，那么您的吞吐量突然就越过了底楼-并非显而易见的原因。如果您的“ where”子句不是特别好，并且您还要拉回很多行，这将变得更糟-这可能会导致大量数据在整个网络中流传到您的位置（即，速度将会很慢）。

您的应用程序需要做更多的工作，必须撤回并存储所有可能不需要的额外数据。

冒着改变列顺序的风险。好的，您不必为此担心（如果仅选择所需的列，则不会担心），但是，如果您一次获得所有这些列，并且[其他]决定重新安排表中的列顺序，经过精心制作的CSV导出文件，您突然下了帐，到了锅里，这又再次变得毫无意义。

顺便说一句，我在上面说了几次“其他人”。请记住，数据库本质上是多用户的。您可能无法控制自己认为可以做到的事情。

#5 楼

简短的答案是：这取决于他们使用哪个数据库。关系数据库经过优化，可通过快速，可靠和原子的方式提取所需的数据。在大型数据集和复杂查询上，它比SELECT *更快，更安全，并且等效于“代码”端的联接。键值存储可能未实现此类功能，或者可能不够成熟，无法在生产中使用。

话虽如此，您仍然可以使用SELECT *填充正在使用的任何数据结构并进行计算其余的在代码中，但是如果您想扩展，就会发现性能瓶颈。

最接近的比较是对数据进行排序：您可以使用quicksort或bubbleort，结果将是正确的。但是并不会被优化，当您引入并发性并且需要原子排序时肯定会出现问题。甚至对JOIN是什么都不了解。

#6 楼

IMO，关于显式还是隐式。当我编写代码时，我希望它能够工作是因为我使它起作用了，而不仅仅是因为所有部分都恰好在那里。如果查询所有记录并且您的代码有效，那么您将有继续前进的趋势。后来，如果发生了某些变化，而现在您的代码无法正常工作，则调试许多查询和函数以查找应该存在的值是唯一的麻烦，唯一的值引用是*。

另外，在N层方法中，最好还是将数据库架构中断隔离到数据层。如果您的数据层正在将*传递给业务逻辑，并且很可能在表示层上传递，则您的调试范围将成倍扩大。

#7 楼

因为如果表中有新的列，那么即使不需要它们，您也会得到所有这些列。使用varchars，这可能会变成大量需要从数据库传输的额外数据

一些数据库优化还可能将非固定长度记录提取到单独的文件中，以加快对固定长度部分的访问，使用select *不能达到目的

#8 楼

除了开销之外，您首先要避免的事情是，我想说，作为程序员，您并不依赖于数据库管理员定义的列顺序。即使需要全部，也可以选择每一列。

#9 楼

我看不出为什么不应该出于构建它的目的使用任何理由-从数据库中检索所有列。我看到三种情况：


在数据库中添加了一个列，您也希望在代码中使用它。
a）带有*的行将失败，并显示一条正确的消息。
b）带有*的行将有效，但不会执行您期望的那样，这很糟糕。
在数据库中添加了一个列，您不希望在代码中使用它。
a）带有*的将失败；这意味着*不再适用，因为它的语义意味着“全部检索”。
b）如果没有*将起作用。
删除列的方法
两种方法都会失败。

现在，最常见的情况是情况1（因为您使用*表示您很可能想要全部）。没有*的话，您的代码可以正常运行，但不能达到预期的效果，这会导致代码错误并失败，导致更糟糕的结果。

我没有考虑那些根据我认为容易出错的列索引检索列数据。根据列名检索它的逻辑要多得多。

#10 楼

这样想吧...如果您从一个只有几个小字符串或数字字段的表中查询所有列，则总共有100k数据。不好的做法，但它会执行。现在，添加一个包含例如图像或10mb word文档的字段。现在，您快速执行的查询立即开始神秘地开始表现不佳，仅是因为将字段添加到了表中……您可能不需要该庞大的数据元素，但是因为您已经完成了Select * from Table，反正还是可以得到它。