BTree

转自：http://forchenyun.iteye.com/blog/942448 相关文章推荐： 海量数据存储之Key-Value存储简介 海里数据存储之存储设计(二) Je的排版真的让人难过...... 从本文开始着重讲解存储细节，思路比较飘逸，观者多包涵。 翻译了一篇Redis作者antirez的 文章 做为本文的切入点，翻译得不好，这部分可以大致一览，后面会有分析。 Append Only和Reuse Blocks的一些区别 对于一颗append only btree(以下简称AOB)来说，最有趣的属性就是它不可能出现corrupt（可以理解为数据不一致状态）。另外一个有趣的属性就是并发访问没有任何问题，因为无论你访问根节点或其它节点，它们总是一致的(Valid)。 但是有一点我不喜欢的，AOB需要一个额外的Compaction(压缩)进程，否则文件会越来越大。如果你的访问需求是绝大部分是读，那么这样是没问题的。但如果你有非常多的写需求，那么问题就来了。 试想一下：如果你的写请求非常大，已经到了磁盘IO的极限，此时你的AOB文件会越来越大，你需要Compaction。但是你已经达到了IO瓶颈，这时你是重新开一个文件还是重写这棵树呢？这些额外的IO将会影响到这棵btree的性能。你能先降低写请求来降低这种冲撞吗？很遗憾不能，另外

1.性能下降SQL慢 执行时间长 等待时间长 查询语句写的烂 索引失效(单值，复合) 关联查询太多join(设计缺陷或不得已的需求) 服务器调优及各个参数设置(缓冲\线程数等) 2.常见通用的join查询 2.1SQL执行顺序 2.1.1手写 2.1.2机读 2.1.3总结 2.2Join图 2.3建表SQL 2.4 7种Join 3.索引简介 3.1什么是索引 MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。 可以得到索引的本质： 索引是数据结构 可以简单理解为"排好序的快速查找数据结构"。 详解(重要): 结论： 数据本身之外,数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法,这种数据结构就是索引。 一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以文件形式存储在硬盘上. 我们平时所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉树)结构组织的索引。 其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然,除了B+树这种类型的索引之外，还有哈希索引(hash index)等。 3.2索引优势 类似大学图书馆建书目索引，提高数据检索效率，降低数据库的IO成本 通过索引列对数据进行排序

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言：在2019年的年末，我又再一次的踏上了面试的漫漫征途。每次的面试准备都是对自己学习的一次积累。目前已经尘埃落定，将自己面试准备的东西做一次整理。 面试准备时长：1.5个月 mysql基本上每次面试都会问道，对于工作四年的开发人员来说，需要准备的知识也非常多。 一、事务隔离级别 read uncommied :即便事务没有commit，但是我们仍然能够读到未提交的数据，这是所有隔离级别中最低的一种 read commited ：可以读取其他事务提交的数据，这也是大多数数据库默认的隔离级别 repeatable read ：可重读 --mysql的默认隔离级别 serializable ：串行化，将当前会话的隔离级别设置为serilizable时，其他会话对该表的写操作将会被挂起。这样做对性能会造成影响。 二、索引 索引的本质 官方定义为：索引（index）是帮助mysql高效获取数据的数据结构。 B-Tree和B+Tree b-tree 的示意图如下所示： btree索引的每个节点中不仅包含数据的key值，还有data值。而每一页的存储空间是有限的，如果data数据较大时，会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时，同样会导致B-tree的深度较大，增大查询时的磁盘I/O次数

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 为什么不是B-Tree或者红黑树呢 为什么不是B-Tree 1.减少IO次数 磁盘每次IO读取出的数据量大小是一致的，当单次IO查询出的内容越多，那么查询的IO次数就越少，性能就越好。 而B-Tree因为其根节点存放的有指针，所以自然其内存消耗多，同等数据体量下IO次数也要比B+Tree多。 2.基于范围查询性能考虑。 因为B+Tree只有叶子节点才存放指针，叶子上有优化，所有的叶子节点可以通过指针串联起来，方便基于范围查询的频繁访问。 3.最主要的还是因为B+Tree的遍历效率高。 为什么不是红黑树之类的 大量数据下，红黑树他们因为深度过大，而造成的IO读写过于频繁，不适合检索。 B-Tree B+Tree 来源： oschina 链接： https://my.oschina.net/fusublog/blog/3154709

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Elasticsearch中的字段类型可以分为两类：精确值和全文。 精确值 如它们听起来那样精确。例如日期或者用户 ID，但字符串也可以表示精确值，例如用户名或邮箱地址。对于精确值来讲，Foo 和 foo 是不同的，2014 和 2014-09-15 也是不同的。另一方面， 全文 是指文本数据（通常以人类容易识别的语言书写），例如一个推文的内容或一封邮件的内容。 精确值很容易查询。结果是二进制的：要么匹配查询，要么不匹配。查询全文数据要微妙的多。我们问的不只是“这个文档匹配查询吗”，而是“该文档匹配查询的程度有多大？”换句话说，该文档与给定查询的相关性如何？为了促进这类在全文域中的查询，Elasticsearch 首先 分析 文档，之后根据结果创建 倒排索引 ，分析然后建立索引是ES处理文档的方式。 倒排索引 Elasticsearch 使用一种称为 倒排索引 的结构，它适用于快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。ES会为每个字段建立一个倒排索引，每个倒排索引最基本的结构就是“keyword”和“Posting List”，Posting list就是一个int的数组，存储了所有符合某个term的文档id。 另外

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> BTree.java package btree; /** * description: * * @author: dawn.he QQ: 905845006 * @email: dawn.he@cloudwise.com * @email: 905845006@qq.com * @date: 2019/12/12 12:03 AM */ import java.util.ArrayDeque; import java.util.LinkedList; import java.util.Queue; /** * @author Herry * * @param <K> * @param <V> */ public class BTree<K extends Comparable<K>, V> { private BTNode<K, V> mRoot = null; private long mSize = 0l; /** * @return */ public BTNode<K, V> getRootNode() { return mRoot; } /** * @return */ public long size() { return mSize; } /** * */ public void clear()

  hash索引的特点是检索效率非常高，检索一次就可以定位，BTree需要从根节点往下查找，经过多次IO访问才能找到结果，所以hash索引的效率远高于BTree。 但hash自身也有很多局限与缺陷： 1.hash只能通过索引精准定位目标，而不能进行范围查询。 2.因为hash只保存了经过hash计算之后的hash值和对应的行指针，所以无法用于排序。 3.hash索引如果遇到大量hash值相等的情况，那么大量的记录指针信息会存于同一个hash值上，这样要定位一条记录时就会很麻烦，最终效率不一定会比BTree索引高。 4.对于组合索引，hash索引会把组合索引合并一起后再计算hash值，而不是各自单独计算hash值，所以通过组合索引前面几个索引键值时，hash索引无法使用。 5.因为不同索引键有可能存在相同的hash值，所以hash索引任何时候都不能避免全表扫描。 BTree又叫平衡多路查找树。一棵m阶的B 树 (m叉树)的特性如下： 1.树中每个结点最多含有m个孩子（m>=2）； 2.除根结点和叶子结点外，其它每个结点至少有[ceil(m / 2)]个孩子（其中ceil(x)是一个取上限的函数）； 3.若根结点不是叶子结点，则至少有2个孩子（特殊情况：没有孩子的根结点，即根结点为叶子结点，整棵树只有一个根节点）； 4.所有叶子结点都出现在同一层，叶子结点不包含任何关键字信息 5.

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：Yves Trudeau 翻译：管长龙 Yves 是 Percona 的首席架构师，专门研究分布式技术，例如 MySQL Cluster，Pacemaker 和 XtraDB cluster。 他以前是 MySQL 和 Sun 的高级顾问。拥有实验物理学博士学位。 原文链接： https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/ 如果你在网上快速的做一个关于 UUID 和 MySQL 的搜索，你会得到相当多的结果。以下是一些例子： 存储 UUID 和 生成列 在 MySQL 中存储 UUID 的值 说明 InnoDB 中的主键模型及其对磁盘使用的影响 主键选型之战 UUID vs. INT GUID / UUID 的性能突破 到底需不需要 UUID? 另：以上文章链接请在文章结尾处查看 那么，像这样一个众所周知的话题还需要更多关注吗？显然是的。 尽管大多数帖子都警告人们不要使用 UUID，但它们仍然非常受欢迎。这种受欢迎的原因是，这些值可以很容易地由远程设备生成，并且冲突的概率非常低。这篇文章，目标是总结其他人已经写过的东西，并希望能带来一些新的想法。 UUID 是什么

作者：Yves Trudeau 翻译：管长龙 前言 作为 Percona 的首席架构师，我的主要职责之一是对客户的数据库进行性能方面的优化，这使得工作复杂且非常有趣。在这篇文章中，我想讨论一个最重要的问题： 选择最佳的 InnoDB 主键 。 InnoDB 主键有什么特别之处？ InnoDB 被称为索引组织型的存储引擎。主键使用的 B-Tree 来存储数据，即表行。这意味着 InnoDB 必须使用主键 。如果表没有主键，InnoDB 会向表中添加一个隐藏的自动递增的 6 字节计数器，并使用该隐藏计数器作为主键。InnoDB 的隐藏主键存在一些问题。您应该始终在表上定义显式主键，并通过主键值访问所有 InnoDB 行。 InnoDB 的二级索引也是一个B-Tree。搜索关键字由索引列组成，存储的值是匹配行的主键。通过二级索引进行搜索通常会导致主键的隐式搜索。 什么是 B-Tree？ 一个 B-Tree 是一种针对在块设备上优化操作的数据结构。块设备或磁盘有相当重要的数据访问延迟，尤其是机械硬盘。在随机位置检索单个字节并不比检索更大的数据花费的时间更少。这是 B-Tree 的基本原理，InnoDB 使用的数据页为 16KB。 让我们尝试简化 B-Tree 的描述。B-Tree 是围绕这键来组织的数据结构。键用于搜索 B-Tree 内的数据。B-Tree 通常有多个级别

写于2018-04-26 索引及数据库高性能基础 作为最核心的内功知识，也是面试中我对应聘者的重点考察项之一。迄今为止，在这方面能让我完全满意的应聘者寥寥无几。 注意： 这里介绍的技能对Mysql、SqlServer、Oracle等关系型数据库基本通用，比较而言，Mysql索引机制更加简单，为了排除更高级的数据库特性带来的复杂性，本文采用Mysql作为性能分析案例。 另外 Mysql常见的存储引擎：MyISAM、InnoDB，实际项目中极少采用MyISAM，大多采用InnoDB。 InnoDB的索引类型：BTREE、HASH，实际项目中很少使用HASH索引，基本都采用BTREE 故采用InnoDB和BTREE作为案例分析更具有普遍性。以下介绍的基础知识可能随着Mysql的版本发展会有少许变化。 I 关于索引 数据准备 建测试表： CREATE TABLE `user_info` ( `user_id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL, `age` int(18) NOT NULL, PRIMARY KEY (`user_id`) ) ENGINE=InnoDB AUTO_INCREMENT=10000001 DEFAULT CHARSET=utf8 生成测试数据： public