B+Tree

前言 很抱歉现在才把这篇文章发出来，这几天事情比较多，周四把任务完成才得空写一写，闲话不多说请看下↓↓↓ 详细需求 需求： 系统中有一个专门存车流量的库（没有主键），其中一个历史表数据量太大，表空间占据太大，每天有500w的数据写入，然后老大给我安排了个任务，让我写个按天分表的定时任务，每次把一天的数据转移到按天生成的表中，并删除原表中的数据，主要目的是不想再增长表空间了，保持一个平衡，因为每天删500w也会加500w 表空间和数据量： 实现思路 我本人实现的做法流程，如图 实现伪代码（删减了部分代码）： /** * 转移数据 每天凌晨3点 每次只能转移一天的数据 */ @Scheduled ( cron = "0 0 3 * * ?" ) public void dataTransfer ( ) throws Exception { System . out . println ( "定时器开始运行------------------------------------------" ) ; String tabaleName = "XXX" ; String isTable = getTableName ( tabaleName ) ; // 当返回为空时,代表该表不存在,则创建 if ( ObjectUtils . isNull ( isTable ) ) {

1. 说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解？ InnoDB 引擎： InnoDB 引擎提供了对数据库 acid 事务的支持，并且还提供了行级锁和外键的约束，它的设计的目标就是处理大数据容量的数据库系统。MySQL 运行的时候，InnoDB 会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎是不支持全文搜索，同时启动也比较的慢，它是不会保存表的行数的，所以当进行 select count() from table 指令的时候，需要进行扫描全表。由于锁的粒度小，写操作是不会锁定全表的,所以在并发度较高的场景下使用会提升效率的。 MyIASM 引擎： MySQL 的默认引擎，但不提供事务的支持，也不支持行级锁和外键。因此当执行插入和更新语句时，即执行写操作的时候需要锁定这个表，所以会导致效率会降低。不过和 InnoDB 不同的是，MyIASM 引擎是保存了表的行数，于是当进行 select count() from table 语句时，可以直接的读取已经保存的值而不需要进行扫描全表。所以，如果表的读操作远远多于写操作时，并且不需要事务的支持的，可以将 MyIASM 作为数据库引擎的首选。 2. 谈谈你对MySQL索引的理解？ MySQL索引使用的数据结构主要有BTree索引 和 哈希索引 。对于哈希索引来说，底层的数据结构就是哈希表

四、索引 ❝ 说说你对 MySQL 索引的理解？ 数据库索引的原理，为什么要用 B+树，为什么不用二叉树？ 聚集索引与非聚集索引的区别？ InnoDB引擎中的索引策略，了解过吗？ 创建索引的方式有哪些？ 聚簇索引/非聚簇索引，mysql索引底层实现，为什么不用B-tree，为什么不用hash，叶子结点存放的是数据还是指向数据的内存地址，使用索引需要注意的几个地方？ MYSQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构，所以说 索引的本质是：数据结构 索引的目的在于提高查询效率，可以类比字典、 火车站的车次表、图书的目录等 。 可以简单的理解为“排好序的快速查找数据结构”，数据本身之外， 数据库还维护者一个满足特定查找算法的数据结构 ，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。下图是一种可能的索引方式示例。 左边的数据表，一共有两列七条记录，最左边的是数据记录的物理地址。 为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值，和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到对应的数据，从而快速检索出符合条件的记录。 索引本身也很大，不可能全部存储在内存中， 一般以索引文件的形式存储在磁盘上 平常说的索引，没有特别指明的话

我记得之前博客我也写过关于索引使用的文章，但是并不全面，这次尽量针对重点铺全面一点。 因为索引是数据引擎层的结构我们只针对最常见使用的 Innodb 使用的 B+Tree 搜索树结构进行介绍。 每一个在 InnoDB 的中的索引都对应一颗 B+Tree。举个栗子： 创建这样一个表，并且在字段 k 上创建索引 mysql> create table T( id int primary key, k int not null, name varchar( 16 ), index (k))engine =InnoDB; 这个时候我们插入值 (100,1)、(200,2)、(300,3)、(500,5) 和 (600,6) 这个时候主键的聚簇索引对应一颗树，然后 k 索引值对应一棵树。 基于 Innodb 引擎的特性，一个表只能有一个聚簇索引，聚簇索引上面会记录所有表字段的有序的信息。普通二级索引上面只有该索引字段和主键索引字段的对应信息。（如果可以看得比较明确）。当我们使用语句 select * from xxx where k = x 的时候，我们使用了二级索引。并且由于在二级索引上面没有索引覆盖到 name 字段，所以我们需要在二级索引里面拿到 id = x 的值然后再去聚簇索引树中搜索对应的 name 记录。这个过程被称作回表。 在频繁查询大表特别是字段非常多的表的时候

前几天下班回到家后正在处理一个白天没解决的bug，厕所突然传来对象的声音： 对象：xx，你有《时间简史》吗？ 我：我去！妹子，你这啥癖好啊，我有时间也不会去捡屎啊！ 对象：...人家说的是霍金的科普著作《时间简史》，是一本书啦！ 我：哦，那我没有... 对象：人家想看诶，你明天帮我去图书馆借一本吧... 我：我明天还要改... 对象：你是不是不爱我了，分手！ 我：我一大早就去~   第二天一大早我就到了图书馆，刚进门就看到一个索引牌，标识着不同楼层的功能，这样我很快能定位到我要找的目标所在的楼层了。      我到楼上后又看到每排的书架上又对书的分类进行了细分，这样我能更快的定位到我要找的书具体在哪个书架！   并且每个楼层都有一台查询终端，输入书名就能查到对应的唯一标识“索书号”，类似于P159-49/164这样的一个编码，书架上的书都是按照这个编码进行排序的！有了这个编码再去对应的书架上，很快就能找到对应的书在书架的具体位置了。      不到十分钟，我就从图书馆借好书出来了。   这么大的图书馆，我为什么能在这么短的时间内找到我要的书？如果这些书是杂乱无章的堆放，或者没有任何标识的放在书架，我还能这么快的找到吗？   这不禁让我想到了我们开发中用到的数据库，图书馆的书就类似我们数据表中的数据，楼层索引牌、书架分类标识、索书号就类似我们查找数据的索引。  

数据库 以下是对面试常见面试题整理，来自知乎大神分享的pdf，引用部分链接已给出，如果有没有标注的，纯属意外，希望提醒。这篇主要整理出来给自己看的 B/B+树 B/B+ 一、B树： 定义：B 树又叫平衡多路查找树。一棵m阶的B 树 的特性如下： 树中每个结点最多含有m个孩子（m>=2）； 除根结点和叶子结点外，其它每个结点至少有[ceil(m / 2)]个孩子（其中ceil(x)是一个取上限的函数）； 若根结点不是叶子结点，则至少有2个孩子（特殊情况：没有孩子的根结点，即根结点为叶子结点，整棵树只有一个根节点）； 所有叶子结点都出现在同一层， 叶子结点不包含任何关键字信息 每个非终端结点中包含有n个关键字信息： (n，P0，K1，P1，K2，P2，......，Kn，Pn)。其中： Ki (i=1...n)为关键字，且关键字按顺序升序排序K(i-1)< Ki Pi为指向子树根的接点，且指针P(i-1)指向子树种所有结点的关键字均小于Ki，但都大于K(i-1)。 关键字的个数n必须满足： [ceil(m / 2)-1]<= n <= m-1。如下图所示： B树中的每个结点根据实际情况可以包含大量的关键字信息和分支(当然是不能超过磁盘块的大小，根据磁盘驱动(disk drives)的不同，一般块的大小在1k~4k左右)；这样树的深度降低了

前言: 目前XFS已成为Linux主流的文件系统，所以有必要了解下其数据结构和原理。 XFS文件系统 XFS是一个日志型的文件系统，能在断电以及操作系统崩溃的情况下保证数据的一致性。XFS最早是针对IRIX操作系统开发的，后来移植到linux上，目前CentOS 7已将XFS作为默认的文件系统。使用XFS已成为了潮流，所以很有必要了解下其数据结构和原理。 XFS官方说明文档参考： https://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html 接下来将介绍XFS的一些概念，包括分配组、超级块、inode等等，过程中会结合xfs_db（xfs提供的输出文件系统信息的工具）打印一些信息，了解当前XFS的实时数据。 分配组（Allocation Group） XFS将空间分为若干个分配组，每个分配组大小相等（最后一个可能不等）。分配组包含有超级块、inode管理和剩余空间管理等，所以分配组可以认为是一个单独的文件系统。正是分配组这样的设计，使得XFS拥有了并行IO的能力。在单个分区上使用XFS体现不了这种并行IO能力，但是如果文件系统跨越多个物理硬件比如ceph，并行IO将大大提高吞吐量利用率。 上图为分配组的结构图，重点关注前面4个扇区，从上到下分别为超级块、空闲块信息

点击上方 " 程序员小乐 "关注, 星标或置顶一起成长 每天凌晨00点00分, 第一时间与你相约 每日英文 A single hand that wipes tears during failures is much better than countless hands that come together to clap on success. 失败时有人伸出一只手来为你擦泪，会好过成功时无数人伸手为你鼓掌。 每日掏心 话 当看破一切的时候才知道，其实失去比拥有更踏实。 来自：NebulaGraph | 责编：乐乐 链接：my.oschina.net/u/4169309/blog/3216614 程序员小乐(ID:study_tech) 第 826 次推文 图片来自百度 往日回顾： Google 出品的 Java 编码规范，强烈推荐，权威又科学！ 正文 之前有过一次面试，关于MySQL索引的原理及使用被面试官怼的体无完肤，立志要总结一番，然后一直没有时间（其实是懒……），准备好了吗？ 索引是什么？ 数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，它可以对数据库表中一列或多列的值进行排序，以协助更加快速的访问数据库表中特定的数据。通俗的说，我们可以把数据库索引比做是一本书前面的目录，它能加快数据库的查询速度。 为什么需要索引？ 思考：如何在一个图书馆中找到一本书

作者：是虎子呀 https://my.oschina.net/u/4062805/blog/3216265 之前有过一次面试，关于MySQL索引的原理及使用被面试官怼的体无完肤，立志要总结一番，然后一直没有时间（其实是懒……），准备好了吗？ 索引是什么？ 数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，它可以对数据库表中一列或多列的值进行排序，以协助更加快速的访问数据库表中特定的数据。通俗的说，我们可以把数据库索引比做是一本书前面的目录，它能加快数据库的查询速度。 为什么需要索引？ 思考：如何在一个图书馆中找到一本书？设想一下，假如在图书馆中没有其他辅助手段，只能一条道走到黑，一本书一本书的找，经过3个小时的连续查找，终于找到了你需要看的那本书，但此时天都黑了。 为了避免这样的事情，每个图书馆才都配备了一套图书馆管理系统，大家要找书籍的话，先在系统上查找到书籍所在的房屋编号、图书架编号还有书在图书架几层的那个方位，然后就可以直接大摇大摆的去取书了，就可以很快速的找到我们所需要的书籍。索引就是这个原理，它可以帮助我们快速的检索数据。 一般的应用系统对数据库的操作，遇到最多、最容易出问题是一些复杂的查询操作，当数据库中数据量很大时，查找数据就会变得很慢，这样就很影响整个应用系统的效率，我们就可以使用索引来提高数据库的查询效率。 B-Tree和B+Tree

前言: 目前XFS已成为Linux主流的文件系统，所以有必要了解下其数据结构和原理。 XFS文件系统 XFS是一个日志型的文件系统，能在断电以及操作系统崩溃的情况下保证数据的一致性。XFS最早是针对IRIX操作系统开发的，后来移植到linux上，目前CentOS 7已将XFS作为默认的文件系统。使用XFS已成为了潮流，所以很有必要了解下其数据结构和原理。 XFS官方说明文档参考：https://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html 接下来将介绍XFS的一些概念，包括分配组、超级块、inode等等，过程中会结合xfs_db（xfs提供的输出文件系统信息的工具）打印一些信息，了解当前XFS的实时数据。 分配组（Allocation Group） XFS将空间分为若干个分配组，每个分配组大小相等（最后一个可能不等）。分配组包含有超级块、inode管理和剩余空间管理等，所以分配组可以认为是一个单独的文件系统。正是分配组这样的设计，使得XFS拥有了并行IO的能力。在单个分区上使用XFS体现不了这种并行IO能力，但是如果文件系统跨越多个物理硬件比如ceph，并行IO将大大提高吞吐量利用率。 上图为分配组的结构图，重点关注前面4个扇区，从上到下分别为超级块、空闲块信息