的非主键索引类似嘛，为什么要叫它“倒排”呢？这个问题我目前也为搞清楚，可能要等到后续了解了其具体实现才能理解。我们还是以书籍检索为例，假设有以下数据，每一行就是一个

信息等，所以需要一套分布式机制来维护元数据的一致性。这类机制一般有两个模式：分散式和集中式分散式机制将元数据存储在部分或者所有节点上，不同节点之间进行不断的通信来维护元数据的变更和一致性。Redis

的关联字段将两张表排序(如果已经排序好了，比如字段上有索引则不需要再排序)，然后在对两张表进行一次归并操作。如果两表已经被排过序，在执行排序合并连接时不需要再排序了，这时Merge

锁冲突相关知识，所以一般遇到这些偶尔出现的死锁异常，往往一时没有头绪，不好处理。本篇文章会讲解一下如果线上发生了死锁异常，如何去排查和处理。除了系列前文讲解的有关加锁和锁冲突的原理还，还需要对

条件是如何生效的，用何登成大神的原话，就是：给定一条SQL，where条件中的每个子条件，在SQL执行的过程中有分别起着什么样的作用？具体场景我们使用下面这张

唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常用于主键或唯一索引扫描。对于每个来自前边的表的行组合，从该表中读取一行。它是除了

语句，如果主键存在，则只需要对其加记录锁，如果不存在，则需要在加间隙锁。至于其他非唯一性索引更新或者插入时的加锁也都不同程度的受到现存数据的影响，后续我们会一一说明。具体场景分析具体

这个主键索引上加写锁，如上图所示。也就是说使用主键索引需要加一把锁，使用二级索引需要在二级索引和主键索引上各加一把锁。根据索引对单行数据进行更新的加锁原理了解了，那如果更新操作涉及多个行呢，比如下面

如果命令执行时间在毫秒级，则实例实际OPS只有1000左右。慢查询队列长度默认128，可适当调大。慢查询本身只记录了命令执行时间，不包括数据网络传输时间和命令排队时间，因此客户端发生阻塞异常

也就是需求发生变更时，只需要修改一个DP。当然对角矩阵属于比较理想的情况，书中也罗列了一些其他类型的映射矩阵。其中最差的情况是

database,type,key,size_in_bytes,encoding,num_elements,len_largest_element,expiry

存储系统，它使用六种底层数据结构构建了包含字符串对象、列表对象、哈希对象、集合对象和有序集合对象的对象系统。今天我们就通过12张图来全面了解一下它的数据结构和对象系统的实现原理。

为了使得集群能够水平扩展，首要解决的问题就是如何将整个数据集按照一定的规则分配到多个节点上，常用的数据分片的方法有：范围分片，哈希分片，一致性哈希算法和虚拟哈希槽等。

System.out.println(StatisticsUtil.standardDeviation(atomicLongMap.asMap().values().toArray(new

probability)呢？，接下来的BloomFilter的原理将回答这个问题。原理解析 初始状态下，布隆过滤器是一个包含m位的位数组，每一位都置为0。 为了表达S={x1,

 集群限流由于会面对相比单机更大的流量冲击，所以一般不会进行线程等待，而是直接进行丢弃，因为如果让拿不到令牌的线程进行睡眠，会导致大量的线程堆积，线程持有的资源也不会释放，反而容易拖垮服务器。

RateLimiter的静态方法创建一个限流器，设置每秒放置的令牌数为5个。返回的RateLimiter对象可以保证1秒内不会给超过5个令牌，并且以固定速率进行放置，达到平滑输出的效果。

 Netty有负责服务端监听建立连接的线程组(mainReactor)和负责连接读写操作的IO线程组(subReactor)，还可以有专门处理业务逻辑的Worker线程组(ThreadPool)。

ReentranLock分为公平锁和非公平锁，二者的区别就在获取锁机会是否和排队顺序相关。我们都知道，如果锁被另一个线程持有，那么申请锁的其他线程会被挂起等待，加入等待队列。

 事务是数据库最为重要的机制之一，凡是使用过数据库的人，都了解数据库的事务机制，也对ACID四个基本特性如数家珍。但是聊起事务或者ACID的底层实现原理，往往言之不详，不明所以。所以，今天我们就一起来分析和探讨InnoDB的事务机制，希望能建立起对事务底层实现原理的具体了解。事务的四大特性 数据库事务具有ACID四大特性。ACID是以下4个词的缩写：原子性(atomicity)

+∞)，可以看出它即锁定了一个范围，也会锁定记录本身。 InnoDB存储引擎的锁算法的一些规则如下所示，后续章节会给出对应的实验案例和详细讲解。在不通过索引条件查询时，InnoDB

1; 我们首先在会话A中显示地开启一个事务，然后读取test表中的id为1的数据，但是事务并没有结束。于此同时，用户在开启另一个会话B，这样可以模拟并发的操作，然后对会话B做出如下的操作：#

 锁是数据库系统区分于文件系统的一个关键特性。数据库使用锁来支持对共享资源进行并发访问，提供数据的完整性和一致性。此外，数据库事务的隔离性也是通过锁实现的。InnoDB在此方面一直优于其他数据库引擎。InnoDB会在行级别上对表数据上锁，而MyISAM只能在表级别上锁，二者性能差异可想而知。InnoDB存储引擎中的锁 InnoDB存储引擎实现了如下两种标准的行级锁：共享锁(S

 任何一个技术都有其底层的关键基础技术，这些关键技术很有可能也是其他技术的关键技术，学习这些底层技术，就可以一通百通，让你很快的掌握其他技术。如何在磁盘上存储数据，如何使用日志文件保证数据不丢失以及如何落盘，不仅是MySQL等数据库的关键技术，也是MQ消息队列或者其他中间件的关键技术之一。InnoDB整体架构 上图详细显示了InnoDB存储引擎的体系架构，从图中可见，InnoDB存储引擎由内存池，后台线程和磁盘文件三大部分组成。接下来我们就来简单了解一下磁盘文件相关的概念和原理。

 常言说得好，每个成功男人背后都有一个为他默默付出的女人，而对于MySQL来说，这个“人”就是InnoDB存储引擎。 MySQL区别于其他数据库的最为重要的特点就是其插件式的表存储引擎。而在众多存储引擎中，InnoDB是最为常用的存储引擎。从MySQL5.5.8版本开始，InnoDB存储引擎是默认的存储引擎。 InnoDB存储引擎支持事务，其设计目标主要面向在线事务处理(OLTP)的应用。其特点是行锁设计、支持外键，并支持非锁定读，即默认读操作不会产生锁。 InnoDB通过使用多版本并发控制(MVCC)来获取高并发性，并且实现了SQL标准的4中隔离级别，默认为REPEATABLE级别。同时，使用一种被称为next-key-locking的策略来避免幻读现象的产生。除此之外，InnoDB存储引擎还提供了插入缓冲(insert

 昔日庖丁解牛，未见全牛，所赖者是其对牛内部骨架结构的了解，对于MySQL亦是如此，只有更加全面地了解SQL语句执行的每个过程，才能更好的进行SQL的设计和优化。 当希望MySQL能够以更高的性能运行查询时，最好的办法就是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点，很多查询优化工作实际上就是遵循一些原则能够按照预想的合理的方式运行。 如下图所示，当向MySQL发送一个请求的时候，MySQL到底做了什么：客户端发送一条查询给服务器。服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段。服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划。MySQL根据优化器生成的执行计划，再调用存储引擎的API来执行查询。将结果返回给客户端。SQL语句执行过程查询缓存 MySQL查询缓存保存查询返回的完整结构。当查询命中该缓存时，MySQL会立刻返回结果，跳过了解析、优化和执行阶段。 查询缓存系统会跟踪查询中涉及的每个表，如果这些表发生了变化，那么和这个表相关的所有缓存数据都将失效。 MySQL将缓存存放在一个引用表中，通过一个哈希值引用，这个哈希值包括了以下因素，即查询本身、当前要查询的数据库、客户端协议的版本等一些其他可能影响返回结果的信息。 当判断缓存是否命中时，MySQL不会进行解析查询语句，而是直接使用SQL语句和客户端发送过来的其他原始信息。所以，任何字符上的不同，例如空格、注解等都会导致缓存的不命中。 当查询语句中有一些不确定的数据时，则不会被缓存。例如包含函数NOW()或者CURRENT_DATE()的查询不会缓存。包含任何用户自定义函数，存储函数，用户变量，临时表，mysql数据库中的系统表或者包含任何列级别权限的表，都不会被缓存。 有一点需要注意，MySQL并不是会因为查询中包含一个不确定的函数而不检查查询缓存，因为检查查询缓存之前，MySQL不会解析查询语句，所以也无法知道语句中是否有不确定的函数。 事实则是，如果查询语句中包含任何的不确定的函数，那么其查询结果不会被缓存，因为查询缓存中也无法找到对应的缓存结果。 有关查询缓存的配置如下所示。query_cache_type:是否打开查询缓存。可以设置为OFF、ON和DEMAND。DEMAND表示只有在查询语句中明确写明SQL_CACHE的语句才会放入查询缓存。query_cache_size:查询缓存使用的总内存空间。query_cache_min_res_unit:在查询缓存中分配内存块时的最小单元。较小的该值可以减少碎片导致的内存空间浪费，但是会导致更频繁的内存块操作。query_cache_limit:MySQL能够查询的最大查询结果。如果查询结果大于这个值，则不会被缓存。因为查询缓存在数据生成的时候就开始尝试缓存数据，所以当结果全部返回后，MySQL才知道查询结果是否超出限制。超出之后，才会将结果从查询缓存中删除。 对查询缓存的优化是数据库性能优化的重要一环。判断流程大致如下图所示。查询缓存判断流程图 缓存命中率可以通过如下公式计算：Qcache_hits/(Qcache_hits

Tree中，你进行的添加列，删除列，插入，更新等任何操作都会被当做操作消息存储在非叶节点上。由于操作只是被简单地存储在缓存或者任何次级索引缓存(secondary

B-Tree索引的底层数据结构一般是B+树，其具体数据结构和优势这里就不作详细描述，下图展示了B-树索引的抽象表示，大致反应了MyISAM索引是如何工作的，而InnoDB使用的结构有所不同。