Can select * usage ever be justified? 能否合理使用select *？
可以选择*的使用是否合理？
在许多场景中，选择*是最佳解决方案。在管理工作室中运行即席查询，只是为了了解正在使用的数据。查询表时，如果是第一次使用新模式，还不知道列名，那么可以选择*。构建一次性的快速工具来进行一次性迁移或数据导出。
我同意，在“正式”开发中，应该避免使用*，但在许多情况下，“正式”开发并不一定是解决业务问题的最佳方案。规则和最佳实践很好，只要你知道什么时候打破它们。 🙂
“查询表时，如果是第一次使用新模式，还不知道列名” - 例如，在实现从数据库模式构建对象的ORM时。
“规则和最佳实践很好，只要你知道什么时候打破它们” +1，我经常被告知“这样就够了”。
不幸的是，根据我的经验，人们使用select *并不是因为上述原因，而是因为懒惰。
在上述内容中，提到了在审计触发器中使用*的情况，以及在派生表和列表表达式中使用它的情况。其中，使用*可以确保如果基表中添加了额外的列，就会引发错误，以确保在审计触发器和/或审计表结构中不会忘记处理这个问题。而且在SQL Server中，优化器可以识别出只有列a,b,c会被需要，因此在内部表达式中使用*不会导致不必要的开销。
但是在视图中使用SELECT *就有问题了，因为视图中存储了列的元数据，当底层表发生变化时，这些元数据不会自动更新，使用*可能会导致混乱和错误的结果，除非运行sp_refreshview来更新这些元数据。
因此，可以看出SELECT *的使用在某些情况下是有合理性的，但在其他情况下可能会导致问题。解决这个问题的方法是在内部表达式中明确列出所需的列，而不是使用*。这样可以避免不必要的开销和潜在的错误。