重建索引

本文探讨了数据库索引的维护策略,重点介绍了索引碎片的产生原因及其影响,并对比了合并索引与重建索引的方法及适用场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    关于索引重建,只需要记住一条: 如果它没坏,就不要去重建它。
 
    关于重建索引有用与否的讨论有很多。一般而言,极少需要重建 B 树索引,基本原因是 B 树索引很大程度
上可以自我管理或自我平衡。事实上,大多数索引都能保持平衡和完整,因为空闲的叶条目可以重复使用。
更新和删除操作确实会导致索引块周围的可用空间形成碎片,但是一般来说这些碎片都会被正确的重用。
 
 

 

    B+树索引对于删除的管理

 

    当删除表里的一条记录时,其对应于索引里的索引条目并不会被物理的删除,只是做了一个删除标记。

 

一个新的索引条目进入一个索引叶子节点的时候,oracle会检查该叶子节点里是否存在被标记为删除的索引

 

条目,如果存在,则会将所有具有删除标记的索引条目从该叶子节点里物理的删除。当一个新的索引条目进

 

入索引时,oracle会将当前所有被清空的叶子节点(该叶子节点中所有的索引条都被设置为删除标记)收

 

回,从而再次成为可用索引块。

 

     尽管被删除的索引条目所占用的空间大部分情况下都能够被重用,但仍然存在一些情况可能导致索引空间

 

浪费,并造成索引数据块很多但是索引条目很少的后果,这时该索引可以认为出现碎片。而导致索引出现

 

片的情况主要包括:

 

    1)不合理的、较高的PCTFREE。很明显,这将导致索引块的可用空间减少。

 

    2)经常被删除或更新的键值,以后几乎不再会被插入时。前面我们知道,某个索引块中删除了部分的索

 

引条目,只有当有键值进入该索引块时才能将空间收回。如果一个键值被删除或更新(更新是先删除旧值在

 

插入新值)后,该键值所在的数据块不在有新值插入

 

进来,就会导致碎片。

 

      如何判断索引出现碎片

 

      直接运行ANALYZE INDEX … VALIDATE STRUCTURE命令,然后检查index_stats视图的pct_used字段,如果该字段过低(该值没有标

 

准,参考值为50%),则说明存在碎片。

 

        碎片的影响

    

        碎片对条件值为等于的情况(包括In,or等)几乎没有影响,但对利用索引列的范围扫描(索引范围扫

 

描)有一定的影响,因为需要访问一些被标记为删除的无用的数据。

 

       去除碎片

 

       从上面的描述也可以知道,更新和删除操作确实会导致索引块周围的可用空间形成碎片,但是一般来说

 

这些碎片都会被正确的重用。所以一般来说不需要重建索引。定时重建索引更不可取。但是当确实出现了很

 

多碎片时该怎么去除碎片呢?这里有两种方法

 

合并索引:合并索引不改变索引的物理组织结构,只是简单地将B树叶子节点中的存储碎片合并在一起。

重建索引:重新创建一个新的索引,删除原来的索引。

合并索引并没有大幅地更改索引的物理结构,只是简单地将B树中的叶子节点中的碎片合在一起,因而并不会对叶子节点的存储参数和表空间进行更改,合并执行前与合并执行后的B树节点如图所示。




 
 

由图中可以看到,合并前放在两个节点中的碎片被合并到了1个节点,而另一个叶子节点就被释放了,这

 

个释放后的叶子节点就可以被再次利用,使得检索的次数变少,提高了查询的效率。

 

语法:ALTER INDEX idx_ename_empno COALESCE;

 

重建索引实际上就是对原有的索引的删除,再重新建一个新的索引。因为是对现有的索引进行删除和重

 

新创建,因此在使用ALTER INDEX时,可以使用各种存储参数来重新设定索引,比如使用STORAGE指

 

定存储参数,使用TABLE SPACE指定表空间或者是利用NOLOGGING选项避免产生重做日志信息。

 

语法:ALTER INDEX 索引名称 REBUILD

 

另外要注意的是,在线重建索引是高风险的操作。在线重建索引是基于日志表。当开始在线重建索引

 

时,系统会创建一个临时日志表,用于存放索引重建期间产生的日志信息。同时这个索引的FLAG字段上

 

会被设置REBUILD标识。当索引信息更变时,会把更变信息写入日志表。当在线重建失败时,这个日志

 

表和数据字典中的状态位都需要靠SMON来清理。要清理这个日志表,需要先锁定这张表。如果业务繁

 

忙,该表的数据一直在变化,SMON就无法对其进行锁定,因此就不能及时清理。如果该表更变十分平

 

凡,或许这项清理工作会在几天甚至几星期后才能完成。

 

所以建议在在线重建索引时,必须注意:

 

1.所有操作写成脚本在后台以nohup运行

 

2.对于高可用性系统,不要在无人值守的情况下进行此操作。

 

3.准备应急预案,一旦出现问题,马上采取措施。

 

 

重建索引和合并索引都可以消除索引碎片,但两者在使用上有明显的区别:

 合并索引不能将索引移动到其他表空间,但重建索引可以。

 合并索引代价较低,无须额外存储空间,但重建索引恰恰相反。

 合并索引只能在B树的同一子树中合并,不改变树的高度;但重建索引重建整个B树,可能会降低树的高度。

 

总结:1.对于索引来说, 如果它没坏,就不要去重建它。

 

           2.不要定期重建索引,可以定期检查索引,在判断索引确实出现问题后再去重建。

 

           3.在可以定期的合并索引。

            

 
<think>嗯,用户需要解决Windows搜索索引重建的问题。从描述看,用户可能遇到了文件搜索不准确或速度慢的情况,甚至可能遇到索引服务崩溃的现象(参考引用[2]提到的"搜索和索引"功能消失的问题)。 用户提到的两个引用很有价值:引用[1]说明了重建索引的基本流程和注意事项,引用[2]则反映了用户可能遇到的疑难解答入口缺失的特殊情况。需要特别注意,用户上次尝试过但没找到"搜索和索引"的疑难解答选项,这可能是系统版本差异或组件损坏导致的。 重建索引的核心步骤其实很明确:先停止服务→删除索引文件夹→重启服务。但有几个关键细节需要提醒用户: 1. 索引重建期间CPU和磁盘占用会飙升,最好在夜间操作 2. 部分系统可能隐藏了ProgramData目录,需要显示隐藏文件 3. 如果遇到权限问题,可能需要取得文件夹所有权 考虑到用户上次找不到系统自带的疑难解答工具,应该提供手动解决方案作为重点。另外要强调重建后首次搜索仍可能不完整,需要等待后台索引完成(任务栏搜索框会出现进度条提示)。 对于高级用户,可以补充索引位置迁移和排除文件夹的技巧。但核心解决方案还是分三步走:停服务→清数据→重启。最后要提醒重建后需要等待,引用[1]也特别说明了这点——"在完全重建索引之前搜索仍会混乱"。</think>以下是Windows重建文件索引的完整解决方案,按操作顺序逐步说明: --- ### **一、重建索引的核心步骤** 1. **停止搜索服务** - 按`Win+R`输入`services.msc` - 找到 **"Windows Search"** 服务 → 右键选择 **"停止"** ![服务停止示意图](https://example.com/search-service.png) (图示仅示意) 2. **删除旧索引数据库** - 打开文件资源管理器 → 输入路径: ```path %ProgramData%\Microsoft\Search\Data\ ``` - 删除该文件夹内 **所有内容**(需管理员权限确认) > ⚠️ 注意:此操作不会删除您的文件,仅清除索引缓存[^1] 3. **重启服务并触发重建** - 返回服务管理窗口 → 右键启动 **"Windows Search"** - 打开 **控制面板** → **索引选项** → 点击 **"高级"** → **"重建"** ![重建索引入口](https://example.com/rebuild-index.png) --- ### **二、加速重建的优化设置** 1. **限制索引范围** - 在 **"索引选项"** 中点击 **"修改"** - 取消勾选临时文件/系统文件夹(如`C:\Windows`) ```markdown 推荐保留: ✓ 文档 ✓ 下载 ✓ 桌面 ✓ 常用项目文件夹 ``` 2. **调整索引优先级** - 任务管理器 → 右键 **"SearchIndexer.exe"** → **设置优先级** → 选 **"低于正常"** - 防止索引占用过多资源影响工作[^1] --- ### **三、疑难问题解决** #### ▶ **情况1:无法停止服务** - 以管理员身份运行CMD: ```cmd net stop "Windows search" /y ``` #### ▶ **情况2:索引选项无响应** - 重置搜索组件: 1. 管理员PowerShell执行: ```powershell Get-AppXPackage -Name "Microsoft.Windows.Cortana" | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} ``` 2. 重启系统 #### ▶ **情况3:重建后仍搜索异常** - 运行系统文件检查: ```cmd sfc /scannow ``` ```cmd DISM /Online /Cleanup-Image /RestoreHealth ``` --- ### **重建索引耗时说明** | 数据量 | 预估时间 | 使用建议 | |--------------|----------|-------------------| | < 50GB | 30~60分钟| 可后台运行 | | 50~200GB | 2~5小时 | 建议夜间操作 | | > 200GB | 8小时+ | 关闭其他程序运行 | > 📌 重建期间搜索功能仍可用,但结果可能不完整,需等待任务栏搜索框进度条消失才完成[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值