Questions tagged «index-maintenance»

1
全文索引维护准则
维护全文索引应考虑哪些准则？ 我应该重新构建或重新组织全文目录（请参阅BOL）吗？什么是合理的维护节奏？可以使用什么启发式方法（类似于10％和30％的碎片阈值）来确定何时需要维护？ （下面的所有内容只是有关此问题的详尽信息，并显示了我到目前为止的想法。） 额外信息：我的初步研究 有关b树索引维护的资源很多（例如，该问题，Ola Hallengren的脚本以及其他站点上有关该主题的大量博客文章）。但是，我发现这些资源都没有提供用于维护全文索引的建议或脚本。 有微软的文档是提到整理基表的B树索引，然后对全文目录执行REORGANIZE可以提高性能，但它并没有任何更具体的建议碰。 我也发现了这个问题，但它主要集中在变更跟踪（如何将对基础表的数据更新传播到全文索引中），而不是可以最大程度地提高索引效率的定期维护类型。 额外信息：基本性能测试 此SQL Fiddle包含可用于创建具有AUTO更改跟踪的全文本索引的代码，并在修改表中的数据时检查索引的大小和查询性能。当我在生产数据的副本（而不是小提琴中的人造数据）上运行脚本的逻辑时，以下是在每个数据修改步骤之后看到的结果的摘要： 即使此脚本中的update语句设计得相当不错，但这些数据似乎表明定期维护有很多好处。 额外信息：初步构想 我正在考虑创建每晚或每周的任务。看来此任务可以执行REBUILD或REORGANIZE。 因为全文索引可能非常大（数以千万计的行），所以我希望能够检测目录中的索引何时足够零散，以确保需要进行REBUILD / REORGANIZE。对于哪种启发式方法可能有意义，我还不清楚。
6
如何防止索引重组期间事务日志变满？
我们有多台机器，我们已将事务日志的大小预分配为50gb。我尝试重新整理的表格大小为55-60 GB，但会不断增加。我要重组的主要原因是要回收空间和任何性能收益，因为这是额外的好处。 该表的碎片级别为30-35％。在其中一些计算机上，我收到“事务日志已满”错误，并且重组失败。事务日志大小达到48gb。有什么好方法可以解决这个问题？我们没有打开自动增量功能，我不愿意这样做。 我可以将日志大小增加到一个更大的值，但是随着将来表大小的增加，该值可能会不够。如果我要平等地增加日志大小，它也会破坏进行重组以回收空间的目的。关于如何有效应对这一问题的任何想法？由于无法接受数据丢失，因此无法使用批量模式。
3
IndexOptimize之后查询和更新非常慢
数据库SQL Server 2017 Enterprise CU16 14.0.3076.1 最近，我们尝试从默认的“索引重建”维护作业切换到Ola Hallengren IndexOptimize。默认的索引重建作业已经运行了几个月，没有任何问题，并且查询和更新在可接受的执行时间内正常工作。在IndexOptimize数据库上运行后： EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y' 性能极度下降。使用100ms之前的一条更新语句IndexOptimize之后（使用相同的计划）花费了78.000ms，并且查询的执行情况也差了几个数量级。 由于这仍然是一个测试数据库（我们正在从Oracle迁移生产系统），因此我们恢复为备份并禁用IndexOptimize，一切恢复正常。 但是，我们想了解与可能导致这种极端性能下降IndexOptimize的“正常” Index Rebuild行为有何不同，以确保一旦投入生产就可以避免这种情况。关于寻找什么的任何建议将不胜感激。 update语句执行速度慢时的执行计划。即 在IndexOptimize 实际执行计划之后（尽快推出） 我还没发现差异。 快速计划相同的查询 实际执行计划
2
MySQL索引维护
我做了很多有关如何在MySQL中维护索引以防止碎片并以某种方式优化查询执行的研究。 我熟悉该公式，该公式可计算表的最大可用空间与数据和索引使用的空间之间的比率。 但是我的主要问题仍然没有答案。也许这是由于我熟悉SQL Server中的索引维护，并且我倾向于认为在MySQL中它应该在某种程度上相似。 在SQL Server中，您可以具有多个索引，并且每个索引可以具有不同级别的碎片。然后，您可以选择一个并在该特定索引中执行“ REORGANIZE”或“ REBUILD”操作，而不会影响其余的索引。 据我所知，没有这种“表碎片”，并且SQL Server没有提供任何工具来修复“表碎片”。它确实提供了检查索引碎片的工具（可以理解为索引碎片使用的工具，例如索引所使用的页数与该页的填充度和连续性之间的比率），以及内部和外部碎片。 至少对于我来说，所有这些都是很容易理解的。 现在，当轮到在MySQL中维护索引时，如上所述，仅存在“表碎片”的概念。 MySQL中的一个表可以有多个索引，但是当我用那个著名的公式检查“碎片率”时，我看不到每个索引的碎片，而是整个表。 当我想优化MySQL中的索引时，我不选择要操作的特定索引（如SQL Server中一样）。相反，我在整个表中执行“ OPTIMIZE”操作，这大概会影响所有索引。 当在MySQL中优化表时，数据+索引使用的空间与整个空间之间的比率将减小，这表明硬盘驱动器中进行了某种物理重组，这意味着物理空间的减少。但是，索引碎片不仅与物理空间有关，而且与由于插入和更新而随时间变化的树的结构有关。 最后，我在InnoDB / MySQL中得到了一个表。该表具有300万条记录，105列和55个索引。它是1.5GB（不包括索引），后者是2.1GB。 每天都要对该表进行数千次点击以进行更新和插入（实际上，我们并未删除记录）。 该表已经创建多年，我可以肯定没有人维护索引。 我原本希望在那里找到一个巨大的碎片，但是当我按照规定执行碎片计算时 free_space / (data_length + index_length) 事实证明，我的碎片只有0.2％。恕我直言，这是非常不现实的。 因此，主要问题是： 如何检查MySQL中特定索引的碎片，而不是整个表格 OPTIMIZE TABLE是否像SQL Server一样实际修复了索引的内部/外部碎片？ 当我在MySQL中优化表时，它实际上会重建表上的所有索引吗？ 认为减少索引的物理空间（而不重建树本身）实际上转化为更好的性能是否现实？
6
索引重建时间是否取决于碎片级别？
重建索引所需的时间是否取决于碎片级别？ 如果重建相同索引的40％碎片索引需要1分钟，重建80％碎片索引大约需要2分钟吗？ 我要求的是执行所需操作所需的RUNTIME（例如，以秒为单位），而不是关于在特定情况下需要执行哪些操作。我知道应该进行索引重组或重建/统计更新时的基本最佳实践。 这个问题不问关于REORG以及REORG和REBUILD之间的区别。 背景：由于设置了不同的索引维护作业（每个晚上，周末工作量较大……），我想知道是否应该对低中级零散的索引更好地执行每日“轻度”离线索引维护作业，以保持关闭时间很小-甚至没有关系，在80％碎片索引上进行重建可能需要与在40％碎片索引上进行相同操作的时间相同。 我遵循了建议，并试图找出自己正在发生的事情。我的实验设置：在没有其他操作且未被任何人或其他任何人使用的测试服务器上，我在uniqueidentifier主键列上创建了带有聚簇索引的表，其中包含一些其他列和不同的数据类型[2数字，9日期时间和2 varchar（1000）]并简单地添加行。对于提出的测试，我增加了约305,000行。 然后，我使用了一条更新命令，并随机更新了对整数值进行过滤的行范围，并使用变化的字符串值更改了VarChar列之一以创建碎片。之后，我检查中的当前avg_fragmentation_in_percent水平sys.dm_db_index_physical_stats。每当为基准创建“新”碎片时，都会将此值（包括该physical_page_count值）添加到下图所组成的录音中。 然后我跑了出来：Alter index ... Rebuild with (online=on); 并CPU time通过STATISTICS TIME ON录音来抓取。 我的期望：我期望至少看到一种线性曲线的指示，该线性曲线显示碎片水平和cpu时间之间的依赖关系。 不是这种情况。我不确定此程序是否真的适合取得良好效果。也许行数/页面数太少？ 但是结果表明，我最初的问题的答案肯定是“ 否”。看起来SQL Server重建索引所需的cpu时间既不依赖于碎片级别，也不依赖于基础索引的页数。 第一张图表显示了与先前的碎片级别相比，重建索引所需的cpu时间。如您所见，平均线是相对恒定的，碎片与所需的cpu时间之间根本没有关系。 为了尊重更新后索引页数变化可能会影响重建的时间的影响，我计算了FRAGMENTATION LEVEL * PAGES COUNT并在第二张图表中使用了该值，该图表显示了所需cpu时间的关系以及碎片和页数。 如您所见，即使页面数有所变化，这也并不表示重建所需的时间受碎片影响。 在做出这些陈述之后，我想我的程序一定是错误的，因为重建一个庞大且高度分散的索引所需的cpu时间可能仅受行数的影响-我并不真正相信这一理论。 因此，因为我确实非常想立即发现这一点，所以欢迎任何进一步的评论和建议。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.