BTree

Btree Btree是一种多路自平衡搜索树，它类似普通的二叉树，但是Btree允许每个节点有更多的子节点。Btree示意图如下： 由上图可知 Btree 的一些特点: 所有键值分布在整个树中 任何关键字出现且只出现在一个节点中 搜索有可能在非叶子节点结束 在关键字全集内做一次查找，性能逼近二分查找算法 B+tree B+树是B树的变体，也是一种多路平衡查找树，B+树的示意图为： 由图可看出B+tree的特点 同时也是 Btree 和 B+tree的区别 所有关键字存储在叶子节点，非叶子节点不存储真正的data 为所有叶子节点增加了一个链指针 参考原址-(写的非常好) Btree/B+tree区别 1、B+tree的所有关键字存储在叶子节点，非叶子节点不存储真正的data。 ​ 2、B+tree为所有叶子节点增加了一个链指针。 ​ 3、B+tree支持叶子节点的延展性（横向性） ​ 4、B+tree可以向下开始分叉 来源： CSDN 作者： Hanmin_hm 链接： https://blog.csdn.net/Hanmin_hm/article/details/104572959

SQL优化的思路： 1.优化更需要优化的sql； 2.定位优化对象的性能瓶颈：优化前需了解查询的瓶颈是IO还是CPU，可通过PROFILING很容易定位查询的瓶颈。 3.明确优化目标； 4.从Explain入手； 5.多使用profile； SQL优化的基本原则： 1.永远用小结果集驱动大结果集； From子句中sql解析顺序为从右向左，执行时会以最左边的表为基础表循环与右边表数据做笛卡尔积，所以以小结果集驱动能减少循环次数，从而减少对被驱动结果集的访问，从而减少被驱动表的锁定。 2.尽可能在索引中完成排序； 排序算法有两种：a.查出排序字段和行指针，排序，再通过行指针获得行数据所需列，返回结果集；b.取出所有排序列数据，在排序缓冲区中排完序直接返回结果集。 索引排序是利用索引的有序性对数据排序的。 3.只取出子集需要的colums 4.仅仅使用最有效的过滤条件； 5.尽可能避免复杂的Join和子查询； 索引的好处： （1）.提高数据检索效率，降低数据库的IO成本。 （2）.降低数据排序成本：要求排序字段和索引键字段一致。 （3）.降低数据分组成本：因为分组之前会先排序，同意如果分组字段与索引字段一致，会降低分组消耗的成本。 索引的弊端： （1）.索引是独立于基础数据的数据库对象，因此它会占用存储空间。 （2）.数据新增、更新会导致索引的同步更新，所以会增加数据新增

索引的物理存储 与B-Tree相比，B+Tree有以下不同点： 非叶子结点的子树指针与关键字个数相同； 非叶子结点的子树指针P[i]，指向关键字值属于[K[i], K[i+1])的子树（B-树是开区间）； 为所有叶子结点增加一个链指针； 所有关键字都在叶子结点出现； 内节点不存储data，只存储key 如：（M=3） 为什么B+Tree更适合做文件索引 因为B+ Tree的内部节点并没有指向关键字具体信息的指针，所以他的内部节点比其他结构的更小，同样大小的盘块能够容纳更多的单位索引结构，一次性读入内存的关键字信息索引就更多，相对来说IO读写次数也就少很多 。 为什么不用AVL数或者红黑树做索引 这个问题回答之前，我们往往评价程序、数据结构、算法的优良好坏由时间和空间决定 空间： 红黑树是二叉树的进化和演变而来的，是一种平衡二叉查找树：（红黑树） 抛开红黑树的其他性质，红黑树每一个父节点都有一个或者两个子节点，那么我们知道，计算机存储结构的最小单元是页，那么就是我无论是否会占满整个页系统都会给分配一个最小存储单元：页（InnoDB一页大小固定默认是16k），那么这就很容易造成了空间上的大量浪费：因为很可能两个子节点根本就无法占满一页！这就造成了空间上的浪费！ 时间： 二叉树，红黑树的最大的特点就是同样大小的盘块不能够容纳更多的单位索引结构（数据在内节点存放）

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。 数据库查询是数据库的最主要功能之一，我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化，这篇文章对索引做一个系统的梳理，希望对大家有帮助。 一、MySQL有哪些索引类型 索引的分类可以从多个角度进行，下面分别从数据结构，物理存储和业务逻辑三个维度进行划分。 1、从数据结构角度 （1）B+树索引(O(log(n))) 关于B+树索引，后面会深入解析 （2）hash索引 仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询 其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引 只有Memory存储引擎显示支持hash索引 （3）FULLTEXT索引 现在MyISAM和InnoDB引擎都支持了 （4）R-Tree索引 用于对GIS数据类型创建SPATIAL索引 2、从物理存储角度 （1）聚集索引（clustered index） 正文内容按照一个特定维度排序存储，这个特定的维度就是聚集索引； Innodb存储引擎中行记录就是按照聚集索引维度顺序存储的，Innodb的表也称为索引表；因为行记录只能按照一个维度进行排序

数据库索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。 索引的常见模型 哈希表 数组加链表实现，添加新数据较快，但是由于不是有序的，所以区间查询速度是很慢的。 哈希表适用于只有等值查询的场景，比如Memcached及其他NOSQL引擎。 有序数组 有序数组是讲索引字段有序的存放在数组中，所以在等值查询和范围查询场景中的性能就都非常优秀。 但是有序数组在插入更新时就比较麻烦，需要移动后面所有记录，成本太高；所以有序数组索引只适用于静态存储引擎。 二叉搜索树 二叉树的查询和更新复杂度均为O(log(N))；假如一棵 100 万节点的平衡二叉树，树高 20，一次查询可能需要访问 20 个数据块。 所以大多数数据存储引擎采用N叉树 MySQL的索引 在MySQL中，索引是在存储引擎层实现的。Mysql索引使用的数据结构主要有 BTree索引 和 哈希索引 。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。 MyISAM中的索引 B+Tree叶节点的data域存放的是数据记录的地址。在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。 InnoDB中的索引

我被告知，如果我将两个表外键，那么SQL Server将创建类似于子表中的索引的东西。 我很难相信这是真的，但找不到与此有关的具体内容。 我之所以提出这个问题的真正原因是因为我们在一个删除语句中遇到了一个非常慢的响应时间，这个表可能包含15个相关表。 我问过我们的数据库人，他说如果字段上有外键，那么它就像一个索引。 你有什么经历？ 我应该在所有外键字段上添加索引还是只是不必要的开销？ #1楼 在PostgeSql中，如果你点击\\ d tablename，你可以自己检查索引 您将看到已在具有主键和唯一约束的列上自动创建btree索引，但不会在具有外键的列上创建。 我认为这至少对postgres来说是回答你的问题。 #2楼 外键不会创建索引。 只有备用键约束（UNIQUE）和主键约束才能创建索引。 在Oracle和SQL Server中也是如此。 #3楼 我注意到实体框架6.1指向MSSQL会自动在外键上添加索引。 #4楼 外键是约束，是两个表之间的关系 - 与索引本身无关。 但是已知的事实是，将所有列作为任何外键关系的一部分的索引很有意义，因为通过FK关系，您通常需要查找相关表并基于提取某些行单个值或一系列值。 因此，对FK中涉及的任何列进行索引是很有意义的，但FK本身不是索引。 查看Kimberly Tripp的优秀文章 “SQL Server何时停止 在外 键列上放置索引？”

一、activeMQ高可用 1、事物 2、签收 3、持久 4、可持久化 二、持久化机制 为了避免意外宕机以后丢失信息，需要做到重启后可以恢复消息队列，消息系统一般都会采用持久化机制 ActiveMQ持久化机制有：JDBC、AMQ、KahaDB和LevelDB，无论哪种持久化方式，消息的存储逻辑都是一致的。 就是在发送者将消息发送出去后，消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等再试图将消息发送给接收者，成功则将消息从内存中删除，失败则继续尝试发送。 消息中心启动后首先要检查指定位置，如果有未发送成功的消息，则需要把消息发送出去。 三、消息持久化机制有哪些 1、AMQ Message Store : 基于文件存储方式，以前默认的消息存储方式，现在基本不用。AMQ是一种文件存储形式，它具有写入速度快和容易恢复的特点。消息存储在一个一个文件当中，文件默认大小为32M，当一个存储文件被全部消费，那么这个文件会被标识为可删除，在下一个清除阶段被删除 2、KahaDB消息存储： 基于日志文件，从5.4版本之后开始默认支持持久化插件，可适用于任何场景，提高了性能和恢复能力。消息存储使用一个事务日志和仅用一个索引文件来存储他所有的地址。KahaDB是一个专门针对消息持久化的解决方案，他对典型的消息使用模式进行优化。数据被追加到data logs中。当不在需要log文件中数据时

前提：包括电面，美团一共7面，面了两个部门，后面一个部门面完hr面，等通知。结果凉凉。 详细的已经记不清楚了，每个问题都是根据回答再继续扩展问，只是简单的列一下。 explain的用法 分布式锁 写接口时考虑哪些 事务的传播机制 分布式一致性 线上遇到的问题，怎么解决 rabbitmq 消息发送的流程 rabbitmq如果一个消息堵在了队列头，如何处理 是否使用过rabbitmq的ack应答机制 rabbitmq的持久化 volitile关键字 threadlocal的使用场景 锁有哪几种 创建线程池的参数的含义 动态代理有哪些？ mybatis的查询过程 btree和b+tree和二叉树、红黑树有什么区别 spring中用到哪些设计模式 来源： oschina 链接： https://my.oschina.net/wuyiyi/blog/3159617

前言 前面介绍了 BlueStore的BitMap分配器 ，我们知道新版本的 Bitmap 分配器的优势在于 使用连续的内存空间从而尽可能更多的命中CPU Cache以提高分配器性能 。在这里我们了解一下基于区间树的 Stupid 分配器（类似于Linux Buddy内存管理算法），并对比分析一下其优劣。 目录 伙伴算法 数据结构 初始化 插入删除 空间分配 空间回收 优劣分析 <a name="chapter1"></a>伙伴算法 Linux内存管理算法为了能够快速响应请求，尽可能的提高内存利用率同时减少外部内存碎片，引入了伙伴系统算法 Buddy-System 。该算法将所有的空闲页分组为11个链表，每个链表分别包含 1、2、4、8、16、32、64、128、256、512、1024 个连续的页框块，每个页框块的第一个内存页的物理地址是该块大小的整数倍。 伙伴的特点是：两个块大小相同、两个块地址连续、第一块的第一个页框的物理地址是两个块总大小的整数倍（同属于一个大块，第1块和第2块是伙伴，第3块和第4块是伙伴，但是第2块和第3块不是伙伴） 。具体内存分配和内存释放可自行Google。 优点： 较好的解决外部碎片问题，不能完全解决。 针对大内存分配设计，可以快速的分配连续的内存。 缺点： 合并的要求过于严格，只能是满足伙伴关系的块才可以合并。 一块连续的内存中仅有一个页面被占用

一. 存储引擎 1. 什么是存储引擎？ 与其他数据库例如Oracle 和SQL Server等数据库中只有一种存储引擎不同的是，MySQL有一个被称为“Pluggable Storage Engine Architecture”(可替换存储引擎架构)的特性，也就意味着MySQL数据库提供了多种存储引擎。用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎。MySQL数据库在实际的工作中其实分为了语句分析层和存储引擎层，其中语句分析层就主要负责与客户端完成连接并且事先分析出SQL语句的内容和功能，而存储引擎层则主要负责接收来自语句分析层的分析结果，完成相应的数据输入输出和文件操作。简而言之，就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和操作此表的类型）。 2. 存储引擎种类 存储引擎 说明 MyISAM 高速引擎，拥有较高的插入，查询速度，但不支持事务 InnoDB 5.5版本后MySQL的默认数据库，支持事务和行级锁定，比MyISAM处理速度稍慢 ISAM MyISAM的前身，MySQL5.0以后不再默认安装 MRG_MyISAM(MERGE) 将多个表联合成一个表使用，在超大规模数据存储时很有用 Memory 内存存储引擎