【问题标题】:Is it faster to only query specific columns?只查询特定列会更快吗?
【发布时间】:2015-03-31 20:03:17
【问题描述】:

我听说手动选择列(“col1、col2、col3 等”)比使用“*”查询所有列更快。

但是,如果我什至不想查询表的所有列怎么办?例如,只查询“col1, col2”而不是“col1, col2, col3, col4”会更快吗?

据我了解,SQL 无论如何都必须搜索所有列,并且只有返回结果会发生变化。我想知道仅选择正确的列是否可以提高性能。

(无论如何我都在这样做,但我的一个应用程序的后端 API 经常返回而不是所有列,所以我正在考虑让用户手动选择他想要的列)

【问题讨论】:

    标签: mysql sql performance select


    【解决方案1】:

    一般来说,减少select 中的列数是一个小优化。这意味着从数据库服务器返回到调用服务器的应用程序的数据更少。更少的数据通常更快。

    在大多数情况下,这只是很小的改进。在某些情况下,改进可能更重要:

    • 如果覆盖索引可用于查询,则索引满足查询而无需访问数据页。
    • 如果某些字段很长,那么记录会占据多页。
    • 如果要检索的数据量仅占每条记录中总数据的一小部分(认为

    单独列出列是个好主意,因为它可以保护代码免受底层架构的更改。例如,如果更改了列的名称,则显式列出列的查询将因易于理解的错误而中断。这比运行并产生错误结果的查询要好。

    【讨论】:

    • 很好的详细答案。我的查询检索大型二进制文件(图像),因此当我不需要图像时列出其他列会是一个更好的主意,是吗?
    【解决方案2】:

    你应该尽量不要使用select *

    • 将数据移动到消费者的效率低下。当您选择 * 时,您从数据库中检索的列通常比您的应用程序真正需要运行的列多。这会导致更多数据从数据库服务器移动到客户端,从而减慢访问速度并增加机器上的负载,并花费更多时间通过网络传输。当有人向基础表中添加新列时尤其如此,而这些新列在原始消费者编写其数据访问代码时并不存在且不需要。

    • 索引问题。考虑一个场景,您希望将查询调优到高性能水平。如果您要使用 *,并且它返回的列比您实际需要的多,那么服务器通常必须执行比其他方式更昂贵的方法来检索您的数据。例如,您将无法创建仅覆盖 SELECT 列表中的列的索引,即使您这样做了(包括所有列 [shudder]),下一个出现的人并向基础表添加一列会导致优化器忽略您优化的覆盖索引,并且您可能会发现查询的性能会因没有显而易见的原因而大幅下降。

    • 绑定问题。 当您选择 * 时,可以从两个不同的表中检索两个同名的列。这通常会使您的数据使用者崩溃。想象一个连接两个表的查询,这两个表都包含一个名为“ID”的列。消费者如何知道哪个是哪个?当底层表结构发生变化时,SELECT * 也会混淆视图(至少在某些版本的 SQL Server 中)——the view is not rebuilt, and the data which comes back can be nonsense。最糟糕的是,您可以小心地为您的列命名,但是下一个出现的人可能无法知道他必须担心添加一个列会与您已经开发的冲突名字。

    我从this 得到这个答案。

    【讨论】:

      【解决方案3】:

      我相信这里已经涵盖了这个主题:

      select * vs select column

      我相信它也涵盖了您的担忧。请看一下。

      【讨论】:

        【解决方案4】:

        所有列标签和值都占用一些空间。将它们发送给请求的发出者而不是列的子集意味着发送更多数据。数据越多发送越慢。

        如果您有列,例如 idusernamepasswordemailbiourl

        你只想得到usernamepassword,那么

        select username, password ...
        

        select * ...
        

        因为idemailbiourl 也为后者发送,这使得响应更大。但是select * 的主要问题是不同的。如果由于某种原因列的顺序发生了变化,则可能是不一致的根源。此外,它可能会检索您不想检索的数据。最好有一个包含您实际要检索的列的白名单。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2015-06-07
          • 1970-01-01
          • 2023-03-27
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2016-04-23
          相关资源
          最近更新 更多