索引的优化和维护
数据库优化的常见策略与技巧
数据库优化的常见策略与技巧数据库是现代应用程序的核心组成部分之一。
它负责存储、管理和提供数据。
随着数据量不断增长和应用程序需求的变化，数据库的性能也面临着挑战和压力。
为了充分利用数据库资源并提高应用程序的性能，数据库优化变得至关重要。
本文将介绍数据库优化的常见策略与技巧，帮助开发人员和管理员改善数据库性能并提高应用程序的效率。
1. 索引优化索引是提高数据库性能的关键因素之一。
通过在数据库表中创建正确的索引，可以加快数据的检索速度和查询性能。
常见的索引优化策略包括以下几点：1.1. 唯一索引：使用唯一索引可以确保表中某个列的值是唯一的，避免数据冲突和重复。
唯一索引可以提高数据的查询速度，特别适用于经常执行查找和更新操作的列。
1.2. 聚集索引：聚集索引是按照表中某个列的物理顺序进行存储的索引。
聚集索引可以加快按照该列的排序和范围查询速度，特别适用于经常执行范围查询的列。
1.3. 非聚集索引：非聚集索引是在表的外部存储位置创建的索引，它包含了表中某些列的引用和指向数据位置的指针。
非聚集索引可以加快数据的查找速度，适用于经常执行精确查找的列。
1.4. 组合索引：组合索引是根据表中多个列的值来创建的索引。
通过合理地选择索引列的顺序和选择列的数量，可以减少索引的大小和提高查询性能。
2. 查询优化优化SQL查询语句是提高数据库性能的关键策略之一。
以下是几个常见的查询优化技巧：2.1. 使用合适的操作符：在SQL查询中，选择适当的比较操作符可以加速查询的执行。
例如，使用"="操作符而不是"LIKE"操作符进行精确匹配，可以提高查询速度。
2.2. 避免使用通配符：使用通配符（如"%")进行模糊匹配可能导致全表扫描，降低查询性能。
尽量避免在查询语句中使用通配符，或者谨慎使用。
2.3. 避免使用子查询：子查询是在主查询的基础上进行嵌套执行的查询语句，往往会导致性能下降。
数据库优化方法与技巧
数据库优化方法与技巧数据库是现代信息系统中的核心组成部分，负责存储和管理数据，为应用程序提供高效的数据操作和查询功能。
然而，随着数据量和访问量的增加，数据库性能可能会受到限制，导致应用程序响应变慢甚至崩溃。
为了解决这个问题，数据库优化成为了必不可少的一环。
本文将介绍一些常用的数据库优化方法与技巧，从索引优化、查询优化、数据模型设计等方面来提高数据库的性能。
一、索引优化索引是提高数据库查询性能的重要手段。
在设计数据库时，通过对关键字段创建索引可以大大减少查询的时间复杂度，提高查询效率。
确定哪些字段需要创建索引，是一个需要仔细考虑的问题。
一般来说，可以根据以下几个原则进行索引优化：1.选择合适的索引类型：不同的数据库支持不同的索引类型，如B树索引、哈希索引、全文索引等。
根据需要选择最适合的索引类型可以提高查询效率。
2.避免过多索引：虽然索引可以加速查询，但是过多的索引也会带来额外的维护成本。
只选择关键字段创建索引，并在数据库设计中尽量避免冗余字段可以减少索引的数量。
3.使用组合索引：当需要同时根据多个字段进行查询时，可以考虑创建组合索引，将多个字段合并在一起作为索引，可以提高查询效率。
4.定期维护索引：随着数据库的更新，索引的性能可能会下降。
定期对索引进行维护，如重新构建索引、优化索引大小等，可以保持索引的高效性。
二、查询优化查询是数据库最常用的操作之一，优化查询性能对整个系统的响应速度有着重要的影响。
下面是一些常见的查询优化方法：1.减少查询结果集：只返回应用程序需要的数据可以减少查询的时间和数据传输的开销。
尽量使用SELECT语句指定需要的字段，避免使用SELECT * 来返回全部字段。
2.使用JOIN优化查询：当涉及到多个表的查询时，使用JOIN操作将多个查询合并为一个复杂查询可以减少数据库的访问次数，提高查询效率。
3.避免使用子查询：尽量避免使用子查询，特别是在大数据量的情况下，因为子查询会增加数据库的负载和查询的时间。
数据库索引失效与优化的解决方案(十)
数据库索引是提高数据库查询效率的重要手段，但有时候索引可能会失效，导致查询变得缓慢。
本文将探讨数据库索引失效的原因，并提出相应的优化解决方案。
I. 索引失效的原因索引失效可能由多种原因引起，下面分别介绍其中一些常见的原因。
1. 数据量过大当数据库中的数据量过大时，索引的效果会逐渐减弱。
这是因为索引需要占用一定的磁盘空间，并且在插入、删除和更新数据时需要进行相应的维护操作。
如果数据量过大，这些维护操作会导致索引失去其原本的效果。
解决方案：- 对于特别大的表，可以考虑拆分为多个较小的子表，并使用分布式数据库进行管理。
- 对于较少进行插入、删除和更新操作的表，可以考虑使用更加精确的索引策略，例如覆盖索引。
2. 索引列上存在函数当在查询条件中对索引列应用了函数时，索引将无法被利用，从而导致索引失效。
常见的函数包括对列进行计算、日期转换、字符串处理等。
解决方案：- 尽量避免在查询条件中对索引列应用函数，可以通过对数据进行预处理或者新建一个专门用于查询的列来解决。
3. 索引列上使用了类型转换如果在查询条件中对索引列进行了类型转换，例如将字符串转换为数字进行比较，索引也将失效。
解决方案：- 尽量避免在查询条件中对索引列进行类型转换，可以通过修改查询条件或者调整列的类型来解决。
4. 索引列上存在模糊查询模糊查询（如使用LIKE关键字）在某些情况下无法充分利用索引，因为模糊查询需要对索引列进行全表扫描，导致效率低下。
解决方案：- 尽量避免在索引列上进行模糊查询，可以考虑使用全文索引或者其他相应的技术来提高查询效率。
II. 索引优化的解决方案除了处理索引失效的原因外，还可以通过优化索引来提高数据库查询效率。
下面介绍几种常见的索引优化解决方案。
1. 使用覆盖索引覆盖索引是指索引包含了查询需要的所有列。
通过使用覆盖索引，可以避免数据库对表进行额外的查找操作，从而提高查询效率。
2. 删除不必要的索引在数据库中创建过多的索引会增加数据库维护的工作量，并且在插入、删除和更新数据时会导致额外的性能损耗。
数据库索引的更新与维护方法(二)
数据库索引的更新与维护方法1. 引言数据库索引是一种对数据库表中的数据进行快速访问和搜索的数据结构。
它可以加速数据的检索和查询操作，提高数据库的性能。
然而，随着数据库中数据的不断增加和修改，索引也需要进行更新和维护。
本文将介绍数据库索引的更新与维护方法，以帮助读者更好地理解和应用数据库索引。
2. 索引的作用与分类数据库索引可以加速数据的检索和查询操作，它通过构建一棵有序的数据结构，将表中的数据按照一定的规则进行分类和排序。
常用的索引类型有B树索引、哈希索引和全文索引等。
不同的索引类型适用于不同的场景，选择合适的索引类型可以提高查询的效率和性能。
3. 索引的更新索引的更新是指在数据库中对表的数据进行插入、删除和修改等操作时，对索引数据结构进行相应的更新。
索引的更新需要考虑以下几个方面：- 插入操作：当向数据库中插入一条新的记录时，需要在索引中添加相应的键值对。
插入操作的开销取决于索引类型的选择和数据规模的大小。
- 删除操作：当从数据库中删除一条记录时，需要在索引中删除相应的键值对。
删除操作的开销也与索引类型和数据规模有关。
- 修改操作：当对表中的记录进行修改时，可能会涉及到索引中的键值对的更新。
修改操作的开销取决于具体的更新需求和索引的规模。
4. 索引的维护索引的维护是指对索引数据结构进行定期的优化和重建，以保持索引的性能和效率。
索引的维护需要考虑以下几个方面：- 查找频率：根据索引的使用频率，可以判断是否需要对索引进行重建或优化。
如果某个索引被频繁地访问，那么可能需要重建或优化该索引。
- 索引的碎片：索引的插入、删除和修改等操作可能导致索引数据结构的碎片化。
定期对索引进行碎片整理，可以提高索引的性能和效率。
- 统计信息的更新：索引的优化和重建需要依赖于表中数据的统计信息。
定期更新表中的统计信息，可以为索引的优化和重建提供准确的数据支持。
5. 索引的调优索引的调优是指通过对索引进行合理的设计和规划，提高查询的效率和性能。
数据库查询优化中索引与统计信息维护技术解析
数据库查询优化中索引与统计信息维护技术解析数据库查询性能是影响整个系统性能的重要因素之一。
为了提高数据库的查询效率，开发人员常常会选择各种优化策略，其中索引与统计信息维护是常见的优化手段之一。
本文将深入探讨数据库查询优化中索引与统计信息维护技术的原理与实践。
一、索引的作用与分类索引是数据库中存储有序数据的结构，可以加快查询速度。
通过将关键列的值存储在索引中，数据库可以快速定位到需要查询的数据，而不需要全表扫描。
在数据库查询优化中，索引的作用主要体现在以下两方面：1. 提高查询的速度：通过使用索引，数据库可以直接定位到数据所在的位置，避免全表扫描，从而大幅度提高查询速度。
2. 降低数据库的负载：通过使用索引，数据库可以减少磁盘的IO操作，减少查询所需要的CPU和内存资源，从而降低数据库的负载。
索引可以根据存储方式的不同进行分类，主要有以下几种类型：1. B-Tree索引：B-Tree索引是最常用的索引类型，适用于范围查询和等值查询。
它将索引数据组织成一个平衡的B树结构，树的节点按照关键值大小有序排列，可以快速定位到需要查询的数据。
2. Hash索引：Hash索引适用于等值查询，将索引数据存储在散列表中。
通过计算数据的哈希值，可以快速定位到需要查询的数据，但不适用于范围查询。
3. 全文索引：全文索引适用于文本字段的模糊查询。
通过对文本进行分词，并构建倒排索引，可以快速定位到包含指定关键词的文档。
4. 聚簇索引：聚簇索引将数据按照指定列的顺序物理存储，彼此相邻的数据存储在磁盘上也是相邻的。
它适用于频繁进行基于范围查询的场景，能够大幅度提高查询速度。
二、统计信息的作用与更新统计信息是数据库中用于优化查询的重要依据之一。
它是关于数据分布、数据结构和数据集合的描述性信息，用于数据库查询优化器生成高效的执行计划。
统计信息的作用主要体现在以下几个方面：1. 查询优化：数据库查询优化器根据统计信息确定如何访问数据，选择合适的查询计划。
如何进行高效的数据库索引优化
如何进行高效的数据库索引优化数据库索引是提高查询性能的重要手段之一。
通过正确使用索引，可以减少数据库的IO操作，提高查询效率。
下面将介绍一些高效的数据库索引优化的方法。
1.基本的索引优化原则-唯一性:根据数据表的唯一性约束，创建唯一索引，以保证数据的一致性和完整性。
-选择适当的列:在创建索引时，选择有重复值、经常查询或者范围查询的列，可以提高索引的效率。
-索引覆盖:尽量使用索引满足查询需求，避免使用全表扫描，提高查询效率。
2.表结构优化-商定数据类型:选择适当的数据类型，可以减小存储空间，提高索引效率。
-表分解:当表数据过大时，可以进行表分解，将相对不常用的列分解到独立的表中，减小主表的大小，提高索引效率。
3.索引类型选择- B-Tree索引:适用于查询条件是等值查询或范围查询的情况，对于数据有序的列，如日期、数字等，B-Tree索引效果较好。
-哈希索引:适用于等值查询较多的情况，哈希索引可以直接定位到存储区域，比B-Tree索引更快。
但是，哈希索引不支持范围查询。
-全文索引:适用于全文搜索的场景，如文章的关键字搜索。
-空间索引:适用于地理信息查询、位置服务等场景，可以优化空间查询的性能。
4.索引的创建和维护-避免过多的索引:太多的索引会增加索引维护的开销，也会降低更新操作（如插入、删除、更新）的性能。
在开发过程中要谨慎选择创建索引的字段。
-定时维护索引:经常进行索引的重建和优化，保证索引的最新状态，提高查询性能。
-删除不必要的索引:定期检查和分析索引的使用情况，删除不再使用或者无效的索引。
5.统计信息的收集和更新-更新统计信息:统计信息对于查询优化至关重要。
定期收集和更新统计信息，以便数据库优化器生成更好的执行计划。
-执行计划的分析:分析查询的执行计划，根据执行计划优化查询语句、索引或者表结构。
6.查询优化技巧-减少全表扫描:避免在查询中使用不带索引的列，使用索引尽量覆盖查询的需求。
-提高查询的可重用性:对于经常使用的查询，将其封装成存储过程或函数，可以避免重复的编译和解析过程，提高查询效率。
数据库索引的维护与优化技巧
数据库索引的维护与优化技巧数据库索引是提高数据库查询性能和数据检索效率的重要手段。
然而，在大量数据的情况下，使用不当的索引或索引的维护不完善会导致性能下降甚至崩溃。
本文将介绍一些数据库索引的维护和优化技巧，以帮助开发人员有效提升数据库的性能。
1.选择合适的索引在创建索引时，需要选择适合的字段作为索引列。
通常情况下，那些经常用于查询条件的字段应该作为索引列。
例如，在用户表中，根据用户名进行查询的频率很高，那么可以考虑为用户名列创建索引。
然而，过多的索引也会降低写操作的性能，因此需要权衡和选择。
2.避免冗余索引冗余索引是指多个索引覆盖相同的查询。
在实际应用中，由于人为疏忽或者维护失误，可能会创建相似的索引。
这不仅浪费了存储空间，还降低了修改数据时的性能。
因此，在设计数据库时，需要避免创建冗余索引，可以通过审查现有索引来识别和删除冗余索引。
3.使用组合索引组合索引是指由多个列组成的索引。
当多个列常常同时出现在查询条件中时，使用组合索引可以提高查询效率。
例如，在订单表中，同时根据订单日期和订单状态进行查询，可以为这两个字段创建组合索引。
组合索引更适用于查询频繁的列组合，可以减少索引的个数和占用的存储空间。
4.避免过度索引虽然索引可以提高查询性能，但是过度使用索引会降低写操作的性能。
因此，需要谨慎选择索引，并考虑索引对写操作的影响。
不需要频繁更新或插入的列可以不创建索引，以减少索引的维护和空间开销。
5.及时更新和重新组织索引随着数据的增长和修改，索引的结构和数据会变得不连续。
这可能导致查询效率下降。
因此，定期检查和更新索引是保持数据库性能的重要步骤之一。
可以通过数据库提供的优化工具或脚本来重新组织索引，以减少索引碎片和提高查询效率。
6.注意索引与数据的一致性当数据库中的数据发生改变时，索引也需要相应的更新。
如果不及时更新索引，可能会导致查询结果不一致或索引失效。
因此，在进行数据的插入、更新和删除操作时，确保及时更新相关的索引，保持数据的一致性和正确性。
数据库优化与维护的工作总结
数据库优化与维护的工作总结一、引言作为一名数据库管理员，我在过去一年中致力于数据库的优化与维护工作。
在这篇总结中，我将回顾并分享我在这个领域的经验和成果。
通过更好的数据库优化和有效的维护策略，我们团队在提高系统性能、减少故障和提升数据安全方面取得了显著的成果。
二、性能优化1. 索引优化通过分析数据库的查询计划，我们识别并优化了关键查询的性能瓶颈。
经过对表结构和数据分布的深入研究，合理地优化了索引的选取和创建。
这一系列的操作显著提高了查询效率，降低了系统的响应时间。
2. 查询优化通过对频繁查询的SQL语句进行调整和重写，我们减少了查询的复杂性和冗余性，并且利用数据库的内置函数和特性来提升查询效率。
此外，我们也大量使用了查询缓存和预编译技术来减少查询的执行时间，从而提高系统的整体性能。
3. 硬件优化除了对数据库进行优化，我们还升级了服务器硬件设施，增加了CPU核心数和内存容量。
这些硬件的升级使得数据库服务器能够更好地处理大量的并发请求，提高了数据库的整体性能。
三、维护策略1. 数据备份与恢复数据备份是确保数据库安全可靠的重要措施。
我们采用了定期全量备份和增量备份的方式，并将备份数据存储在不同地点的离线媒介上，以防止意外数据丢失。
此外，我们还定期测试备份数据的完整性和可恢复性，确保在系统故障时能够快速地将数据恢复到正常状态。
2. 定期维护与优化根据数据库的实际使用情况与特点，我们制定了定期的维护计划。
这包括数据库的重建、重新索引和统计信息的收集，以及对数据库表结构的优化。
通过定期维护，我们保持数据库的稳定性和性能，并及时发现并解决潜在的问题。
3. 监控和警报系统为了及时发现和解决数据库的异常情况，我们搭建了监控和警报系统。
通过设置阈值和指标，我们可以实时监控数据库的性能、空间使用率和连接状态等。
一旦发现异常，系统会自动发送警报信息给相关人员，并触发相应的应急处理措施，保障数据库的稳定性和安全性。
四、总结与展望通过数据库优化与维护的工作，我们取得了显著的成绩。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
索引的优化和维护目的：通过对数据库中的索引进行优化和维护，提交检索的速度和效率。
原理：随着数据库的使用，不可避免地对基本表进行插入，更新和删除，这样导致叶子行在索引中被删除，使该索引产生碎片。
插入删除越频繁的表，索引碎片的程度也越高。
碎片的产生使访问和使用该索引的I/O成本增加。
碎片较高的索引必须重建以保持最佳性能。
当索引的层数增大时，I/O的成本增加，检索的效率开始降低，oracle建议当索引的层数大于3时，则应当对此索引进行重建以提交效率。
随着表记录的增加，相应的索引也要增加。
如果一个索引的next值设置不合理(太小)，索引段的扩展变得很频繁。
索引的extent太多，检索时的速度和效率就会降低。
当然还有就是由于一些人为的原因或者系统表的迁移，有可能造成索引的失效，也会降低检索的效率和速度。
通过对索引进行分析，找出碎片比例占索引20%以上的索引；通过查询和索引相关的数据字典和表找出失效的索引、层数大于3的索引和被扩展超过10次的索引；将这些问题索引数据统计到临时表。
分别对这些索引进行重建或重新设置 next值（尽量增大，到合理的数值），从而达到优化索引和提高数据库效率的目的。
脚本：DECLAREv_index_name varchar2(100);v_analyze_str varchar2(300);height number;lf_rows number;del_lf_rows number;v_ex_count number;v_idx_owner varchar2(30);v_tab_name varchar2(50);v_tabspa_name varchar2(50);v_idx_status varchar2(10);CURSOR analyze_index ISSELECT index_name,table_owner,table_name,tablespace_name,statusFROM user_indexes;BEGINOPEN analyze_index;FETCH analyze_index INTOv_index_name,v_idx_owner,v_tab_name,v_tabspa_name,v_idx_status;WHILE analyze_index%FOUND LOOPif v_idx_status ='INVALID' theninsert into lifemenu.index_stats_probvalues(v_index_name,null,null,null,‘该索引已失效’,v_idx_owner,v_tab_name,v_tabspa_name,v_idx_status);end if;if v_idx_status ='VALID' thenv_analyze_str := 'analyze index '||v_index_name||' validate structure';EXECUTE IMMEDIATE v_analyze_str;SELECT HEIGHT,DECODE(LF_ROWS,0,1,LF_ROWS),DEL_LF_ROWSINTO height,lf_rows,del_lf_rowsFROM index_stats;if (del_lf_rows/lf_rows)>0.2 theninsert into lifemenu.index_stats_probvalues(v_index_name,del_lf_rows/lf_rows,null,v_ex_count,'该索引的碎片太多，建议重建',v_idx_owner,v_tab_name,v_tabspa_name,v_idx_status);end if;if height>=4 and (del_lf_rows/lf_rows) <=0.2 theninsert into lifemenu.index_stats_probvalues(v_index_name,null,height,v_ex_count,'该索引的层数超过3，建议重建',v_idx_owner,v_tab_name,v_tabspa_name,v_idx_status);end if;select count(*)into v_ex_countfrom user_extentswhere segment_name =v_index_name;if v_ex_count>=11 and (del_lf_rows/lf_rows)<=0.2 and height<4 theninsert into lifemenu.index_stats_probvalues(v_index_name,null,null,v_ex_count,'该索引扩展超过10次，建议重建时增大参数next',v_idx_owner,v_tab_name,v_tabspa_name,v_idx_status);end if;end if;commit;v_index_name :='';v_analyze_str :='';v_idx_status :='';FETCH analyze_index INTOv_index_name,v_idx_owner,v_tab_name,v_tabspa_name,v_idx_status;END LOOP;CLOSE analyze_index;END;执行结果：执行结果存储在表index_stats_prob中，表的结构和说明如下：create table INDEX_STATS_PROB(INDEX_NAME VARCHAR2(30) not null,//索引名称FRAG_PCT NUMBER, //碎片比例HEIGHT NUMBER, //索引层数EXTENT_TIME NUMBER, //扩展次数COM VARCHAR2(50), //建议处理方法OWNER VARCHAR2(30) not null,//所属用户TABLE_NAME VARCHAR2(50), //所属表TABLESPACE_NAME VARCHAR2(50), //所在表空间STATUS VARCHAR2(10) //状态)其中问题索引主要就有四类：1 碎片比例大于20%的2 索引层数大于3的且不属于第一类的3 索引扩展次数超过10的且不属于第一类和第二类的4 失效的索引之所以这样处理，是因为碎片比较多的问题索引必须进行处理，其次是层数多的索引，再其次是扩展次数比较多的索引。
在测试数据库ld05sh中的执行结果中，没有发现第二类和第四类的问题索引。
下列是分别在各个用户下执行脚本所耗费的时间的列表：处理建议：1．对于第一类和第二类问题索引，即碎片比例大于20%的问题索引和索引层数大于3的且不属于第一类的，都建议进行重建。
可以执行下列语句来找出这些索引。
同时我们对这两类问题索引也提供了它们扩展的次数，因此如果发现它们被扩展的次数过大，那么在重建的时候也要注意增大索引的next参数。
SELECT *FROM INDEX_STATS_PROBWHERE FRAG_PCT IS NOT NULL OR HEIGHT IS NOT NULLORDER BY FRAG_PCT DESC;重建语句如下：alter index 用户名.索引名 rebuildtablespace 表空间名storage(initial 初始值 next 扩展值)nologging如果出于空间或其他考虑，不能重建索引，可以整理索引：alter index用户名.索引名 coalesce2．对于第三类索引，由于发现在ld05sh中此类索引特别多，所以建议重建扩展次数在50次以上的索引，当然如果在其他环境中发现这类索引的数量不是很多，需要综合考虑，按照扩展次数的多少来确定重建的优先次序，即扩展次数越多的，越优先考虑重建，重建时主要是增大索引的next参数。
执行下列语句来找出这些索引：SELECT *FROM INDEX_STATS_PROBWHERE FRAG_PCT IS NULL AND HEIGHT IS NULL AND EXTENT_TIME>10ORDER BY EXTENT_TIME DESC;重建语句相同，注意重建时要增大next 参数：alter index 用户名.索引名 rebuildtablespace 表空间名storage(initial 初始值next 扩展值)nologging3．重建索引后，原有的索引被删除，这样会造成表空间的碎片。
整理表空间的碎片alter tablespace 表空间名 coalesce4. 另外，优化索引还有一些普遍的原则，如：1）定期对数据更新（主要是删除）频繁的表重建索引2）建议索引不要建立在系统表空间内3）建议索引建立在db_block_size比较大的表空间中4）记录太少的表，应当少建或不建索引；经常处理的业务表（插入、删除、修改），应在查询允许的情况下尽量减少索引。
具体操作：登录要分析的数据库在lifemenu用户下创建存放分析数据的表index_stats_prob，脚本如下：create table INDEX_STATS_PROB(INDEX_NAME VARCHAR2(30) not null,FRAG_PCT NUMBER,HEIGHT NUMBER,EXTENT_TIME NUMBER,COM VARCHAR2(50),OWNER VARCHAR2(30) not null,TABLE_NAME VARCHAR2(50),TABLESPACE_NAME VARCHAR2(50),STATUS VARCHAR2(10))将此表授权给其他的用户：grant all on index_stats_prob to 用户名用其他用户登录要进行索引优化的数据库，执行PL/SQL脚本，然后参照处理建议对索引进行重建，从而达到优化索引，提高效率的目的。
各个用户下的执行时间都不同，具体可以参照执行结果中的脚本耗费时间来设计脚本执行计划。
验证说明：重建索引后，检索的速度和效率都会得到提高，用户可以通过前后的检索所需时间的比较来验证。
建议：1．首先需要肯定的一点，该文章总结的非常好，基本上考虑到了在实际使用过程中对索引维护尤其是在判断索引要不要重建的问题。