Minor的Java技术博客

MySQL默认就是使用的临键锁，当在非唯一索引下如果SQL没有命中记录则就是间隙锁，命中了记录就是临键锁。如果用唯一索引且SQL命中了记录，那么加的就是普通记录锁，否则就是间隙锁。，这段语句就会对该记录进行加S锁，允许其它事务的读取，其它事务也可以继续加S锁，但是不允许其它事务加X锁，否则会阻塞，直到当前事务提交后释放了S锁，其它线程才能加X锁。和间隙锁不同的是，临键锁是SQL命中了部分记录的场景，除了会锁定间隙外还会锁定命中记录的下一个区间，是一个。...

Manager节点一般是独立部署一台机器，Node节点一般是部署在每台MySQL机器上的，Node节点通过解析MySQL的日志来进行工作。MySQL主从集群默认采用的就是异步复制方式，Master的事务提交后，写入binlog然后就给客户端返回成功的响应了。相比于异步复制，半同步复制就是说事务的提交后binlog要保证至少将数据同步给一个从库才算完成，但是半同步复制并不保证从库对数据的提交是否成功。日志上的，通过对Binlog的实时同步来实现主从数据的同步。常见的分库分表手段有客户端插件、数据库代理。...

InnoDB的索引一般使用B+Tree的数据结构，但是InnoDB还支持一种索引的方式：哈希索引。InnoDB底层会实时监控索引，如果某个索引使用十分频繁，就会被认定为这个索引是热点数据，然后在InnoDB的Buffer Pool内存中创建一个Hash索引，称之为自适应Hash索引。创建以后，如果下次的查询又命中索引，那么就可以利用这个Hash索引直接O(1)的时间复杂度就能查询结果。但是，自适应hash索引只能提供的查询，做范围、模糊查询是不支持的。而且InnoDB的自适应Hash索引使用的是拉链法解决

所谓一致性问题，指的是缓存和数据库对同一份变量如何保持一致。一致性问题根据对缓存不一致的容忍程度可以划分为强一致和最终一致。强一致性保证只能通过一致性协议、分布式锁来进行控制。最终一致性可以通过MQ、最大努力通知等手段来实现。这个方案是最不可取的，因为如果一旦更新缓存成功，但是数据库写入失败就会发生脏数据问题。有可能发生数据库成功更新但是缓存更新失败，那么缓存中值永远都是旧的值。这个设计存在2个问题：1.如果先把缓存删掉，那么将会有大量读请求直接落地到DB层，造成DB压力。2.如果A线程删了缓存，还没来

事务的读取操作如果使用MVCC的方式读取就是快照读，它是一种无锁的读。所有的SELECT查询语句在可重复读、读已提交的级别下都是快照读。由于一致性读不会对记录进行加锁的操作，所以在并发环境下其它事务可以对表中的记录进行写操作。1.2.2 锁定读的语句：读取记录信息前对记录进行加锁(S/X锁都行)的行为就叫。，这段语句就会对该记录进行加S锁，允许其它事务的读取，其它事务也可以继续加S锁，但是不允许其它事务加X锁，否则会阻塞，直到当前事务提交后释放了S锁，其它线程才能加X锁。，对该记录进行加X独占锁，其它事

A事务覆盖了B事务更新的内容，B事务刚才的更新操作被A给覆盖掉了，称之为。A事务读取到了B事务已经修改但还没有提交的内容。如果此时B回滚，那么A读取的数据就是脏数据，这个情况称之为。A事务同一个SQL查询语句前后查询出来的结果不一致，叫。A事务事先通过SQL查询出某个符合条件的记录，后续由于B事务添加了这个符合条件的记录，那么A事务再次查询的时候就比第一次多了一些记录，称之为。简单说：A事务读取到了B事务新增的数据。InnoDB为每条记录都分配了和两个隐藏字段，在事务中可作为事务ID和回滚指针的作用，这个回

事务具有原子性，一系列的操作要么全部完成要么都失败回滚。如果遇到事务中的错误、手动rollback等操作就需要将数据库变更为原来的样子。例如，如果事务中的insert操作改变了数据库，那么回滚的时候只需要删除刚才添加的数据即可。MySQL将这些记录回滚相关记录的称之为。2.2 事务ID怎么生成MySQL服务器在内存内存中维护了一个全局变量，和row_id机制类似，每当有一个事务需要分配ID时，就会将这个全局变量的值当做事务ID分配给事务，然后自增1。每当这个变量的值是256的倍数时，就将该变量的值刷回

一系列的操作，要么全部执行完毕，要么全部失败。这一系列的操作具有原子性。一致性是原子性、隔离性、持久性保证后的一个事务状态，代表数据库事务前后的完整性是否有被破坏。多个事务的操作互相之间不要影响彼此的状态转移，事务与事务之间具有隔离性质。数据状态完成了转移以后结果将会永久保存。数据的访问和更改都会在Buffer Pool中更新，对于一个已经提交了的事务，在事务提交后即时发生了系统故障，这个事务对于数据库所做的更改仍然不能丢失。因为InnoDB是以页为单位管理数据，如果事务只修改了一小部分数据就没必要都立即刷

InnoDB是通过页来管理数据的，页是存放在表空间中，表空间说白了就是对数据文件的抽象，数据始终是存储在磁盘上的，如果每次CRUD的操作都要和磁盘进行IO交互，那MySQL的性能将会大打折扣，吞吐量页没法保证。此时InnoDB就需要引入一个Buffer缓冲区来优化这个问题，当客户端要访问某个页面或者数据时，可以直接从Buffer缓冲区中快速读取，这个缓冲区是在内存中的，速度不言而喻。而且这个Buffer会将页数据缓存一段时间，以便于再次访问页数据时能够快速定位，提高效率。总之，缓存的引入就是为了减少磁盘的

表示这个SQL查询语句包含了哪几张表，这个表可以是真实存在的表，也可以是临时物化表。每有一个SELECT关键字就会有一个唯一的id值，相同id值代表同一个连接查询，前面的是驱动表，后面的是被驱动表。如果是子查询，则id不一样。只要查询中不包含Union或子查询都算作Simple类型。对于包含了Union/UnionAll或者子查询的查询语句来说，最左边那个查询的type就是Primary类型。Union/UnionAll，除了最左边那个查询语句，剩下的都是Union类型。查询语句中包含物化派生表的查询方式。

MySQL的SQL查询语句对表的访问或者是查询可以有多种方式，每种方式执行的成本、花费的时间大不一样，MySQL定义了很多种表的访问方式或者叫访问类型来。通过主键索引或者唯一二级索引和常数值进行查询的时候因为目标结果是唯一确定的，MySQL认为这种查询效率十分高，成本消耗几乎忽略不计，这种访问方式定义为常数级访问const。通过二级索引和常数值进行查询的时候，扫描区间是一个单点区间，MySQL讲这种查询方式定义为ref访问类型。这种类型是ref的一种特殊存在，区别是它多了一些扫描Null值的扫描区间。如果查

用户的数据记录存放在User Records的部分，一个页生成的时候是没有User Records的，当有记录需要插入进来的时候通过去Free Space申请空间，如果足够的话那么就会开辟User Records空间作为记录空间。如果Free Space的空间不够了，就会申请新的页。用户数据的记录在User Records中是密集无缝隙的排列，且按照主键的大小从小到大单向链表排列。InnoDB在设计时，在为每个页都分配了2个内置的记录，...

索引是数据库设计中特殊的数据存储结构，它能使我们的查询效率加倍，合理的使用索引让我们的性能得到质的提升，但是开发过程中，难免各种各样的业务需求可能会导致我们不意间写的SQL语句索引失效，这里整理了一些让索引失效的SQL操作有哪些。下面是User表结构，主键只有一个id，数据量一共是800w条,根据不同测试条件后续会修改索引。CREATE TABLE `csdn`.`无标题` ( `id` bigint(11) NOT NULL AUTO_INCREMENT, `name` varchar(64