BTree

我们知道数据的存储和检索是两个很重要的功能，当我们的数据量大了，怎么能快速的检索数据呢，答案是使用索引，可索引具体的技术实现有很多，选择哪一种呢，我就以mysql为例记录下它为什么选择了B+树作为索引的实现方式。 1. 索引简介 　　 索引是一种用于快速查询行的数据结构 ，就像一本书的目录就是一个索引，如果想在一本书中找到某个主题，一般会先找到对应页码。MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质： 索引是数据结构 。 2. 索引的几种数据结构类型 2.1 哈希索引（hash index） 哈希索引（hash index）基于哈希表（也可以叫散列表）实现 ，只有精确匹配索引所有列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code）,哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。 ​ 下面举个小例子 ​ 它能快速的检索数据，不过在mysql数据库却有局限： a): 哈希索引数据并不是按照索引值顺序存储的，所以无法用来进行排序； b): 不能进行多列字段查询数据； c): 更不支持范围查询，比如查询年龄大于30,。 d): 有大量重复键值的情况下，哈希索引的效率也是极低的

1.管理数据 1.1.关于GP的并发控制 1) GP使用多版本控制模型(Mutltiversion Concurrency Control/MVCC)保持数据一致性； 可将MVCC看成行级别锁的一种妥协，它在许多情况下避免了使用锁，同时可以提供更小的开销。根据实现的不同，它可以允许非阻塞式读，在写操作进行时只锁定必要的记录。MVCC会保存某个时间点上的数据快照。这意味着事务可以看到一个一致的数据视图，不管他们需要跑多久。这同时也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。如果你从来没有过种体验的话，可能理解起来比较抽象，但是随着慢慢地熟悉这种理解将会很容易。 2) MVCC以避免给数据库事务显式锁定的方式，最大化减少锁争用以确保多用户环境下的性能； 3) GP提供了各种锁机制来控制对表数据的并发访问； 4) GP为每个事务提供事务隔离； 1.2.插入新纪录 1) 需要表名和该表每列的值使用INSERT命令插入数据，GP是自动提交； 2) 显式的指定列名插入数据，当不知道当前表中列名时； 3) 从另一个表中获取并插入到当前表； 4) 使用一个命令插入多条记录，AO表为批量装载做了优化，不建议在AO表上使用单条的INSERT语句。 devdw= # \h insert 查看当前insert命令的帮助 Command: INSERT Description:

创建与管理序列 序列常用于在新增记录时自动生成唯一标识符，序列的管理包括创建序列、使用序列、修改序列以及删除序列。 创建序列 使用CREATESEQUENCE命令来创建并初始化一个给定名称的单列序列表； devdw=# \h CREATE SEQUENCE 查看创建序列的帮助 Command: CREATE SEQUENCE Description: define a new sequence generator Syntax: CREATE [ TEMPORARY | TEMP ] SEQUENCE name [ INCREMENT [ BY ] increment ] [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ] [ START [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ] [ OWNED BY { table.column | NONE } ] devdw=# \ds 通过 \ds 命令查看当前数据库中存在的序列 No relations found. devdw=# create sequence myseq start with 100; 创建名为 myseq 的序列 CREATE SEQUENCE devdw=# \ds

配置选项 配置选项 含义 --enable-debug 使用调试符号进行编译并关闭编译器优化。 --enable-utf8 具有广泛的字符支持编译。 Ncursesw是必需的。 - -enable-geoip=<legacy|mmdb> 与GeoLocation支持一起编译。 必须使用MaxMind的GeoIP。 旧版将使用原始的GeoIP数据库。 mmdb将使用增强的GeoIP2数据库。 - -enable-tcb=<memhash|btree> 与Tokyo Cabinet的存储支持一起编译。 memhash将利用Tokyo Cabinet的内存中哈希数据库。 btree将利用Tokyo Cabinet的磁盘B + Tree数据库 - -disable-zlib 在B + Tree数据库上禁用zlib压缩。 - -disable-bzip 在B + Tree数据库上禁用bzip2压缩。 - -with-getline 动态扩展行缓冲区以解析完整的行请求，而不是使用固定大小的4096。 --with-openssl 使用其WebSocket服务器的OpenSSL支持编译GoAccess 编译 + 安装 goaccess ./configure --prefix=/usr/local/goaccess --enable-utf8 --enable-geoip=legacy -

Postgresql:10.11 测试表数据量：3亿 测试使用8c 16g 服务器 创建一张表： create table nt_order ( id int PRIMARY KEY, order_id text, order_time timestamp without time zone, info jsonb ); CREATE SEQUENCE nt_order_id_seq START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE CACHE 1; alter table nt_order alter column id set default nextval('nt_order_id_seq'); 创建索引： brin索引： create index idx_nt_order_brin on nt_order using brin (order_time); 全文检索： create index idx_gin_nt_order_info on nt_order using gin(to_tsvector('english',info)); 为什么使用brin索引？ 占空间小，比btree小千倍靠上 使用brin索引适用任何场景吗？ brin索引适合范围查询（与btree索引比差距较小），brin索引主要用于高度相关的数据

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用： 这么牛X的名单，你不想了解下LSM Tree吗？装X之前，我们先来了解一些基本概念。 设计数据存储系统可能需要考虑的一些问题有：ACID，RUM（Read,Write,Memory）。 ACID ACID 相信小伙伴都被面试官问过，我想简单讨论的一点是：如何 持久化数据 才能保证数据写入的 事务性 和 读写性能？ 事务性可简单理解为：1.数据必须持久化。2.一次数据的写入返回给用户 写入成功就一定成功，失败就一定失败。 读写性能可简单理解为：一次读 或 一次写 需要的IO次数，因为访问速率：CPU>>内存>>SSD/磁盘。 对于单机存储，最简单的方式当然是：写一条就持久化一条，读一条就遍历一遍所有数据，然后返回。当然没人这么干，在内存中我们都还知道用个HashMap呢。 拿Mysql InnoDB举例子：读性能体现在数据的索引在磁盘上主要用B+树来保证。写性能体现在运用 WAL机制 来避免每次写都去更新B+树上的全量索引和数据内容，而是通过redo log记录下来每次写的增量内容，顺序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，然后在一定条件下触发脏页的刷盘。 redo

　前几天统计一个sql，是一个人提交了多少工单，顺便做了相关sql优化。数据大概2000多w。 select CustName,count(1) c from WorkOrder where CreateDate>'2016-5-1' and CreateDate<'2017-1-1' group by CustName having c>100 order by c desc; 　　为了实验最少受其他因素干扰，将生产库的200多w数据导出来，用测试服务器进行测试。 　　导出来的数据是一个堆表，没有主键，没有索引。 mysql> show index from WorkOrder; 查询index方法1 Empty set (0.00 sec) mysql> show keys from WorkOrder; 查询index方法2 Empty set (0.00 sec) 　1.堆表的情况 　这时候就在这时候，用执行计划分析下语句。 mysql> explain select CustName,count(1) c from WorkOrder where CreateDate>'2016-5-1' and CreateDate<'2017-1-1' group by CustName having c>100 order by c desc; +----+------------

Log-Structured Merge-Tree，简称 LSM。 以 Mysql、postgresql 为代表的传统 RDBMS 都是基于 b-tree 的 page-orented 存储引擎。现代计算机的最大处理瓶颈在磁盘的读写上，数据存储无法绕开磁盘的读写，纯内存型数据库除外，但由于内存存储的不稳定性，我们一般只将内存型的存储作为缓存系统。 为提升数据库系统的写性能，我们发现磁盘的 顺序写性能远远大于随机写性能 ，甚至性能高于内存的随机写。所以在很多偏向写性能的数据库系统中，以牺牲一部分读性能和增大写放大的情况下引入了 LSM 数据结构。 设计一个数据库引擎 我们从头开始设计一个数据库引擎。数据模型很简单，我们选最简单的 Key-Value 结构，一条数据只有一个 Key 和一个 Value。操作只有 get 和 put，如下： get(key); put(key, value); 从最简单的开始，每个数据库一个 data.db 文件，我们像写日志一样，将每条记录 append 到文件结尾。 key1,value1 key2,value2 key3,value3 key10,value10 key8,value8 这样我们已经完成了 80%了，然后需要完成读功能。如上数据文件，若需要查询 key2 数据，我们只能从文件开头开始遍历，当直到读取到 key2 数据： for

MySQL索引怎么用？究竟能有多快？看完这篇你就懂了 追逐仰望星空 2020-08-05 10:43:38 推荐学习 阿里P8MySQL，基础/索引/锁/日志/调优都不误，一锅深扒端给你 “吃”完这本Java性能调优实战，MySQL+JVM+Tomcat等问题一键全消 为了能让索引能有更直观的效率，我在一张表里扔进了 百万条 数据（光靠这些数据，生成数据代码写了一个小时，解决MySQL8的文件导入权限问题解决了两个小时，导入数据花费了一个小时，我太难了~(；д；)。但是，一切不以 实践数据 为标准的理论都是**耍！流！氓！**o(´^｀)o）。让我们一边讲解MySQL的使用一边看一下索引能为我们的查询带来的性能提升吧。 索引使用的优势 提高查询效率，简单来说就是查的 快 ！ 再快 ！ 更快 ！外面说的什么提高表的速度、加速表连接、减少分组及排序时间、提高系统性能，说白了都是快，查得快！（顺便我发现百度出来的索引使用优势劣势貌似就那么一两套，真就天下文章一大抄呗，抄我的也欢迎，烦请注明出处或者作者Solid_lele哈） 具体会有多快呢？ 这是没有索引的百万级数据查找（这个算快的了，慢的四十秒，时间不是很稳定，因为是从磁盘块中读取数据，原理参照我开头提到的那篇文章）10.797s： 这是有索引的百万级数据查找0.272s： 差了四十多倍，就相当于别人一年赚四十多万，我一年赚一万

int 四个字节 定长 char 也是定长 varchar text blob 变长 1、定长和变长适合放到不同表里 2、常用和不常用的字段放到不同表里 3、在一对多 需要关联查询时，进行适当合理的冗余字段 字段类型选择 整型》data time >enum char> varchar >blob text char 需要考虑字符集和校对集(校对规则 用于排序) 但是tinyint（一个字节）不存在这样的问题 mysql索引结构 1hash 2 btree https://www.cnblogs.com/tanshaoshenghao/p/12572841.html 来源： oschina 链接： https://my.oschina.net/u/3572435/blog/4321279