【数据库索引和空间索引】知识点和相关资料总结

数据库索引

1. MySQL是基于磁盘的数据库，索引是以索引文件的形式存在于磁盘中的，索引的查找过程就会涉及到磁盘IO消耗。磁盘IO的消耗相比较于内存IO的消耗要高好几个数量级，所以索引的组织结构要设计得在查找关键字时要尽量减少磁盘IO的次数。为什么要使用B/B+树，跟磁盘的存储原理有关。
2. 索引是数据库中一个用于排序的数据结构，用来快速查询数据库中的数据。MySQL数据库使用B+树来实现索引的。B+树的特点就是叶子节点包含了所有的关键字信息和data数据，非叶子节点只包含子节点的最大或者最小关键字，用来实现索引。
3. 建索引的优缺点：
   优点：大大加快对数据的查询速度
   缺点：占物理空间，对数据库进行增删改的时候也要动态的维护索引。
4. 相关链接：
   以B tree和B+ tree的区别来分析mysql索引实现
   数据库索引详细介绍

空间索引

1. 空间索引可划分为两大类：1）基于哈希思想，如网格索引等；2）基于树思想，有四叉树、R树等。
2. 相关资料：GIS空间索引技术

1、B-tree

1. B-tree是为磁盘等外存储设备设计的一种平衡查找树

2. B-tree主要用来存放一维排序的数据元素

3. 更擅长于数据点查，它的设计并不利于数据的范围查询

4. B-tree相对于AVL树缩减了节点个数，在每次磁盘I/O取到内存的数据时都发挥了作用，从而提高了查询效率。

5. 图示：

6. 相关链接讲得是真好：Btree-----数据库相关

2、B+ tree

1. B+ tree是在B-tree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用B+ tree实现其索引结构。
2. B-tree的每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。在B+ tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+ tree的高度。
3. 通常在B+ tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对B+ tree进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。
4. 在数据库中，B+Tree的高度一般都在2-4层。mysql的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。
5. 相比于B-tree，B+ tree的读写代价更低，查询效率更加稳定。
6. B+ tree更适合外部存储（一般指磁盘存储），由于内节点（非叶子节点）不存储data，所以一个节点可以存储更多的内节点，每个节点能索引的范围更大更精确。也就是说使用B+ tree单次磁盘IO的信息量相比较B-tree更大，IO效率更高。
7. MySQL是关系型数据库，经常会按照区间来访问某个索引列，B+ tree的叶子节点间按顺序建立了链指针，加强了区间访问性，所以B+ tree对索引列上的区间范围查询很友好。而B-tree每个节点的key和data在一起，无法进行区间查找。
8. B+树可以保证等值和范围查询的快速查找
9. 图示：
10. 相关链接：
    Btree-----数据库相关
    以B tree和B+ tree的区别来分析mysql索引实现
    一文搞懂MySQL索引所有知识点（建议收藏）

3、R-tree

1. R-tree存放的是多维空间数据元素
2. R树就是一棵用来存储高维数据的平衡树
3. 二维：MBR(Minimum Bounding Rectangle)
   三维：MBB(Minimum Bounding Box)
4. 用地图的例子来解释，就是所有的数据都是餐厅所对应的地点，先把相邻的餐厅划分到同一块区域，划分好所有餐厅之后，再把邻近的区域划分到更大的区域，划分完毕后再次进行更高层次的划分，直到划分到只剩下两个最大的区域为止。要查找的时候就方便了。
5. 假设我们有一个地图路网要进行道路的快速索引，那么我们可以将每一条路的最小MBB作为R树的数据单元来进行构建R树。每一条路使用一个最小MBB来进行包裹，使它成为R树的叶子结点.
6. R树很好理解，但是具体操作好复杂，想具体了解就看链接吧……
7. 相关链接：空间数据索引RTree完全解析

4、网格索引

1. 对地理空间进行网格划分，划分成大小相同的网格，每个网格对应着一块存储空间，索引项登记上落入该网格的空间对象。
2. 举个例子，我们将地理空间进行网格划分，并进行编号。该空间范围内有三个空间对象，分别是id=5的街道，23的河流和11的商圈。这时候我们可以按照哈希的数据结构存储，每个网格对应着一个存储桶，而桶里放着空间对象，比如对2号网格，里面存储着id=5的空间对象，对35号网格，桶里放着id=5和id=23的空间对象。
3. 缺点：
   1）索引数据冗余
   网格与对象之间多对多关系在空间对象数量多、大小不均时造成索引数据冗余。比如11号商圈这个空间对象在68，69，100，101这4个网格都有存储，浪费了大量空间。
   2）网格的大小难以确定
   网格的划分大小难以确定。网格划分得越密，需要的存储空间越多，网格划分的越粗，查找效率可能会降低。对于图a，这个查询需要查询4个网格，由于4个网格覆盖了整个空间，因此这个查找其实是将空间范围内所有的点数据都遍历一遍，失去了索引的意义。
   3）很多网格没有数据
   空间数据具有明显的聚集性，比如POI只在几个热点商贸区聚集，在郊区等地方很稀疏，这将导致很多网格内没有任何空间数据。
4. 相关链接：
   空间索引–网格索引

5、KD-tree

1. KD-tree（k-dimensional树的简称），是一种对k维空间中的实例点进行存储以便对其进行快速检索的树形数据结构。主要应用于多维空间关键数据的搜索（如：范围搜索和最近邻搜索）。K-D树是二进制空间分割树的特殊的情况。
2. 好难这个……

6、倒排索引

1. 倒排索引理解起来很简单。比方说数据库里好多文档，你现在要找出所有包含“进程与线程”这个字符串的文档，那你一个文档一个文档扫描，时间开销必然是巨大的！那肿么办呢？我们可以根据你要搜索的关键字建一个索引！比如以“进程与线程”为索引键，它对应的就是包含“进程与线程”这个字符串的所有文章的id。当你查找“进程与线程”时，数据库会直接根据你这个索引找到所有文档的id，然后根据id找到文档返回给你。这样就快很多倍。
2. 那么问题来了，如何建倒排索引呢？你怎么知道把哪些关键字作为索引呢？我也不知道。按个人感觉来看，这要视具体情况而定吧。

7、Z-order curve

1. 相关链接：多维空间点索引算法概述

8、Hilbert curve

1. Hilbert曲线以及其离散近似表示方法都非常实用，因为其将多维空间转换为一维空间的方法很好地保留了空间邻近性。(x, y)是一个单元方格中的点，d代表该点在Hilbert曲线上的位置，而由于其空间的邻近性，在单元格上近似的点，其对应Hilbert的d值也比较接近。
2. 正因为这种邻近性，空间填充曲线被广泛用于计算机科学，且在多维数据库索引中，经常用Hilbert曲线取代Z order曲线。
3. 相关链接：
   多维空间点索引算法概述
   HILBERT曲线介绍以及代码实现