SQL数据库索引的原则和优势
索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com/3358 www.Sina.com.Sina.com/http://ww.Sina.com
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com/3358 www.Sina.com.Sina.com/http://ww.Sina.com
http://www.Sina.com/http://www.Sina.com /
合并索引根据数据行的键值对表中的数据行进行排序和存储。 每个表只有一个聚集索引。 数据行的分支只能按一个顺序存储。 在聚合索引中，表中每行的物理顺序与索引关键字的逻辑(索引)顺序相同。 聚合索引通常会加速UPDATE和DELETE操作，因为需要读取大量数据。 创建或修改聚合索引可能需要一些时间。 这是因为在执行这些操作时在磁盘上重新组织表中的行。
优点
由于一个表只能创建一个聚集索引，因此如果需要在表中创建多个索引，则可以创建非聚集索引。 表中的数据不以非聚集索引列的顺序存储，但非聚集索引的索引行存储非聚集键值和行定位符，以便根据非聚集键值快速找到记录的存储位置。 非聚集索引本质上也是聚集索引的一种。 虽然非聚集索引以额外方式生成聚集索引的b树结构，而不是改变该表的物理结构，但是叶节点是对该表的参考，该参考分为两种，如果该表没有聚集索引，则参考行号。 如果表中已经有聚集索引，请浏览“聚集索引”页。
通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。对于小表，未编制索引的数据量较少的表的表扫描成本不高。 不要设置太多的索引。 没有聚合索引的表最多可以有249个非聚合索引。 如果索引过多，首先磁盘空间会变大，在数据发生更改时维护索引会特别消耗性能。 可以适当地应用复合索引，或者在某些情况下考虑创建包括所有输出列的复盖索引。 对于经常使用范围查询的字段，也可以考虑聚合索引。 不要在不常用的列、逻辑列或大型字段列上创建索引。
通过对需要频繁搜索的列编制索引，可以缩短搜索时间。 作为主键的列中，连接中常用的列主要具有外键，用于强制该列的唯一性和组织表中数据的数组结构，从而可以加速连接。 经常在需要根据范围搜索的列上创建索引。 因为索引已经排序，指定的范围是连续的。 在需要频繁排序的列上创建索引。 由于已经对索引进行了排序，因此查询可以利用索引排序来减少查询排序时间。 通过在WHERE子句中的列之上创建索引来加速条件的确定。
避免索引请不要在查询中很少使用或引用的列上创建索引。 这是因为这些列很少使用，而且有索引或没有索引都不会提高查询的速度。 相反，由于索引增加，系统维护速度降低，空间要求增加。 对于数据值少的列，也不应该增加索引。 这是因为这些列的可取值很少，如人力资源表中的性别列。 在查询结果中，结果集中的数据行占表中数据行的很大一部分。 这意味着需要在表中查找的数据行的比例很大。 添加索引不会大幅提高搜索速度。 不要将image和bit数据类型的索引添加到定义为text的列中。 这是因为这些列的数据量相当多或值很少。 如果修复的性能远大于搜索的性能，请不要创建索引。 这是因为修正性能和检索性能矛盾。 增加索引会提高搜索性能，但会降低修改性能。 减少索引会提高修改性能，降低搜索性能。 因此，如果修复的性能远大于搜索的性能，请不要创建索引。
索引算法可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
BTree (多重搜索树
不是二叉的）是一种常见的数据结构。使用BTree结构可以显著减少定位记录时所经历的中间过程，从而加快存取速度。按照翻译，B 通常认为是Balance的简称。这个数据结构一般用于数据库的索引，综合效率较高。逻辑结构为一颗N叉平衡树，每列中distinct key 都对应一个 RIDs(Row IDentifiers)数组。树状结构适合频繁的更新操作，适用于事物型数据库。不适合场景
单列索引的列不能包含null的记录，复合索引的各个列不能包含同时为null的记录，否则会全表扫描；不适合键值较少的列（重复数据较多的列），即低基数情况，索引结构空间冗余，B-Tree树上会存在大量相同键值的叶子节点，造成严重的空间和I/O扫描浪费；N叉平衡树的结构会随着记录的增多而膨胀。单一索引路径选择问题，即SQL条件中包含多列时，即时每个列对应一个索引，在执行中也只能沿着一个索引的执行路径， 而其它列之能作为筛选条件。前导模糊查询不能利用索引(like '%XX'或者like '%XX%')Hash散列索引
Hash散列索引是根据HASH算法来构建的索引。虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。精确查找非常快（包括= <> 和in），其检索效率非常高，索引的检索可以一次定位，不像BTree 索引需要从根节点到枝节点，所以 Hash 索引的查询效率要远高于 B-Tree 索引。不适合场景
不适合模糊查询和范围查询（包括like，>，<，between……and等），由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样；不适合排序，数据库无法利用索引的数据来提升排序性能，同样是因为Hash值的大小不确定；复合索引不能利用部分索引字段查询，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。同样不适合键值较少的列（重复值较多的列）；Bitmap位图索引
就是用位图表示的索引，对列的每个键值建立一个位图，即每列中的distinct key都对应一bit序列。相对于BTree索引，占用的空间非常小，创建和使用非常快。位图索引由于只存储键值的起止Rowid和位图,占用的空间非常少。下图是位图索引的一个直观描述。其中，Identifier列是每一行的唯一标识，HasInternet是索引列，那么右侧的Bitmaps下方的两列Y和N则表示左侧所对应的bitmap索引。
适合决策支持系统，数据仓库，OLAP类分析场景，图数据库；当select count(XX) 时,可以直接访问索引中一个位图就快速得出统计数据；当根据键值做and，or或 in(x,y,..)查询时，直接用索引的位图进行或运算,快速得出结果行数据。利用计算机硬件对按位操作（AND/OR/XOR）的强有力的支持，从而使单列内部的按位操作可以有效的转化为按位逻辑操作。多列之间的结果聚合也可以有效的转化为按位逻辑操作。适合只读，较少更新或者追加的数据集上的查询操作。
不适合的场景
不适合键值较多的列（重复值较少的列）；不适合update、insert、delete频繁的列，代价很高。更新操作慢，由于更新操作的锁只能有单用户获取，并且需要同时锁住很多索引，故并发性能较差。转载来源：https://www.cnblogs.com/zuowj/p/3520509.html
参考来源：https://blog.csdn.net/u010265638/article/details/71191116
参考来源：https://blog.csdn.net/sanyaoxu_2/article/details/79026050