Format more copywriting

.autocorrectrc

@@ -0,0 +1,108 @@
+# yaml-language-server: $schema=https://huacnlee.github.io/autocorrect/schema.json
+rules:
+  # Default rules: https://github.com/huacnlee/autocorrect/raw/main/autocorrect/.autocorrectrc.default
+  spellcheck: 2
+spellcheck:
+  words:
+    # Please do not add a general English word (eg. apple, python) here.
+    # Users can add their special words to their .autocorrectrc file by their need.
+    - ActiveMQ
+    - AirPods
+    - Aliyun
+    - API
+    - App Store
+    - AppKit
+    - AppStore = App Store
+    - AWS
+    - CacheStorage
+    - CDN
+    - CentOS
+    - CloudFront
+    - CORS
+    - CPU
+    - DNS
+    - Elasticsearch
+    - ESLint
+    - Facebook
+    - GeForce
+    - GitHub
+    - Google
+    - GPU
+    - H5
+    - Hadoop
+    - HBase
+    - HDFS
+    - HKEX
+    - HTML
+    - HTTP
+    - HTTPS
+    - I10n
+    - I18n
+    - iMovie
+    - IndexedDB
+    - Intel
+    - iOS
+    - iPad
+    - iPadOS
+    - iPhone
+    - iTunes
+    - JavaScript
+    - jQuery
+    - JSON
+    - JWT
+    - Linux
+    - LocalStorage
+    - macOS
+    - Markdown
+    - Microsoft
+    - MongoDB
+    - Mozilla
+    - MVC
+    - MySQL
+    - Nasdaq
+    - Netflix
+    - NodeJS = Node.js
+    - NoSQL
+    - NVDIA
+    - NYSE
+    - OAuth
+    - Objective-C
+    - OLAP
+    - OSS
+    - P2P
+    - PaaS
+    - RabbitMQ
+    - Redis
+    - RESTful
+    - RSS
+    - RubyGem
+    - RubyGems
+    - SaaS
+    - Sass
+    - SDK
+    - Shopify
+    - SQL
+    - SQLite
+    - SQLServer
+    - SSL
+    - Tesla
+    - TikTok
+    - tvOS
+    - TypeScript
+    - Ubuntu
+    - UML
+    - URI
+    - URL
+    - VIM
+    - watchOS
+    - WebAssembly
+    - WebKit
+    - Webpack
+    - Wi-Fi
+    - Windows
+    - WWDC
+    - Xcode
+    - XML
+    - YAML
+    - YML
+    - YouTube

cs_learn/README.md

@@ -4,5 +4,5 @@
 
 - [学习计算机基础有什么推荐的书？](/cs_learn/cs_learn.md)
 - [看书的一点小建议](/cs_learn/look_book.md)
-- [ 如何将计算机网络、操作系统、数据结构与算法、计算组成融会贯通？](/cs_learn/feel_cs.md)
+- [如何将计算机网络、操作系统、数据结构与算法、计算组成融会贯通？](/cs_learn/feel_cs.md)
 

cs_learn/cs_learn.md

@@ -312,7 +312,7 @@ TCP/IP 网络参考模型共有 `4` 层，其中需要我们熟练掌握的是
 
 MySQL 入门的话是了解 SQL 语法，进阶的话是深入底层实现原理。
 
-千万不要一上来就看《高性能 MySQL》，我曾经先读《高性能 MySQL》然后一路暴雷… 因为这本不是入门的书籍！
+千万不要一上来就看《高性能 MySQL》，我曾经先读《高性能 MySQL》然后一路暴雷…… 因为这本不是入门的书籍！
 
 我先介绍下 MySQL 的重点知识，也是面试常面的知识点：
 
@@ -373,7 +373,7 @@ Redis 官网也有一整套的命令详解，遇到需要或者不会的地方
 - 带着输入一条 url 到网页显示，期间发生了什么的问题，去学习计算机网络；
 - 带着进程、内存、磁盘是如何被操作系统管理点，去学习操作系统；
 - 带着如何实现一个高并发网络模型，去学习网络编程；
-- …
+- ……
 
 我之前也写过一篇我的看书心得，帮助到了很多同学，建议没看过的同学，去看看； [看书的一点小建议](https://mp.weixin.qq.com/s?__biz=MzUxODAzNDg4NQ==&mid=2247493177&idx=1&sn=77e32cec53e8a1aee9fa9fd3b31b19c2&scene=21#wechat_redirect)
 

cs_learn/feel_cs.md

@@ -256,7 +256,7 @@ Google 推出的 **BBR 算法是以测量带宽、时延来确定拥塞的拥塞
 
 Linux 4.9 版本之后都支持 BBR 算法，开启 BBR 算法的方式：
 
-```
+```plain
 net.ipv4.tcp_congestion_control=bbr
 ```
 

mysql/base/how_select.md

@@ -266,7 +266,7 @@ select * from product where id = 1;
 
 举个全表扫描的例子：
 
-```
+```plain
 select * from product where name = 'iphone';
 ```
 

mysql/base/row_format.md

@@ -392,7 +392,7 @@ Compressed 和 Dynamic 这两个行格式和 Compact 非常类似，主要的区
 
 ## 总结
 
->  MySQL 的 NULL 值是怎么存放的？
+> MySQL 的 NULL 值是怎么存放的？
 
 MySQL 的 Compact 行格式中会用「NULL 值列表」来标记值为 NULL 的列，NULL 值并不会存储在行格式中的真实数据部分。
 

mysql/buffer_pool/buffer_pool.md

@@ -49,7 +49,7 @@ Buffer Pool  除了缓存「索引页」和「数据页」，还包括了 undo 
 
 上图中控制块和缓存页之间灰色部分称为碎片空间。
 
->  为什么会有碎片空间呢？
+> 为什么会有碎片空间呢？
 
 你想想啊，每一个控制块都对应一个缓存页，那在分配足够多的控制块和缓存页后，可能剩余的那点儿空间不够一对控制块和缓存页的大小，自然就用不到喽，这个用不到的那点儿内存空间就被称为碎片了。
 
@@ -227,7 +227,7 @@ MySQL 是这样做的，进入到 young 区域条件增加了一个**停留在 o
 
 也就说，**只有同时满足「被访问」与「在 old 区域停留时间超过 1 秒」两个条件，才会被插入到 young 区域头部**，这样就解决了 Buffer Pool  污染的问题。
 
-另外，MySQL 针对 young 区域其实做了一个优化，为了防止 young 区域节点频繁移动到头部。young 区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4被访问了才会。
+另外，MySQL 针对 young 区域其实做了一个优化，为了防止 young 区域节点频繁移动到头部。young 区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4 被访问了才会。
 
 ### 脏页什么时候会被刷入磁盘？
 

mysql/index/2000w.md

@@ -14,7 +14,7 @@
 
 ## **实验**
 
-实验一把看看… 建一张表
+实验一把看看…… 建一张表
 
 ```sql
 CREATE TABLE person(

mysql/index/count.md

@@ -73,7 +73,7 @@ select count(id) from t_order;
 
 用下面这条语句作为例子：
 
-```
+```plain
 select count(1) from t_order;
 ```
 

mysql/index/index_interview.md

@@ -10,7 +10,7 @@
 - 什么时候不需要创建索引？
 - 什么情况下索引会失效？
 - 有什么优化索引的方法？
-- .....
+- ……
 
 今天就带大家，夯实 MySQL 索引的知识点。
 
@@ -257,13 +257,13 @@ ON table_name(column_name(length));
 
 通过将多个字段组合成一个索引，该索引就被称为联合索引。
 
-比如，将商品表中的 product_no 和 name 字段组合成联合索引` (product_no, name)`，创建联合索引的方式如下：
+比如，将商品表中的 product_no 和 name 字段组合成联合索引`(product_no, name)`，创建联合索引的方式如下：
 
 ```sql
 CREATE INDEX index_product_no_name ON product(product_no, name);
 ```
 
-联合索引` (product_no, name)` 的 B+Tree 示意图如下：
+联合索引`(product_no, name)` 的 B+Tree 示意图如下：
 
 ![联合索引](https://cdn.xiaolincoding.com/gh/xiaolincoder/mysql/索引/联合索引.drawio.png)
 
@@ -349,7 +349,7 @@ Q2 和 Q1 的查询语句很像，唯一的区别就是 a 字段的查询条件
 
 通过 Q2 查询语句我们可以知道，虽然 a 字段使用了 >= 进行范围查询，但是联合索引的最左匹配原则并没有在遇到 a 字段的范围查询（ >=）后就停止匹配了，b 字段还是可以用到了联合索引的。
 
-> Q3: ` SELECT * FROM t_table WHERE a BETWEEN 2 AND 8 AND b = 2`，联合索引（a, b）哪一个字段用到了联合索引的 B+Tree？
+> Q3: `SELECT * FROM t_table WHERE a BETWEEN 2 AND 8 AND b = 2`，联合索引（a, b）哪一个字段用到了联合索引的 B+Tree？
 
 Q3 查询条件中 `a BETWEEN 2 AND 8` 的意思是查询 a 字段的值在 2 和 8 之间的记录。不同的数据库对 BETWEEN ... AND 处理方式是有差异的。在 MySQL 中，BETWEEN 包含了 value1 和 value2 边界值，类似于 \>= and =<。而有的数据库则不包含 value1 和 value2 边界值（类似于 > and <）。
 
@@ -361,7 +361,7 @@ Q3 查询条件中 `a BETWEEN 2 AND 8` 的意思是查询 a 字段的值在 2 
 
 通过 Q3 查询语句我们可以知道，虽然 a 字段使用了 BETWEEN 进行范围查询，但是联合索引的最左匹配原则并没有在遇到 a 字段的范围查询（BETWEEN）后就停止匹配了，b 字段还是可以用到了联合索引的。
 
-> Q4: ` SELECT * FROM t_user WHERE name like 'j%' and age = 22`，联合索引（name, age）哪一个字段用到了联合索引的 B+Tree？
+> Q4: `SELECT * FROM t_user WHERE name like 'j%' and age = 22`，联合索引（name, age）哪一个字段用到了联合索引的 B+Tree？
 
 由于联合索引（二级索引）是先按照 name 字段的值排序的，所以前缀为‘j’的 name 字段的二级索引记录都是相邻的，于是在进行索引扫描的时候，可以定位到符合前缀为‘j’的 name 字段的第一条记录，然后沿着记录所在的链表向后扫描，直到某条记录的 name 前缀不为‘j’为止。
 

mysql/index/index_lose.md

@@ -57,7 +57,7 @@ InnoDB 存储引擎根据索引类型不同，分为聚簇索引（上图就是
 
 在我们使用「主键索引」字段作为条件查询的时候，如果要查询的数据都在「聚簇索引」的叶子节点里，那么就会在「聚簇索引」中的 B+ 树检索到对应的叶子节点，然后直接读取要查询的数据。如下面这条语句：
 
-```
+```plain
 // id 字段为主键索引
 select * from t_user where id=1;
 ```
@@ -69,14 +69,14 @@ select * from t_user where id=1;
 
 上面这个过程叫做**回表**，如下面这条语句：
 
-```
+```plain
 // name 字段为二级索引
 select * from t_user where name="林某";
 ```
 
 在我们使用「二级索引」字段作为条件查询的时候，如果要查询的数据在「二级索引」的叶子节点，那么只需要在「二级索引」的 B+ 树找到对应的叶子节点，然后读取要查询的数据，这个过程叫做**覆盖索引**。如下面这条语句：
 
-```
+```plain
 // name 字段为二级索引
 select id from t_user where name="林某";
 ```
@@ -93,7 +93,7 @@ select id from t_user where name="林某";
 
 比如下面的 like 语句，查询 name 后缀为「林」的用户，执行计划中的 type=ALL 就代表了全表扫描，而没有走索引。
 
-```
+```plain
 // name 字段为二级索引
 select * from t_user where name like '%林';
 ```
@@ -102,7 +102,7 @@ select * from t_user where name like '%林';
 
 如果是查询 name 前缀为林的用户，那么就会走索引扫描，执行计划中的 type=range 表示走索引扫描，key=index_name 看到实际走了 index_name 索引：
 
-```
+```plain
 // name 字段为二级索引
 select * from t_user where name like '林%';
 ```
@@ -133,7 +133,7 @@ select * from t_user where name like '林%';
 
 比如下面这条语句查询条件中对 name 字段使用了 LENGTH 函数，执行计划中的 type=ALL，代表了全表扫描：
 
-```
+```plain
 // name 为二级索引
 select * from t_user where length(name)=6;
 ```
@@ -148,7 +148,7 @@ select * from t_user where length(name)=6;
 
 举个例子，我通过下面这条语句，对 length(name) 的计算结果建立一个名为 idx_name_length 的索引。
 
-```
+```plain
 alter table t_user add key idx_name_length ((length(name)));
 ```
 
@@ -162,7 +162,7 @@ alter table t_user add key idx_name_length ((length(name)));
 
 比如，下面这条查询语句，执行计划中 type = ALL，说明是通过全表扫描的方式查询数据的：
 
-```
+```plain
 explain select * from t_user where id + 1 = 10;
 ```
 
@@ -194,7 +194,7 @@ explain select * from t_user where id + 1 = 10;
 
 然后我在条件查询中，用整型作为输入参数，此时执行计划中 type = ALL，所以是通过全表扫描来查询数据的。
 
-```
+```plain
 select * from t_user where phone = 1300000001;
 ```
 
@@ -204,7 +204,7 @@ select * from t_user where phone = 1300000001;
 
 我们再看第二个例子，id 是整型，但是下面这条语句还是走了索引扫描的。
 
-```
+```plain
  explain select * from t_user where id = '1';
 ```
 
@@ -227,29 +227,29 @@ select * from t_user where phone = 1300000001;
 
 前面的例子一中的查询语句，我也跟大家说了是会走全表扫描：
 
-```
+```plain
 //例子一的查询语句
 select * from t_user where phone = 1300000001;
 ```
 
 这是因为 phone 字段为字符串，所以 MySQL 要会自动把字符串转为数字，所以这条语句相当于：
 
-```
+```plain
 select * from t_user where CAST(phone AS signed int) = 1300000001;
 ```
 
 可以看到，**CAST 函数是作用在了 phone 字段，而 phone 字段是索引，也就是对索引使用了函数！而前面我们也说了，对索引使用函数是会导致索引失效的**。
 
 例子二中的查询语句，我跟大家说了是会走索引扫描：
 
-```
+```plain
 //例子二的查询语句
 select * from t_user where id = "1";
 ```
 
 这时因为字符串部分是输入参数，也就需要将字符串转为数字，所以这条语句相当于：
 
-```
+```plain
 select * from t_user where id = CAST("1" AS signed int);
 ```
 
@@ -305,7 +305,7 @@ MySQL 5.5 的话，前面 a 会走索引，在联合索引找到主键值后，
 
 举个例子，比如下面的查询语句，id 是主键，age 是普通列，从执行计划的结果看，是走了全表扫描。
 
-```
+```plain
 select * from t_user where id = 1 or age = 18;
 ```
 

mysql/index/why_index_chose_bpuls_tree.md

@@ -183,7 +183,7 @@ B 树进行单个索引查询时，最快可以在 O(1) 的时间代价内就查
 
 但是 B 树的查询波动会比较大，因为每个节点即存索引又存记录，所以有时候访问到了非叶子节点就可以找到索引，而有时需要访问到叶子节点才能找到索引。
 
-**B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少**。
+**B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O 次数会更少**。
 
 ### 2、插入和删除效率
 
@@ -255,7 +255,7 @@ B 树和 B+ 都是通过多叉树的方式，会将树的高度变矮，所以
 
 但是 MySQL 默认的存储引擎 InnoDB 采用的是 B+ 作为索引的数据结构，原因有：
 
-- B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少。
+- B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O 次数会更少。
 - B+ 树有大量的冗余节点（所有非叶子节点都是冗余索引），这些冗余索引让 B+ 树在插入、删除的效率都更高，比如删除根节点的时候，不会像 B 树那样会发生复杂的树的变化；
 - B+ 树叶子节点之间用链表连接了起来，有利于范围查询，而 B 树要实现范围查询，因此只能通过树的遍历来完成范围查询，这会涉及多个节点的磁盘 I/O 操作，范围查询效率不如 B+ 树。