【问题标题】:Is it faster to apply multiple indexes to a table one after the other or with multiple individual queries将多个索引一个接一个或多个单独的查询应用于一个表是否更快
【发布时间】:2019-10-10 07:56:53
【问题描述】:

这与多列索引(复合)与单列索引无关。这比功能更重要的是性能。

我有一个场景需要对同一个表应用多个索引。现在我让它检查它们是否存在,然后一个接一个地应用它们。

我的问题是,从开始到结束的总时间需要几个小时才能全部应用。我想尽可能减少总时间(减少应用它们的时间窗口)

一个接一个

index1 => index2 = index3 =>...indexN

全部同时应用于一个表

index1 
index2 
index3 
...
indexN

某些表的索引计数为 10+,有多个表,这将应用于多个数据库(几百个)我对 SAN 魔术类型的数据存储或 SQL Server 没有任何控制权事物。我有 16 个处理器和一个企业服务器,但所有数据库中所有表的总数并不小。在近 3000 个表中考虑多个 GB 行表计数和多个 TB 存储大小。这些都是聚集索引,而且大多数是复合索引

【问题讨论】:

  • 更新您的 sql server 版本并移至列存储索引功能
  • @ZaynulAbadinTuhin 不是一个选项,这是另一天的任务,还有很多工作要做
  • 您想每天晚上重建这些索引还是一次性操作?
  • @M.Kanarkowski 这是一次性的,但它的工作量很大。

标签: sql performance sql-server-2008 indexing


【解决方案1】:

虽然似乎不存在实现此目的的简单方法,但在对一个相当大的表进行测试时发现,该表应用了 10 个具有单独查询和配置的新索引并发处理(所有这些都始于几乎相同的时间,分别)确实比单个脚本快,其中索引以串行方式应用了显着优势。如果 SQL Server 有足够的资源来处理影响,这似乎也没有可以检测到的负面影响。

只是在这里更新范围和规模,而不是太具体:

  • 针对多个表进行了测试,规模从微不足道(360 万行)到更大
  • 针对具有 30 多个索引(200M-500M 行)的集合进行测试
  • 针对 1.6B 到 1.9B 行的表进行测试
  • 索引计数在 3-30+ 之间变化,具体取决于表格
  • tempdb 大小为 1TB
  • 2800 多个表中的总范围从 0 行到近 2B 行
  • 服务器基本上已加载到它可以处理的最大点并使用自动化保持在那里

实际结果示例与 9 到 14 小时的完成时间一致,减少到不到 43 分钟,所有索引同时应用于单个表和多个表索引在一个数据库以及 200 多个单独的数据库中.多 TB 级别的数据大小。

我使用 Powershell 提交了添加的索引,其中数百个同时在不同的表上运行,其中包括多个表上的 30 多个。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-09-01
    • 1970-01-01
    • 2011-05-09
    • 1970-01-01
    • 2018-03-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多