我听说SELECT *在编写SQL命令时使用通常是不好的做法,因为它对SELECT您特别需要的列更有效.
如果我需要SELECT表中的每一列,我应该使用
SELECT * FROM TABLE
要么
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下,效率真的重要吗？SELECT *如果你确实需要所有的数据,我认为内部会更优化,但我说的是没有真正了解数据库.
我很想知道在这种情况下最佳做法是什么.
更新:我可能应该指定我真正想要做的唯一情况SELECT *是当我从一个表中选择数据时我知道所有列总是需要被检索,即使添加了新列.
鉴于我所看到的反应,这仍然是一个坏主意,SELECT *永远不应该用于更多技术原因,我曾经考虑过.
如果我只需要2/3列并且我查询SELECT *而不是在select查询中提供这些列,那么是否有关于更多/更少I/O或内存的性能下降？
如果我在不需要的情况下选择*,则可能存在网络开销.
但是在select操作中,数据库引擎是否始终从磁盘中提取原子元组,还是仅提取select操作中请求的那些列？
如果它总是拉取元组,那么I/O开销是相同的.
同时,如果它提取元组,则可能存在从元组中剥离所请求列的内存消耗.
因此,如果是这种情况,选择someColumn将比select*具有更多的内存开销
我一直向我的开发者讲道,这SELECT *是邪恶的,应该像瘟疫一样避免.
有什么理由可以说是合理的吗？
我不是在谈论COUNT(*)- 大多数优化者都可以解决这个问题.
编辑
我在谈论生产代码.
我看到这个不好的做法的一个很好的例子是select *在存储过程中使用的传统asp应用程序,用于ADO循环返回的记录,但是通过索引得到列.您可以想象在字段列表末尾之外的某处添加新字段时发生的情况.