blocks|key|965248|text|你需要考虑的不仅仅是额外的数据方面。选择所有列将否定覆盖索引的用处，因为需要对聚集索引(或表)进行书签查找。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|965249|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's not just the extra data aspect that you need to consider. Selecting all columns will negate the usefulness of covering indexes, since a bookmark lookup into the clustered index (or table) will be required.

blocks|key|194905|text|这取决于选择了多少行，以及这些额外的字段消耗了多少内存。例如，如果存在多个文本/blobs字段，或者选择了许多行，则运行速度会慢得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|194906|稍后添加字段有何风险？修改查询以适应不断变化的需求是开发过程中的自然部分。|194907|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It depends on how many rows are selected, and how much memory do those extra fields consume. It can run much slower if several text/blobs fields are present for example, or many rows are selected.

How is adding fields later a risk? modifying queries to fit changing requirements is a natural part of the development process.

blocks|key|194969|text|据我所知，在select语句中显式命名列的唯一好处是，如果代码正在使用的列被重命名，则select语句将在代码之前失败。更好的是，如果select语句在proc中，proc和DB脚本将无法编译。如果您正在使用诸如VS+DB版之类的工具来编译/验证DB脚本，这将非常方便。否则，性能差异将可以忽略不计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|194970|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The only benefit I know of explicitly naming your columns in your select statement is that if a column your code is using gets renamed your select statement will fail before your code. Even better if your select statement is within a proc, your proc and the DB script would not compile. This is very handy if you are using tools like VS DB edition to compile/verify DB scripts.
Otherwise the performance difference would be negligible.

blocks|key|965212|text|与SQL请求本身的大量开销相比，检索到的字段数量对性能的影响是二阶的--离开进程，通过网络传输到另一台主机，并可能传输到该主机上的磁盘，所需的周期比存储几个额外字节的数据多得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|965213|显然，如果额外的字段包含一个兆字节的blob，则等式是不正确的。但我的经验是，事务开销与检索到的实际数据相同或更大。我依稀记得很多年前，一个“空的”NOP+TNS请求大约是100个字节。|965214|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The number of fields retrieved is a second order effect on performance relative to the large overhead of the SQL request itself -- going out of process, across the network to another host, and possibly to disk on that host takes many more cycles than shoveling a few extra bytes of data.

Obviously if the extra fields include a megabyte blob the equation is skewed. But my experience is that the transaction overhead is of the same order, or larger, than the actual data retreived. I remember vaguely from many years ago than an "empty" NOP TNS request is about 100 bytes on the wire.

blocks|key|965230|text|如果SQL服务器与您正在查询的计算机不同，那么选择额外的列将通过网络传输更多的数据(这可能是一个瓶颈)，不要忘记它必须从磁盘读取更多的数据，分配更多的内存来保存结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|965231|没有一件事情本身会导致问题，但将它们加在一起就会导致性能问题。当您有大量查询或数据时，每一点都会有所帮助。|965232|我猜风险在于，您必须稍后将字段添加到查询中，这可能意味着更改代码，但通常您必须添加更多代码来处理额外的字段。|965233|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If the SQL server is not the same machine from which you're querying, then selecting the extra columns transfers more data over the network (which can be a bottleneck), not forgetting that it has to read more data from the disk, allocate more memory to hold the results.

There's not one thing that would cause a problem by itself, but add things up and they all together cause performance issues. Every little bit helps when you have lots of either queries or data.

The risk I guess would be that you have to add the fields to the query later which possibly means changing code, but then you generally have to add more code to handle extra fields anyway.

How much of a performance benefit is there by selecting only required field in query instead of querying the entire row? For example, if I have a row of 10 fields but only need 5 fields in the display, is it worth querying only those 5? what is the performance benefit with this limitation vs the risk of having to go back and add fields in the sql query later if needed?

Performance benefit when SQL query is limited vs calling entire row?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如果只选择查询中的必填字段而不是查询整个行，性能会有多大的好处？例如，如果我有一行10个字段，但在显示中只需要5个字段，那么是否值得只查询这5个字段？与需要时必须返回并在sql查询中添加字段的风险相比，这种限制的性能优势是什么？

问与调用整行相比，SQL查询受限时的性能优势是什么？
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问与调用整行相比，SQL查询受限时的性能优势是什么？EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问与调用整行相比，SQL查询受限时的性能优势是什么？
EN