有人可以说是一个更好的做法吗?对于选择查询,我应该返回我需要的全部或ID吗?
效率?可扩展性?等
感谢
环境:SQL Server 2008,VS2008(VB)
答案 0 :(得分:9)
始终明确枚举您的列。在任何生产代码中都没有select *
。
即使看似有意义的情况也会产生意想不到的后果。例如,当您有一个应该镜像表格布局的视图时,您可能会想到select *
,但如果您修改基础表而不重新生成视图,则会发生奇怪的事情。
远离select *
,除非您输入查询并执行该查询。
答案 1 :(得分:3)
有人可以说是一个更好的做法吗?对于选择查询,我应该返回我需要的全部或ID吗?
为列命名。
这不仅是一种最佳做法,而且可以获得更高的性能。
想象一下两个问题:
SELECT *
FROM mytable
WHERE column1 = @somevalue
和
SELECT id, column1
FROM mytable
WHERE column1 = @somevalue
id
是一个群集主键,column1
上有一个索引。
我假设您的客户端代码正确处理可变数量的列,i。即表格布局更改不会破坏代码。这是一个非常强大的假设,但让我们做到。
现在,如果mytable
仅由id
和column1
组成,则查询相同。
如果您向column2
添加mytable
会怎样?
第二个查询(带有命名列)仍然使用索引(因为in包含查询所需的所有内容),但第一个查询也需要选择column2
(SQL Server
不知道你要去忽略它。)
这会在计划中添加Clustered Table Seek
,您的查询效果会变差。
答案 2 :(得分:3)
使用表中的select col1,col2,col3而不是select * from table1。如本文和此处所述,这有许多优点。
另见: http://weblogs.sqlteam.com/jeffs/jeffs/archive/2007/07/26/60271.aspx
Is there a difference between Select * and Select [list each col]
答案 3 :(得分:2)
永远不要听任何人告诉你总是在SQL中做某事 - 或者,总是要警惕任何人告诉你永远不要在SQL中做某事:)
在以下示例中,SELECT *
不会造成任何伤害,并且可以说在可读性和代码维护方面具有优势(DRY以及所有这些):
示例1
如果已在“内部”范围中指定了属性的commalist:
SELECT *
FROM (
SELECT col1, col2, col3, col4, col5
FROM T1
) AS DT1;
示例2
在CTE中使用表值构造函数时,会强制一个(例如在SQL Server中)将VALUES
子句包装在表表达式(SELECT..FROM
)中,例如
WITH T1
AS
(
SELECT *
FROM (
VALUES (1, 1, 1, 2, 1),
(1, 1, 2, 1, 1),
(1, 2, 1, 1, 1)
) AS T (col1, col2, col3, col4, col5)
)
SELECT ...
好的,所以这最后一个有点像一个稻草人,但考虑到每个机会使用商家都会导致错误并使调试变得困难:
WITH T2 (author_name, book_title, ISBN)
AS
(
SELECT book_title, ISBN, author_name
FROM (
VALUES ('9780321189561', 'C. J. Date', 'An Introduction to Database Systems')
) AS T (ISBN, author_name, book_title)
)
SELECT *
FROM T2;
答案 4 :(得分:1)
始终使用命名列!
一个很好的例子,说明为什么不好:"select * from table" vs "select colA,colB,etc from table" interesting behaviour in SqlServer2005
答案 5 :(得分:1)
在大多数情况下,您应该指定列,这最适合将来的更改和维护。它还可以减少数据量,提高性能。
答案 6 :(得分:1)
优先明确命名SELECT * FROM our_table
列的原因是
答案 7 :(得分:0)
除非您从未引用客户端代码中的任何列名称,否则应使用命名列。
答案 8 :(得分:0)
我不会告诉你“永远不会”或“总是”使用其中一个。从那开始的建议不是字面意思。
如果您正在使用小型数据集,请不要坚持使用愚蠢的“优化”,例如将*
替换为字段列表,尤其是如果您要指定所有的字段。
具有可读且易于维护的SQL代码通常比一些节省的CPU周期或几千字节的内存使用量或网络流量更有价值。