围绕MS SQL上的SELECT*的性能/代码可维护性问题在今天与现代ORM是否仍然相关？

小结：由于性能和可维护性方面的考虑，我看到了很多反对在MS SQL中使用SELECT*的建议。然而，这些职位很多都很老-5至10年！从这些帖子中可以看出，性能问题实际上可能很小，即使是在他们的时间里，至于可维护性问题（“哦，不，如果有人更改了列，而您是通过索引数组来获取数据的！您的选择*会给您带来麻烦！”），现代编码实践和ORM（如短小精悍）似乎消除了这些顾虑，至少以我的经验来看是这样的

那么：对于SELECT*是否存在今天仍然相关的问题

---

更大的背景：我开始在一个有很多旧MS代码（ASP脚本等）的地方工作，我一直在帮助实现很多现代化，但是：我的大部分SQL经验实际上来自MySQL和PHP框架以及ORM——这是我第一次使用MS SQL——我知道两者之间存在细微的区别。另外：我的同事比我大一点，并且有一些担心——对我来说——似乎“老了”(“可为空的字段太慢了！避免使用它们！”）但是，在这个特定的字段中，它们肯定比我有更多的经验

出于这个原因，我还想问：现在使用现代ORM选择*是否安全和明智，是否有最近的在线资源表明这一点

---

谢谢！：）

在这个答案中，我不涉及可维护性，只涉及性能部分

在这种情况下，性能与ORMs关系不大

对于服务器来说，它正在运行的查询是如何生成的并不重要，不管是手工编写的还是由ORM生成的

选择不需要的列仍然是个坏主意

从性能的角度来看，查询是否为：

SELECT * FROM Table

或者所有列都明确列出，如：

SELECT Col1, Col2, Col3 FROM Table

如果只需要

Col1

，那么请确保只选择

Col1

。无论是通过手动编写查询还是通过微调ORM来实现，这都无关紧要

---

为什么选择不必要的列是个坏主意：

• 要从磁盘读取的额外字节

• 要通过网络传输的额外字节

• 要在客户端上解析的额外字节

• 但是，最重要的原因是，Optimizer可能无法生成一个好的计划。例如，如果有一个包含所有请求列的覆盖索引，服务器通常只读取该索引，但如果您请求更多列，它将进行额外的查找或使用其他索引，或者只扫描整个选项卡最终的影响可以从几秒钟到几小时的运行时间不等。数据库越大、越复杂，您越有可能看到明显的差异

网站上有一篇关于这个主题的详细文章

现在我们已经对为什么选择 一切都不利于性能，您可能会问为什么它被列为 神话？因为很多人认为明星是坏事。 此外，他们认为他们没有犯下这种罪行，因为他们的 ORM仍然按名称列出所有列。事实上，罪行是选择 所有列都没有考虑它，而且大多数列都很容易提交 这是代表他们的用户犯罪

---

我将在这里为您的评论添加答案

我不知道如何接近一个没有给我选择字段选项的ORM。我个人会尽量不使用它。一般来说，ORM添加了一个非常糟糕的抽象层

这意味着您仍然需要知道如何编写SQL代码以及DBMS如何运行这些代码，但还需要知道ORM是如何工作和生成这些代码的。如果您选择不知道ORM背后发生了什么，那么当您的系统发展到不重要的程度时，您将遇到无法解释的性能问题

你说在你以前的工作中，你使用ORM来处理一个大系统，没有任何问题。这对你来说很有效。很好。不过，我有一种感觉，你的数据库不是很大（你有几十亿行吗？），而且系统的性质允许在缓存后面隐藏性能问题（这并不总是可能）。系统可能永远不会超出硬件容量。如果您的数据适合缓存，通常在任何情况下都会相当快。只有当您超过某个阈值时，它才开始起作用。在这之后，突然一切都变慢，很难修复

对于业务/项目经理来说，忽视可能永远不会发生的未来问题是很常见的。业务总是有更紧迫的问题要处理。如果业务/系统在性能成为问题时增长足够大，那么它要么已经积累了足够的资源来重构整个系统，要么将继续工作效率越来越低，或者如果这个系统恰好对业务非常关键，那么就失败，给另一家公司一个超越它的机会

回答您的问题“是否在性能备受关注的应用程序中使用ORM？”“。当然可以使用ORM。但是，您可能会发现它比不使用它更困难。考虑到ORM和性能，您必须手动检查ORM生成的SQL代码，并从性能角度确保它是一个好代码。因此，您仍然需要非常了解SQL和您使用的特定DBMS，并且需要非常了解您的ORM，以确保它生成您想要的代码。为什么不直接编写你想要的代码呢

你可能认为ORM与原始SQL的这种情况类似于一个高度优化的C++编译器，而不是手工编写汇编程序中的代码。嗯，是n

Select colA, colB
From table1 t1
Where Exists (Select * From Table2  Where column = t1.colA)