冷雨清的博客

MySQL底层知识主要要从张架构图开始谈起MySQL架构记住！**增删查改都不是直接对磁盘或者硬盘操作！**而是先会对MySQL的buffer pool进行操作，而这个是在存储引擎层面的，而不是中间查询缓存的过程！默认buffer pool是128M页buffer pool是存放在内存当中的，主要是存储‘页’，这个页里面是磁盘里面映射的数据。里面既有双向链表，也有单向链表；一页是16KB里面页的连接主要是双向链表，而页里面的数据就是单向链表，而页里面的数据并未是固定的，有可能是叶子节点，也

1.最左匹配原则介绍如果建立的是复合索引，索引的顺序要按照建立时的顺序，即从左到右，如：a->b->c（和 B+树的数据结构有关）无效索引举例a->c：a 有效，c 无效b->c：b、c 都无效c：c 无效2.覆盖索引在B+树的索引中，叶子节点可能存储了当前的key值，也可能存储了当前的key值以及整行的数据，这就是聚簇索引和非聚簇索引。 在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键建立聚簇索引。如果没有唯一键，则隐式的生成一个键来建

B+树能存多少数据？一个扇区的大小是512字节，而文件系统的最小单元是块，一个块的大小是4k，而对于InnoDB存储引擎也有自己的最小储存单元——页（Page），一个页的大小是16K。假设一行数据的大小是1k，那么一个页可以存放16行这样的数据。假设主键ID为bigint类型，长度为8字节，而指针大小在InnoDB源码中设置为6字节，这样一共14字节，我们一个页中能存放多少这样的单元，其实就代表有多少指针，即16384/14=1170。那么可以算出一棵高度为2的B+树，能存放1170*16=18

主要要从张架构图开始谈起MySQL架构记住！增删查改都不是直接对磁盘或者硬盘操作而是先会对MySQL的buffer pool进行操作，而这个是在存储引擎层面的，而不是中间查询缓存的过程！默认buffer pool是128M页buffer pool是存放在内存当中的，主要是存储‘页’，这个页里面是磁盘里面映射的数据。里面既有双向链表，也有单向链表；一页是16KB里面页的连接主要是双向链表，而页里面的数据就是单向链表，而页里面的数据并未是固定的，有可能是叶子节点，也有可能是非叶子节点。但总之里

其实所谓的两阶段就是把一个事物分成两个阶段来提交。就像下图这样两阶段提交的第一阶段 （prepare阶段）：写rodo-log 并将其标记为prepare状态。紧接着写binlog两阶段提交的第二阶段（commit阶段）：写bin-log 并将其标记为commit状态。什么需要两段式提交呢？因为MySQL有两个日志文件，我们需要两个日志都写入，我们需要保证两个日志的一致性。那么如果不使用两阶段提交的方式，直接写入redo log然后写入binlog有什么问题呢？假设，写完redo log，系统

注：这篇文章并非原创，是在网上查询的资料（侵删）本篇文章会分析下一个 sql 语句在 MySQL 中的执行流程，包括 sql 的查询在 MySQL 内部会怎么流转，sql 语句的更新是怎么完成的。在分析之前我会先带着你看看 MySQL 的基础架构，知道了 MySQL 由那些组件组成已经这些组件的作用是什么，可以帮助我们理解和解决这些问题。一 MySQL 基础架构分析1.1 MySQL 基本架构概览下图是 MySQL 的一个简要架构图，从下图你可以很清晰的看到用户的 SQL 语句在 MySQL 内

事务的并发问题1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。小结：不可重复读的和幻读很容易混淆，不可重复读侧重

​ 事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现。说到事务日志，不得不说的就是redo和undo。在存储引擎修改表的数据时，会将数据从磁盘拷贝到内存中，然后修改内存中的数据拷贝，再将修改行为持久化到磁盘中，而不用每次将修改的数据本身持久化到硬盘中1.redo log（重做日志）在innoDB的存储引擎中，事务日志通过重做(redo log)日志和日志缓冲(redo Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，每次事务日志

锁类别表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。这些存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。最大程度的支持并发，同时也带来了最大的锁开销。在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在

什么是索引索引是帮助MySQL高效获取数据的排好序的数据结构索引的数据结构二叉树：理想的情况下应该是下面这样的但用这个数据结构的话会产生下面这种情况，所以不适用红黑树：但是如果数据量达到百万级别了，红黑树树高还是太高了，而且范围查找需要回滚查询效率低Hash表：hash表是散列存放，用hash函数计算出来的hash模拟存放的地址，所以直接查找效率很高，但是！！如果出现范围查找就会出问题，如下图所示，如果要查找大于22的值，还是要遍历全表！！所以不合适B-Tree（

分库分表(4) —SpringBoot + ShardingSphere 实现分表这是我网上看到的一篇很好的blog，在此记录一下用于学习（仅用于学习）源blog地址：https://www.cnblogs.com/qdhxhz/p/11651163.htmlShardingSphere实现分表有关分库分表前面写了三篇博客:1、分库分表(1) — 理论2、分库分表(2) — ShardingSphere(理论)3、分库分表(3) —SpringBoot + ShardingSphere实现读写

分库分表(3) —SpringBoot + ShardingSphere 实现读写分离这是我网上看到的一篇很好的blog，在此记录一下用于学习（仅用于学习）源blog地址：https://www.cnblogs.com/qdhxhz/p/11656205.htmlShardingSphere实现读写分离有关ShardingSphere概念前面写了两篇博客:1、分库分表(1) — 理论2、 分库分表(2) — ShardingSphere(理论)下面就这个项目做个整体简单介绍，并在文章最下方附上

分库分表(2) — ShardingSphere(理论)这是我网上看到的一篇很好的blog，在此记录一下用于学习（仅用于学习）源blog地址：https://www.cnblogs.com/qdhxhz/p/11629883.htmlShardingSphere—理论ShardingSphere在中小企业需要分库分表的时候用的会比较多，因为它维护成本低，不需要额外增派人手;而且目前社区也还一直在开发和维护，还算是比较活跃。但是中大型公司一般会选择选用 Mycat 这类 proxy 层方案，因为可能

分库分表(1) — 理论这是我网上看到的一篇很好的blog，在此记录一下用于学习（仅用于学习）源blog地址：https://www.cnblogs.com/qdhxhz/p/11608222.html当一张表的数据达到几千万时，查询一次所花的时间会变长。业界公认MySQL单表容量在 1千万 以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。数据切分可以分为：垂直切分和水平切分。一、垂直切分垂直切分又可以分为: 垂直分库和垂直分表。1、垂直分库概念 就是根据业务耦合性，将关联度低的