数据库版本：oracle12c
前几部分都是说的关于索引的理论，今天就主要来聊聊在日常使用过程中，我们该怎么使用这一工具的技巧（据说oracle19已经开始支持动态索引了，那么以后索引跟我有什么关系？）。
要谈索引的使用，那就得谈到表，因为索引是因为表才建立的，因为要更好的使用表，我们才用到了索引，万变不离其宗，都得先对表进行分析。所以第一步我们就得谈谈表的结构。
表的结构主要包括字段以及它自身的特性，关于自身的特性我们可以先忽略，前面也大概区分了一些不同的表类型的区别。这里主要聊聊字段，因为索引就是建立在几个字段之上的，建立索引的过程也就是选择字段并排序的过程。️而表的字段的根据是实际需求，他的长度，他的类型都属于业务程序强关联的一部分，虽然在数据库理论中有三大范式对表结构进行了约束，但也有反范式的设计来反这个范式，所以一般情况下，范式并不是很有用，范式只是减少了数据冗余和解偶，但并不关心在使用过程中多表查询带来的问题（范式鼓励拆表，这会导致任何一个sql都需要关联多张表使用，这反倒大大增加了数据库的负担和开发人员使用数据库数据的复杂度。又有人说可以使用外键，但也得考虑外键锁导致的死锁问题）。所以我们大多数的表，都是根据业务场景需求，做了部分解偶和组合后形成的。这样就大概说明了一张表的来源根据，而对于如何选择索引，也同样出现这样的问题，索引是因为使用了一些sql语句而产生的。所以我们最后就落到了，那张表哪个sql用了哪些字段，如何选择字段以及联合索引的先后顺序问题了。
说到表的时候，首先应该考虑的是表里面的数据分布，以及表字段长度，一个较小的字段且重复度较低的字段适合建立索引（重复度低主要是考虑他的查询结果都是少量数据，如果重复度高，返回大量数据，很有可能跟全表扫描没什么区别了）。从索引自身大小和高度考虑，以及从索引导致的回表读的数据量考虑，以及这个字段的使用频率上考虑。当某一个sql需要建立索引的时候，我们首先要做的是分析所有字段的分布情况，哪些字段重复度高，哪些字段重复度低，甚至可以分析到某个字段的某个值占比非常高（百分之90以上），如果在这个字段建立索引，同时使用那个值特别多，就可能出现oracle不踩你给它建立的索引的情况，因为确实它就相当于全表读，当然也并不是说它不适合建立索引，虽然这个字段占比百分之90但，另外我有10万个其他值分布均匀占比百分之10，当使用其他10万个值的一个的时候，效果依然明显的，甚至比一些重复度低但值范围较少的还高，因为它能够精确到数据列更少，这也是评估是否适合建立联合索引的一个标准（a字段返回较多，b字段返回较多，联合查询的时候返回更少，那就适合建立联合索引），也就是数据占比将是分析索引的第一步。当得到了sql使用的字段占比情况后，一般仍然不能直接决定哪些字段该做索引，就比如这个字段特别大，无序，使用场景少（关键因素）等等，都可能本来从分布的情况来说它应该是索引，但综合考虑下来，他可能并不是最适合的选择。应该需要更多的参考因素才对，特别要考虑的是业务需求（比如某些场景下他慢点无所谓，某些场景就要快点），根据涉及的使用场景来联合分析，这是第二步。这一步主要的工作就是分析所有关于这个表的sql语句，以及他的使用频率，使用的字段，以及他是范围查询还是精确查询等等，列成一个表，整体分析字段，对于要求快的sql语句则可以使用第一步分析占比，同样得出一些备选的字段。当前两部分做完之后，第三步就是尝试了，毕竟行不行跑一哈才知道，对于单键索引，如果场景分析和数据分析得当，它也就基本能够确定。但对于联合索引，主要是如何组合和顺序的问题，哪些字段适合组合起来，哪些字段又适合单独建立索引然后多个索引同时查，以及他们的先后顺序的问题，这个时候就要靠尝试了。当然也有一些经验，就是如果sql允许的情况下，经常范围查询的字段放到后面，精确的放前面（实际上我们如果能够精确查询的时候，就很少用范围查询了，主要看场景），更深入一点就是，相对来说返回更少记录的字段放在前面，返回更多记录的字段放到后面。另外一个规则就是不为空的放在前面，可为空的尽量放到后面，使用度较高的放在前面，使用度较低的放到后面。另外一个经验就是重复度较高的放到前面（这样看起来返回的列更多了，不符合前面说的返回更少的放到前面的规则），重复度低的放到后面，这样做的目的可能是为了如果第一列不出现在sql里面的时候，oracle可能会尝试用跳表查询。
巴掌大的一坨，没有拆分开，抱歉。
网友评论