Oracle数据库索引创建指南：三要素提升性能

如何合理创建Oracle数据库索引的3个要求

如何合理创建Oracle数据库索引的三个要求：在Oracle数据库中，创建索引是比较简单的。
但合理地创建索引是比较困难的。
笔者认为，创建索引时要做三件事，即在适当的表和列上创建适当数量的索引。
虽然这些可以用一句话概括为优化索引的基本原理，但这样做需要数据库管理员付出相当大的努力。
具体来说，为了实现这三个适当的要求，需要满足以下要求。
1.根据表的大小创建索引。
虽然为表创建索引可以提高查询效率。
然而，数据库管理员应该记住，索引也需要一些开销。
这并不意味着为所有表创建索引就会提高数据库性能。
这种理解是错误的。
相反，如果不管情况如何都为所有表创建索引，这会对数据库性能产生负面影响。
因为现在滥用索引的成本可能远远大于随之而来的性能收益。
因此，笔者认为数据库管理员应该首先为适当的表创建索引，而不是为所有表建立索引。
一般来说，较小的表没有必要创建索引。
例如，在ERP系统数据库中，部门表用于存储公司部门的信息。
一个企业一般只有十几个当事人，最多不超过一百个。
这100条记录对于人们来说可以算很多了。
但对于计算机来说这还不够。
因此没有必要为类似的小表创建索引。
因为即使创建了索引，其性能也不会提高多少。
相比之下，索引创建的开销，比如维护成本等就更大。
换句话说，付出的多于得到的显然是违反常识的。
此外，即使对于非常大的表，也没有必要创建索引。
有些表虽然比较大，但是记录数量却非常多。
但此时为这张表创建索引并不一定合适。
例如系统中有一张表，主要用来保存数据库中的一些变化信息。
通常，此信息仅对数据库管理员可用。
此时不适合为该表创建索引。
由于这个表很少使用，所以只有出现问题时才需要检查它。
其次，即使查了，也没有多少记录可以查询，可能是上周的更新记录等等。
对于一些非常大的表，创建索引有时无法达到预期的效果。
而且，在表上创建索引的成本比普通表要大得多。
那么，是否要为大表创建索引呢？笔者认为，这主要取决于两个方面。
首先我们需要关注这张大表中经常需要查询的记录数量。
一般来说，如果频繁查询的数据不超过10-15%，则不需要建立索引。
因为现在索引的成本可能远远大于性能的改进。
这个比率只是一个经验数据。
如果数据库管理员需要得出更精确的结论的话，那就是需要进行测试分析。
也就是说，数据库管理员必须检查一次全表扫描的时间，看看它比建立索引后的查询时间长还是短。
如果它很长，则意味着您需要创建索引。
如果不是，则说明全表扫描速度更快。
此时无需创建索引。
总之，在考虑是否为表创建索引时，一般情况下，小表没有必要创建索引。
要打印电表，需要对真实情况进行有效分析。
更简单的，可以根据一个大概的比例来确定。
如果想要更精确，可以进行全表扫描性能分析，以确定索引创建是否真正按照预期提高了数据库性能。
2.根据列特征创建索引。
列的特性不同，创建索引的效果也不同。
数据库管理员需要知道对哪些列建立索引才能事半功倍。
同时你还需要了解要哪些列创建索引，但这会有事半功倍的效果。
这对他们来说是好事……什么样的字段应该被索引？根据笔者的经验，为具有以下特征的列创建索引往往可以产生更明显的效果。
例如，对于一些重复内容较少的列，尤其是那些定义了唯一约束的列。
在这些列上创建索引通常可以产生很好的结果。
例如，如果一些空值列与非空值列混合在一起，如果用户需要频繁查询所有非空值记录的列，最好为其设置索引。
如果经常需要对多个表进行合并查询，那么在用于合并的列上设置索引可以达到事半功倍的效果。
可见，指标设置是否恰当不仅与数据库设计架构有关，还与企业的经济活动有关。
为此，对于一些套装软件，虽然数据库管理员一开始就已经做好了索引优化工作。
但随着经济数据随之增加，这一指标的效果将日益受到削弱。
这主要是因为记录表格式影响索引优化的效果。
因此笔者建议所有的数据库管理员，即使是使用大型软件公司的软件包，也要在一段时间后，例如一年后，对数据库索引进行优化。
删除该删除的内容，更改该更改的内容，以提高数据库性能。
例如，数据库中有一张表，用于存储用户信息。
有一个字段ID号，这是一个唯一的字段。
该字段的索引是在数据库设计期间创建的。
但当使用这个数据库时，用户很少输入他们的ID号码。
我们通常不会使用这个号码来提问。
当逐月到达的记录越来越多时，这个ID号上的索引字段不仅不能提高数据库查询性能，反而变得毫无用处。
对于这些有很多NULL值并且不经常查询所有非NULL值记录的列，数据库管理员必须确定清除这些列上的索引。
因此，指标的优化和调整是一个动态的过程。
这并不意味着数据库设计后就不应修改。
数据库管理员经常需要根据对记录所做的更改进行适当的更改。
以提高索引性能。
3、一张表需要创建多少个索引？虽然在表上创建的索引数量没有限制，但并不总是越多越好。
换句话说，在创建索引时，1+1>2往往是不成立的。
有时，创建多个索引可能会产生相反的效果。
那么一张表上应该创建多少个索引呢？这并没有明确的标准。
相反，数据库管理员必须根据实际使用情况和数据库中记录的情况做出判断。
一般来说，表的索引越多，查询速度就越快。
但是，表的更新速度会降低。
这主要是因为表更新（例向表中插入一条记录）的速度随着索引的增加而增加。
这主要是因为当你更新记录时，需要更新相关的索引信息。
因此，在表上创建的索引数量需要在更新速度和查询速度之间取得平衡。
例如，对于某些数据仓库或决策数据库系统，它主要用于查询。
相关记录通常是在数据库初始化期间插入的。
目前，设置多个索引可以提高数据库查询性能。
同时，由于记录很少更新，即使索引很多，更新速度也不会受到影响。
即使最初需要入大量数据，也可以先禁用索引。
等待数据导入后再启用索引。
这有助于减少索引对数据更新的影响。
相反，如果这些表中的记录经常需要更新，就像在某些事务性应用系统中发生的那样，数据更新操作是很常见的。
此时，如果在表上创建太多索引，更新速度就会受到影响。
由于更新操作比较频繁，因此对其带来的负面影响远大于查询效率的提升。
目前您需要限制索引的数量，仅在少数必要的字段上创建索引。
我平时优化数据库的时候，经常会根据这些来设置列的索引。
您可以查询相关的动态视图，看看更新操作（包括更新、删除、插入等）是否占该表操作的较大比例，或者查询操作是否占较大比例。
当过多的索引影响了更新操作的速度时，数据库管理员需要禁用一些索引来提高数据库性能。
简而言之，在适当的表和适当的列上创建适当的索引。
这句话包含很多含义，以上内容只是其中的一部分。
俗话说，师父带路，修炼靠自己。
作者这里指的是我能点击多少。
索引优化的一些具体内容还需要读者在下文中去体验和总结。
他们的日常工作。

三大准则11个技巧,手把手教你创建数据库索引

创建高效的数据库索引需要遵循三个主要准则和11个技巧，以确保最佳的查询性能和高效的数据维护。
本文以B+树索引为例，详细介绍了索引创建的最佳实践，同时也重点介绍了不同索引类型的适用条件和限制。
详细信息请参见“数据库索引的类型”。
首先，索引创建应该基于工作负载而不是表结构，确保它包含数据库执行的所有SQL语句。
其次，索引创建应考虑SQL结构以优化数据放置。
最左前缀原则指导我们如何高效地利用索引来快速定位数据，范围条件也有助于快速访问数据。
避免查询中的排序对于索引设计也至关重要。
使用索引可以避免不必要的数据排序操作。
对于分区表，本文深入讨论了创建和维护本地分区、全局分区和非分区全局索引的方法。
不同的数据库对分区表索引的支持不同。
另外，使用功能索引、条件索引索引融合技术是提高查询性能的有效手段。
通过在外键上创建索引，可以大大提高表关联的效率，特别是在支持索引合并的数据库中。
最后，创建索引时必须考虑约束条件，包括索引数量、磁盘空间使用情况以及对写入性能的影响，以确保系统整体性能最佳。
综合应用上述原理和技术，可以实数据库索引的优化配置，从而提高查询性能和数据维护效率。

数据库索引创建索引

在数据库中，创建索引是提高查询性能的关键步骤。
最常见的情况是对WHERE子句中出现的字段进行索引。
例如，创建名为mytable的表，如下：

sqlCREATETABLEmytable(idserialprimarykey,category_idintnotnulldefault0,user_idintnotnulldefault0,adddateintnotnulldefault0);

如果经常使用查询语句类似：

sqlSELECT*FROMmytableWHEREcategory_id=1;

为Category_id创建简单索引：

sqlCREATEINDEXmytable_categoryidONmytable(category_id);

For几个选择条件，例如：

sqlSELECT*FROMmytableWHEREcategory_id=1ANDuser_id=2;

错误的做法是为user_id创建一个列表，而不是一个索引，而应该创建多个索引：

sqlCREATEINDEXmytable_categoryid_useridONmytable(category_id,user_id);

命名时习惯使用“表名_字段名”1_fieldname2"，可以轻松快速识别正在使用适当的索引。

要检查数据库是否将使用这些索引，请使用EXPLAIN命令。
我们以Postgres为例：

sqlEXPLAINSELECT*FROMmytableWHEREcategory_id=1ANDuser_id=2;

Postgres返回：

plaintextNOTICE:QUERYPLAN:IndexScanusingmytable_categoryid_useridonmytable(cost=0.00..2.02rows=1width=16)

这表明数据库正在使用索引，并且正在使用创建的第二个索引。
命名规则可以帮助您快速确定正确的索引。

如果有ORDERBY子句，则在该字段上创建索引。
例如：

sqlSELECT*FROMmytableWHEREcategory_id=1ANDuser_id=2ORDERBYadddateDESC;

为adddate创建索引：

sqlCREATEINDEXmytable_categoryid_userid_adddateONmytable(category_id,user_id,adddate);

sqlCREATEINDEXmytable_categoryid_userid_adddateONmytable(category_id,user_id,adddate);

索引名称创建后，将被缩短为“mytable_categoryid_userid_addda”。

测试结果：

sqlEXPLAINSELECT*FROMmytableWHEREcategory_id=1ANDuser_id=2ORDERBYadddateDESC;

返回：

IndexScanusingmytable_categoryid_userid_adddaonmytable(cost=0.00..2.02rows=1width=16)

数据库正在执行不必要的排序操作，表明性能下降。
提供了其他提示以提高效率。

通过调整查询语句，数据库优化器可以使用预期的索引，例如：

sqlEXPLAINSELECT*FROMmytableWHEREcategory_id=1ANDuser_id=2ORDERBYcategory_idDESC,user_idDESC,adddateDESC;

返回返回：

plaintextNOTICE:QUERYPLAN:IndexScanBackwardusingmytable_categoryid_userid_adddaonmytable(cost=0.00..2.02rows=1width=16)

使用预期索引并向后读取以避免排序。

在处理复杂查询（例如对多个表进行联接查询）时，尤其是当WHERE子句中的字段来自多个表时，请尽量避免这种情况。
如果无法避免，则需要为每个表创建单独的索引，并使用EXPLAIN进行检查。
如果使用预期的索引，查询性能将会提高。

请注意，太多索引会减慢更新和插入速度，因为每个索引文件都必须更新。
对于经常更新和插入的表，不需要为很少使用的WHERE子句创建单独的索引。
对于小表，排序成本较低，并且不需要额外的索引。

创建索引的基本原则是根据查询的要求创建索引，并使用EXPLAIN命令验证其使用。
每个数据库优化器都不同，性能优化需要根据实际情况进行调整。

如果您的数据库表很小，您可能不需要立即创建索引。
可以使用OPTIMIZETABLE等命令来优化现有表。
总之，索引的创建和使用应该根据具体的查询需求和性能来决定。

扩展信息

索引是一种对数据库表中一个或多个列的值进行排序的结构。
索引可用于快速访问数据库表中的特定信息。

mysql创建索引的原则

1.选择唯一索引。
唯一索引的值是唯一的，通过索引可以更快地确定一条记录。
例如，学生表中的中学ID就是一个唯一字段。
对该字段建立唯一索引，可以快速确定某个学生的信息。
如果使用名字，可能会出现重名的情况，会减慢查询速度。
2、为经常需要排序、分组、联合操作的字段创建索引，往往需要进行ORDERBY、GROUPBY、DISTINCT、UNION等操作。
排序操作会浪费很多时间。
如果对其建立索引，就可以有效避免排序操作。
3．为经常作为查询条件的字段创建索引。
如果某个字段经常作为查询条件，则该字段的查询速度会影响整个表的查询速度。
因此，对此类字段建立索引可以提高整个表的查询速度。
4．限制索引的数量。
索引越多越好。
每个索引都需要磁盘空间。
索引越多，需要的磁盘空间就越多。
当表修改时，重建和更新索引很麻烦。
索引越多，更新表就越耗时。
5、尽量使用数据量小的索引。
如果索引值很长，查询速度就会受到影响。
例如，对CHAR(100)类型字段进行全文搜索肯定会比CHAR(10)类型字段花费更多时间。
6.尝试使用前缀来索引。
如果索引字段的值很长，最好使用值的前缀来索引。
例如，对TEXT和BLOG类型字段进行全文搜索会浪费时间。
如果只检索字段的前几个字符，可以提高检索速度。
7．删除不再使用或很少使用的索引。
当表中的数据被大量更新，或者数据的使用方式发生改变后，原有的一些索引可能不再需要。
数据库管理员应该定期识别这些索引并删除它们，以减少索引对更新操作的影响。
8、最左前缀匹配原则是一个非常重要的原则。
mysql会一直向右匹配，直到遇到范围查询（>、<、Between、like）并停止匹配。
例如a1=""and=""b="2"c="">3andd=4如果建立了(a,b,c,d)索引，则不使用d进行索引。
如果创建了(a,b,d,c)的索引，就可以使用。
a、b、d的顺序可以任意调整。
9.=和in可能会乱序。
例如a=1andb=2andc=3可以以任意顺序创建(a,b,c)索引，MySQL查询优化器会帮你优化成索引可以识别的形式。
10、尽量选择区分度高的列作为索引。
区分的公式为count(distinctcol)/count(*)，表示不重复字段的比例。
比率越大，我们扫描的记录就越少。
唯一键区分度为1，有些状态、性别字段可能数量较多。
数据前面的歧视度为0，那么有人可能会问，这个比例有什么经验价值吗？不同的使用场景使得这个值很难确定。
一般我们要求需要join的字段在0.1以上，即平均每次扫描10条记录。
11.索引列不能参与计算，所以要保持列“干净”。
例如，from_unixtime(create_time)='2014-05-29'不能使用索引。
原因很简单。
b+树存储数据表中的字段值，但检索时需要对所有元素应用函数。
相比之下，成本显然太高了。
因此，该语句应写为create_time=unix_timestamp('2014-05-29');12、尽可能扩展索引，不要创建新索引。
例如，表中已有a的索引，现在要添加a的索引索引为(a,b)，那么只需要修改原来的索引即可。
注意：选择索引的最终目的是为了让查询更快。
上面给出的原则是最基本的指导方针，但你不能拘泥于上述指导方针。
读者应在今后的学习和工作中继续实践。
根据应用的实际情况进行分析判断，选择最合适的索引方法。