2021-07-31 - 需要打印出来的图表 - 含各种机制

1.应用场景

主要用于帮助自己记住知识点，能随时记起，有时候就是要记住，每次靠查询是不可靠的～

2.学习/操作

1.文档阅读  08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？-极客时间 分布式存储 - 含DB读写分离/主从同步/分库分表/ - 学习/实践_分布式存储db-CSDN博客  SQL 更新语句的执行流程与日志写入  2.整理输出 2.1 MySQL 1. MySQL主从同步机制  20210731 周六 家里 08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？-极客时间 // 08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？ 分布式存储 - 含DB读写分离/主从同步/分库分表/ - 学习/实践_分布式存储db-CSDN博客 // 2021-03-22 - 分布式存储 - 数据库主从/分库分表 - 学习/实践 描述 主从复制的过程是这样的： 首先从库在连接到主节点时会创建一个 IO 线程，用以请求主库更新的 binlog，并且把接收到的 binlog 信息写入一个叫做 relay log 的日志文件中， 而主库也会创建一个 log dump 线程来发送 binlog 给从库； 同时，从库还会创建一个 SQL 线程读取 relay log 中的内容，并且在从库中做回放，最终实现主从的一致性。 这是一种比较常见的主从复制方式。 在这个方案中，使用独立的 log dump 线程是一种异步的方式，可以避免对主库的主体更新流程产生影响，而从库在接收到信息后并不是写入从库的存储中，是写入一个 relay log，是避免写入从库实际存储会比较耗时，最终造成从库和主库延迟变长。 你会发现，基于性能的考虑，主库的写入流程并没有等待主从同步完成就会返回结果，那么在极端的情况下，比如说主库上 binlog 还没有来得及刷新到磁盘上就出现了磁盘损坏或者机器掉电，就会导致 binlog 的丢失，最终造成主从数据的不一致。 不过，这种情况出现的概率很低，对于互联网的项目来说是可以容忍的。 2. 执行计划的的各字段及含义 20210731 周六 家里 https://laravelacademy.org/post/21922 // SQL 更新语句的执行流程与日志写入 3. 索引底层数据结构 B 树的出现就是为了解决这个问题，B 树的英文是 Balance Tree，也就是平衡的多路搜索树，它的高度远小于平衡二叉树的高度。在文件系统和数据库系统中的索引结构经常采用 B 树来实现。  B 树的结构如下图所示： B+树  维护节点[分裂节点]  4. 归并排序 伪代码 // 归并排序算法, A是数组，n表示数组大小 merge_sort(A, n) {   merge_sort_c(A, 0, n-1) } // 递归调用函数 merge_sort_c(A, p, r) {   // 递归终止条件   if p >= r  then return   // 取p到r之间的中间位置q   q = (p+r) / 2   // 分治递归   merge_sort_c(A, p, q)   merge_sort_c(A, q+1, r)   // 将A[p...q]和A[q+1...r]合并为A[p...r]   merge(A[p...r], A[p...q], A[q+1...r]) } 5. 快速排序 占用额外内存空间的分区过程 优化后： 原地分区的整个过程 伪代码 // 快速排序，A是数组，n表示数组的大小 quick_sort(A, n) {   quick_sort_c(A, 0, n-1) } // 快速排序递归函数，p,r为下标 quick_sort_c(A, p, r) {   if p >= r then return      q = partition(A, p, r) // 获取分区点   quick_sort_c(A, p, q-1)   quick_sort_c(A, q+1, r) } 后续补充 ...

3.问题/补充

TBD

后续补充

...