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

Question

总结:看了很多建议反对 出于性能和可维护性的考虑，在 MS SQL 中使用 SELECT *。然而，这些帖子中的许多都非常古老——5 到 10 年!它似乎 ，从许多这些帖子中，性能问题实际上可能很小，即使在他们的时代，以及可维护性问题(“哦，不，如果有人更改了列，并且您通过索引数组来获取数据呢？ !您的 SELECT * 会给您带来麻烦!”)，现代编码实践和 ORM(例如 Dapper)似乎 - 至少以我的经验 - 消除这种担忧。

所以: SELECT * 是否存在今天仍然相关的问题？

更大的背景:我已经开始在一个有很多旧 MS 代码(ASP 脚本等)的地方工作，并且我一直在帮助对其进行现代化改造，但是:我的大部分 SQL 经验实际上来自MySQL 和 PHP 框架和 ORM - 这是我第一次使用 MS SQL - 我知道两者之间存在细微的差异。另外:我的同事比我大一点，并且有些担心 - 对我来说 - 看起来“老”。 (“可空字段很慢!避免使用它们!”)但同样:在这个特定领域，他们肯定比我有更多的经验。

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

谢谢! :)

Answer 1

这个问题已经有一段时间了，似乎没有人能够找到，Ben 在寻找什么......

我认为是这样，因为答案是“视情况而定”。

只有 不是 的答案。

例子

正如我之前指出的，如果一个数据库不是你的，而且它可能经常被修改，你就不能保证性能，因为使用 select * 每行的数据量可能会爆炸

如果您使用 ITS OWN 数据库编写应用程序，则没有人更改您的数据库(希望如此)并且您需要您的列，那么 select *

有什么问题

如果您构建某种延迟加载，“主要属性”会立即加载，而其他属性会在稍后加载(同一实体)，则不能使用 select *，因为您会得到所有

如果你使用 select * 其他开发人员每次都会想“他有没有考虑过 select *”，因为他们会尝试优化。所以你应该添加足够的评论...

如果你构建 3-Tier-Application 在中间层构建大型缓存并且性能是由缓存完成的主题，则可以使用 select *

扩展 3Tier:如果你有很多并发用户和/或非常大的数据，你应该考虑每一个字节，因为你必须在浪费每个字节的情况下扩展你的中间层(正如有人在之前的评论中指出的那样)

如果你为 3 个用户和几千条记录构建一个小应用程序，预算可能没有时间优化速度/db-layout/东西

与您的 dba 交谈...他会建议您必须更改/优化/精简/...

我可以继续。没有一个答案。它只是取决于许多因素。