SQL 通配符 : performance overhead?

标签 sql performance wildcard sql-execution-plan overhead

我用 Google 搜索了这个问题,但似乎找不到一致的意见,也找不到许多基于可靠数据的意见。我只是想知道在 SQL SELECT 语句中使用通配符是否会比单独调用每个项目产生额外的开销。我在几个不同的测试查询中比较了两者的执行计划,似乎估计值总是一样的。是否有可能在其他地方产生了一些开销,或者它们是否真正以相同的方式处理?

我具体指的是什么:

SELECT *

对比

SELECT item1, item2, etc.

最佳答案

SELECT * FROM...

SELECT every, column, list, ... FROM...

将执行相同的操作,因为两者都是未优化的扫描

区别在于:

  • 要解析的 sys.columns 中的额外查找 *
  • 契约(Contract)/签名在表架构更改时更改
  • 无法创建覆盖索引。事实上,根本没有调整选项,真的
  • 如果非架构绑定(bind)则必须刷新所需的 View
  • 不能使用 * 索引或架构绑定(bind) View
  • ...和其他东西

关于同一主题的其他 SO 问题...

关于SQL 通配符 : performance overhead?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11485741/

相关文章:

sql - PIVOT 运算符中指定的列名 "FirstName"与 PIVOT 参数中的现有列名冲突

用于检索同一表中包含的不同数据系列的 SQL 查询

performance - 有关使Hive在Hadoop上更快运行的任何技巧?

c# - 扩展方法 : Performance issue when using too much?

xpath - 使用通配符缩短 XPATH

mysql - 需要一个 MySQL 查询来显示有 child 的 parent 以及没有 child 的 parent

mysql - 优化超过 200,000 条记录的查询

mysql - WHERE 的通配符?

jquery - 删除下拉选项性能问题

java - Windows(7?)上 Java 7 命令行的损坏的通配符扩展