LIST分区和RANGE分区非常的相似，主要区别在于LIST是枚举值列表的集合，RANGE是连续的区间值的集合。二者在语法方面非常的相似。同样建议LIST分区列是非null列，否则插入null值如果枚举列表里面不存在null值会插入失败，这点和其它的分区不一样，RANGE分区会将其作为最小分区值存储，HASH\KEY分为会将其转换成0存储，主要LIST分区只支持整形，非整形字段需要通过函数转换成整形；5.5版本之后可以不需要函数转换使用LIST COLUMN分区支持非整形字段，在COLUMN分区中有详细的讲解。
高性能事务系统应用程序通常在提供活动跟踪的历史记录表；同时，事务系统生成$日志记录，用于系统恢复。这两种生成的信息都可以受益于有效的索引。众所周知的设置中的一个例子是TPC-a基准应用程序，该应用程序经过修改以支持对特定账户的账户活动历史记录的有效查询。这需要在快速增长的历史记录表上按帐户id进行索引。不幸的是，基于磁盘的标准索引结构（如B树）将有效地使事务的输入/输出成本翻倍，以实时维护此类索引，从而使系统总成本增加50%。显然，需要一种以低成本维护实时索引的方法。日志结构合并树（LSM树）是一种基于磁盘的数据结构，旨在为长时间内经历高记录插入（和删除）率的文件提供低成本索引。LSM树使用一种延迟和批量索引更改的算法，以一种类似于合并排序的有效方式将基于内存的组件的更改级联到一个或多个磁盘组件。在此过程中，所有索引值都可以通过内存组件或其中一个磁盘组件连续进行检索（除了非常短的锁定期）。与传统访问方法（如B-树）相比，该算法大大减少了磁盘臂的移动，并将在使用传统访问方法进行插入的磁盘臂成本超过存储介质成本的领域提高成本性能。LSM树方法还推广到插入和删除以外的操作。然而，在某些情况下，需要立即响应的索引查找将失去输入/输出效率，因此LSM树在索引插入比检索条目的查找更常见的应用程序中最有用。例如，这似乎是历史表和日志文件的常见属性。第6节的结论将LSM树访问方法中内存和磁盘组件的混合使用与混合方法在内存中缓冲磁盘页面的常见优势进行了比较。
哈希表 哈希表支持增、删、改、查操作，但是支持范围查找较差；因为哈希表特性，如果进行范围查找，一个范围的所有数据都必须经过哈希计算来查找对应的链表节点，这几乎是需要这个范围每一个数据都需要去哈希表中查找一次，性能比较差。 📷 B+树 B+树支持增、删、改、查操作，并且很好支持范围查找，插入和查找性能均衡。 B+树的结构每个非叶子节点是数据索引，叶子节点是数据或者数据的指针。B+树叶子节点之间的连接可以实现高效的范围查询，例如innoDB存储引擎默认就是B+树结构. 传统的B+树读写相对比较均衡，但是当内存容
本文在上述的基础上介绍优先队列的另外一种支持高效合并操作的实现——二项队列。原来在介绍二叉堆和左式堆的时候喜欢从结构性和堆序性两个方面介绍，它们二者都是特殊的二叉树结构，但是二项队列不能单纯的从结构性和堆序性两个方面介绍了因为二项队列并不是我们熟悉的树结构，而是树的集合——森林,本篇文章从二项队列的结构性出发介绍二项队列的基本原理。
§合并果子(fruit) 【问题描述】 在一个果园里，多多已经将所有的果子打了下来，而且按果子的不同种类分成了不同的堆。多多决定把所有的果子合成一堆。 每一次合并，多多可以把两堆果子合并到一起，消耗的体力等于两堆果子的重量之和。可以看出，所有的果子经过n-1次合并之后，就只剩下一堆了。多多在合并果子时总共消耗的体力等于每次合并所耗体力之和。 因为还要花大力气把这些果子搬回家，所以多多在合并果子时要尽可能地节省体力。假定每个果子重量都为1，并且已知果子的种类数和每种果子的数目，你的任务
1 文档说明 该文档为学习基本排序算法过程中的学习笔记，大部分内容从网络上其他渠道也能得到，仅用于记录备忘之用。 冒泡、选择、插入三种作为基本的排序算法是必须要掌握的，而在MapReduce的实际应用中。在Map阶段，k-v溢写时，采用的正是快排;而溢出文件的合并使用的则是归并;在Reduce阶段，通过shuffle从Map获取的文件进行合并的时候采用的也是归并;最后阶段则使用了堆排作最后的合并过程。 所以快排、归并以及堆排是必须要掌握的排序算法，这都在MapReduce内部使用的排序算法，
在上一篇文章《Redis列表实现原理之ziplist结构》，我们分析了ziplist结构如何使用一块完整的内存存储列表数据。
B+ 树为了维护索引有序性，在插入新值的时候需要做必要的维护。如果插入的值比最大值id大，则只需要最后记录后面插入一个新记录。如果新插入的ID值在原先的有序中间，就相对麻烦了，需要逻辑上挪动后面的数据，空出位置。如果所在的数据页已经满了，根据 B+ 树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去。这个过程称为页分裂。在这种情况下，性能自然会受影响。 除了性能外，页分裂操作还影响数据页的利用率。原本放在一个页的数据，现在分到两个页中，整体空间利用率降低大约 50%。 当然有分裂就有合并。当相邻两个页由于删除了数据，利用率很低之后，会将数据页做合并。合并的过程，可以认为是分裂过程的逆过程。 基于上面的索引维护过程说明，我们来讨论一个案例： 你可能在一些建表规范里面见到过类似的描述，要求建表语句里一定要有自增主键。当然事无绝对，我们来分析一下哪些场景下应该使用自增主键，而哪些场景下不应该。 自增主键是指自增列上定义的主键，在建表语句中一般是这么定义的： NOT NULL PRIMARY KEY AUTO_INCREMENT。 插入新记录的时候可以不指定 ID 的值，系统会获取当前 ID 最大值加 1 作为下一条记录的 ID 值。 也就是说，自增主键的插入数据模式，正符合了递增插入的场景。每次插入一条新记录，都是追加操作，都不涉及到挪动其他记录，也不会触发叶子节点的分裂。 而有业务逻辑的字段做主键，则往往不容易保证有序插入，这样写数据成本相对较高。 除了考虑性能外，我们还可以从存储空间的角度来看。假设你的表中确实有一个唯一字段，比如字符串类型的身份证号，那应该用身份证号做主键，还是用自增字段做主键呢？ 由于每个非主键索引的叶子节点上都是主键的值。如果用身份证号做主键，那么每个二级索引的叶子节点占用约 20 个字节，而如果用整型做主键，则只要 4 个字节，如果是长整型（bigint）则是 8 个字节。 显然，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。 所以，从性能和存储空间方面考量，自增主键往往是更合理的选择。 有没有什么场景适合用业务字段直接做主键的呢？还是有的。比如，有些业务的场景需求是这样的：
Excel催化剂已正式在千聊上发布视频，如查阅文章有理解障碍，不妨查看下视频，视频不定期更新，内容丰富，干货满满，有术亦有道！
在所有的排序算法中，冒泡、插入、选择属于相类似的排序算法，这类算法的共同点：通过不停地比较，再使用交换逻辑重新确定数据的位置。
在ClickHouse中不支持对数据update和delete操作（不能使用标准的更新和删除语法操作CK），但在增量计算场景下，状态更新是一个常见的现象，此时update操作似乎更符合这种需求。
最近在学习数据库相关的知识，了解到数据库很多是采用B-/+树作为索引，例如Mysql的InnoDB引擎使用的B+树、MongoDB默认采用B树作为索引。
排序算法中，冒泡、插入、选择属于相类似的排序算法，这类算法的共同点：通过不停地比较，再使用交换逻辑重新确定数据的位置。
特别说明：本节【SAS Says】基础篇：复制、堆叠、合并数据，用的是数说君学习《The little SAS book》时的中文笔记，我们认为这是打基础的最好选择。 前面我们介绍过导入数据、ODS的使用、产生一个描述性结果的报告。到这一节，终于开始玩数据了。本节就开始复制和合并数据。 本节目录： 1. 使用SET语句复制数据集 2. 使用SET语句堆叠数据 3. 使用SET语句插入数据集 4. 一对一匹配合并数据 5. 一对多匹配合并数据 6. 合并统计量与原始数据 7. 合并total和原始数据 ---
在列表中插入一个新的区间，你需要确保列表中的区间仍然有序且不重叠（如果有必要的话，可以合并区间）。
排序：所谓排序，就是使一串记录，按照其中的某个或某些关键字的大小，递增或递减的排列起来的操作。 稳定性：假定在待排序的记录序列中，存在多个具有相同的关键字的记录，若经过排序，这些记录的相对次序保持不变，即在原序列中，r[i]=r[j]，且r[i]在r[j]之前，而在排序后的序列中，r[i]仍在r[j]之前，则称这种排序算法是稳定的；否则称为不稳定的。 内部排序：数据元素全部放在内存中的排序。 外部排序：数据元素太多不能同时放在内存中，根据排序过程的要求不能在内外存之间移动数据的排序。
在进入 Vue 3 组合 API，深入响应式之前，我们需要搞懂 ES6 出现的几个 API，其中包含以下几个
作者：肖涛 背景 Redis是一个应用广泛的开源NoSql数据库，在腾讯云Redis开发过程中，我们比较深入地对其进行了研究和应用，并和自研的Grocery等数据库系统做了一些对比，总结出了Redis
以上结构适合用于数据量相对不是很大，能够一次性存放在内存中，进行数据查找的场景（内查找）。
在 统计信息（上） 中，我们介绍了统计信息基本概念、TiDB 的统计信息收集/更新机制以及如何用统计信息来估计算子代价，本篇将会结合原理介绍 TiDB 的源码实现。
每个链表都有一个“链表头”，通常是一个指针。对Java而言，它是链表节点对象的引用。用来存放链表中第一个节点的地址。同时，链表中最后一个节点的指针域通常会置空null，用来表示该节点是链表的最后一个节点，没有后继节点。
前面的文章我们已经学习了二叉搜索树和平衡二叉搜索树AVL树，今天我们再来了解一种新的平衡树2–3树，2–3树由约翰·霍普克洛夫特于1970年发明，在计算机科学中，2–3树是一种树型数据结构，内部节点（存在子节点的节点）要么有2个孩子和1个数据元素，要么有3个孩子和2个数据元素，叶子节点没有孩子，并且有1个或2个数据元素，2-3树的平均时间复杂度为O（logN），空间复杂度为O（N），注意严格的说2-3树的性能是在O（log3N）和O（log2N）之间的，因为大O复杂度表示通常会忽略系数项。
二分搜索树是为了快速查找而生，它是一颗二叉树，每一个节点只有一个元素（值或键值对），左子树所有节点的值均小于父节点的值，右子树所有的值均大于父节点的值，左右子树也是一颗二分搜索树，而且没有键值相等的节点。它的查找、插入和删除的时间复杂度都与树高成比例，期望值是O(logn)。
线段树不支持的操作：删除，插入 ---- 常见的平衡树 treap 慢||好写 sbt(大小平衡的树) 非常快 比较好写 ||功能不全 rbt 红黑树 特别快 || 非常难写 以上操作支持插入删除O(NlogN) splay 特别慢。。≈O(sqrt(N)) 不太好写，功能强大 ---- 可持久化Treap 平衡树一定是二叉树 左儿子里面的元素一定比他小 右儿子一定比当前节点大 中序遍历一定排好序 每次递归的查询 小——》左 大——》右 弊端：深度可能会非常深-->代价非
推出一个新系列，《看图轻松理解数据结构和算法》，主要使用图片来描述常见的数据结构和算法，轻松阅读并理解掌握。本系列包括各种堆、各种队列、各种列表、各种树、各种图、各种排序等等几十篇的样子。
B 树和红黑树的动画小吴还在制作当中，比想象中的复杂好多好多好多，今天先来一个图解版的 B 树。。。
PostgreSQL13.0于2020年9月24日正式release，13版本的PG带来很多优秀特性：比如索引的并行vacuum，增量排序，btree索引deduplication，异构分区表逻辑订阅等。在这里面最闪亮的特性非deduplication莫属。
归： 不断将原数组拆分为子数组（一分为二），直到每个子数组只剩下一个元素 = 》 归过程结束
MySQL InnoDB 表数据页或者二级索引页（简称数据页或者索引页）的合并与分裂对 InnoDB 表整体性能影响很大；数据页的这类操作越多，对 InnoDB 表数据写入的影响越大。
面对这个问题，我相信80%的人都不清楚（包括我自己），那么本文就围绕这个问题展开介绍，在了解索引之前，我们先了解一下B+树，什么是B+树？在了解B+树之前，先了解一下什么是B树？介绍B树和B+树的插入、删除操作。
兜兜转转，一晃年关将至。时间证明了一个道理，学啥忘啥，学的越快忘得越快，还不如踏踏实实写点笔记心得来的实在。
B树，又称多路平衡查找树，B树中所有节点的孩子结点数的最大值成为B树的阶，通常用m表示。一棵m阶B树或为空树，或为满足如下特性的m叉树：
由于LeetCode上的算法题很多涉及到一些基础的数据结构，为了更好的理解后续更新的一些复杂题目的动画，推出一个新系列 -----《图解数据结构》，主要使用动画来描述常见的数据结构和算法。本系列包括十大排序、堆、队列、树、并查集、图等等大概几十篇。
当数据项存储在诸如列表的集合中时，我们说它们具有线性或顺序关系。每个数据项都存储在相对与其他数据项的位置。在Python列表中，这些相对位置是单个项的索引值。由于这些索引值是有序的，我们可以按顺序访问它们。这个过产生了顺序查找。
本文是介绍BTree文章的下篇，在BTree实现原理上篇主要介绍实现原理，下篇主要介绍btree源码实现。
在日常开发中难免会出现一些"手贱"的操作，当你不小心删除了一个文件后，该如何找回它呢？
这一章我们接着介绍组合操作符，这类operators可以同时处理多个Observable来创建我们所需要的Observable。组合操作符主要包含：等等。 Merge 将两个Observable发射的事件序列组合并成一个事件序列，就像是一个Observable发射的一样。你可以简单的将它理解为两个Obsrvable合并成了一个Observable，合并后的数据是无序的。 我们看下面的例子，一共有两个Observable：一个用来发送字母，另一个用来发送数字；现在我们需要两连个Observable发射
输了并不代表一无所有，你所经历的同样宝贵。如果你没有总结教训，只是沉浸在阴霾中，这样你就真的输了。
1. 概述 相信很多同学看过 MySQL 各种优化的文章，里面 99% 会提到：单表数据量大了，需要进行分片（水平拆分 or 垂直拆分）。分片之后，业务上必然面临的场景：跨分片的数据合并。今天我们就一
LevelDB是Google开源的持久化KV单机数据库，具有很高的随机写，顺序读/写性能，但是随机读的性能很一般，也就是说，LevelDB很适合应用在查询较少，而写很多的场景。LevelDB应用了LSM (Log Structured Merge) 策略，lsm_tree对索引变更进行延迟及批量处理，并通过一种类似于归并排序的方式高效地将更新迁移到磁盘，降低索引插入开销，关于LSM，本文在后面也会简单提及。
要设计一个时间复杂度为 O(n log k) 的算法，将 k 个有序链表合并为一个有序链表，可以使用最小堆来实现 k 路归并。
首先，让我们明确一下问题的描述。我们有一个长度为 n 的序列，这个序列被分为 n/k 个子序列，每个子序列包含 k 个元素。每个子序列中的元素都满足题目的条件：小于其后继子序列中的所有元素，且大于其前驱子序列中的每个元素。我们的目标是证明对这个序列进行排序所需的最少比较次数是 Ω(nlgk)。
根据文章内容总结的摘要
本文是对开源监控工具Ganglia使用的RRD数据库的一个简单介绍，此外还有一些有关RRDTool的基本操作。
该题在 LeetCode 官网上有关于链表的问题中标注为最难的一道题目：难度为 Hard ，通过率在链表 Hard 级别目前最低。
给出一个无重叠的按照区间起始端点排序的区间列表。 在列表中插入一个新的区间，你要确保列表中的区间仍然有序且不重叠（如果有必要的话，可以合并区间）。
Kylin在1.6.0版本中提到了TopN的性能提升非常大：https://issues.apache.org/jira/browse/KYLIN-1917
https://segmentfault.com/a/1190000039776687
在解决本题时最初的思路就是通过遍历比较值的大小然后合并两个链表，并且由于对于链表知识的遗忘，导致具体实现过程中出现一些错误，且时间花费在复习链表知识上。后来成功提交后，看了题解，才发现可以使用递归解决该题目，并自己尝试着写递归，能成功提交，但占用内存相比官方递归代码多。 第一次提交： 遍历比较值，合并链表，结果如下所示
那就是搞定面试官系列，我会把常见的面试知识通过这个专栏写出来，比如我们常见的 Java、MySQL、Redis、MQ 以及其他的一些技术框架。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
