我听说很多都不使用*(星号),而是命名我需要的字段。是因为性能问题还是安全原因?有人可以为此说一些好的论点吗?
所以不是
SELECT * FROM users WHERE name='John';
但是
SELECT name FROM users WHERE name='John';
答案 0 :(得分:6)
不在生产查询中使用星号的最大原因是将非SQL代码与数据库架构中的更改隔离开来,或者使这些更改更难以被忽视。
例如,如果您的代码使用星号查询,第一列中需要name
而第二列中需要address
,那么如果架构更改为在第二列前面添加第三列,那么您已经在阅读,您的代码将获得新列而不是名称,并且还将名称替换为地址。最糟糕的是,它可以在没有崩溃的情况下完成所有操作:用户只会看到垃圾数据。
相比之下,具有显式命名列的查询将在架构更改时获取正确的列,或者在已删除或重命名所需列时中断。这将立即指出问题的根源,使您可以轻松调查并解决问题。
答案 1 :(得分:1)
这是表演的事情。当您SELECT *
时,您正在检索表格中的每个字段。如果您SELECT name
,则只选择名称字段。在仅选择所需字段时,可以从数据库服务器向应用程序传输的数据少得多。
答案 2 :(得分:0)
SELECT *
表示从表中选择SELECT。它将选择所有列。
但是如果您指定只选择查询中的某些列
SELECT name --->这将只选择名称列
答案 3 :(得分:0)
因为如果选择*,那么您将获得该查询的所有列,这将转换为数据集的更高内存使用量,而不仅仅是获取所需的列。
答案 4 :(得分:-5)
对我来说,这更像是理智,可读性和常识的问题。
当您只需要name
时 - 为什么不明确写出来?
它将使您的查询为读者提供更多信息。
但是当我看到可怜的开发人员明确地写出数十个字段名称只是为了追随这个“性能”废话 - 它让我受伤。
评论中的一个重要说明:
编写不依赖于查询中的字段顺序或数量的代码确实很重要
所以,只需使用*
,获取关联数组,你的代码永远不会因为如此愚蠢的原因而破解。
对于我的拙劣测试,我有一些不同。 0,0002分秒 好吧,如果这样的差异是你的应用程序的某个瓶颈 - 去显式写字段(尽管解析器需要更多时间来解析你的查询,呵呵:) 但是,在我的领域中,性能问题始于至少0,001的差异。所以,我不会打扰。