docs：分布式理论知识优化完善（改动很大）

Author: Snailclimb

README.md

@@ -329,7 +329,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle.
 - [CAP 理论和 BASE 理论解读](https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html)
 - [Paxos 算法解读](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html)
 - [Raft 算法解读](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html)
-- [Gossip 协议详解](https://javaguide.cn/distributed-system/protocol/gossip-protocl.html)
+- [Gossip 协议详解](https://javaguide.cn/distributed-system/protocol/gossip-protocol.html)
 - [一致性哈希算法详解](https://javaguide.cn/distributed-system/protocol/consistent-hashing.html)
 
 ### RPC

README_EN.md

@@ -64,6 +64,7 @@ Recommended to read through online reading platforms for better experience and f
 - [ArrayList Core Source Code + Expansion Mechanism Analysis](./docs/java/collection/arraylist-source-code.md)
 - [LinkedList Core Source Code Analysis](./docs/java/collection/linkedlist-source-code.md)
 - [HashMap Core Source Code + Underlying Data Structure Analysis](./docs/java/collection/hashmap-source-code.md)
+
 # Java Collection & Concurrency Series
 
 ## Collection
@@ -128,6 +129,7 @@ The JVM part mainly refers to the [JVM Specification - Java 8](https://docs.orac
 - [Java 18 New Features Overview](./docs/java/new-features/java18.md)
 - [Java 19 New Features Overview](./docs/java/new-features/java19.md)
 - [Java 20 New Features Overview](./docs/java/new-features/java20.md)
+
 # Overview of Java 21, 22, 23, 24, and 25 New Features
 
 ## Computer Fundamentals
@@ -169,7 +171,7 @@ The JVM part mainly refers to the [JVM Specification - Java 8](https://docs.orac
 - [Linear Data Structures: Arrays, Linked Lists, Stacks, Queues](./docs/cs-basics/data-structure/linear-data-structure.md)
 - [Graphs](./docs/cs-basics/data-structure/graph.md)
 - [Heaps](./docs/cs-basics/data-structure/heap.md)
-- [Trees](./docs/cs-basics/data-structure/tree.md): Focus on [Red-Black Trees](./docs/cs-basics/data-structure/red-black-tree.md), B-, B+, B* Trees, and LSM Trees
+- [Trees](./docs/cs-basics/data-structure/tree.md): Focus on [Red-Black Trees](./docs/cs-basics/data-structure/red-black-tree.md), B-, B+, B\* Trees, and LSM Trees
 
 Other Commonly Used Data Structures:
 
@@ -205,6 +207,7 @@ Additionally, [GeeksforGeeks](https://www.geeksforgeeks.org/fundamentals-of-algo
 ### MySQL
 
 **Knowledge Points/Interview Questions Summary:**
+
 # MySQL Common Knowledge Points & Interview Questions Summary (Must-Read :+1:)
 
 - [MySQL Common Knowledge Points & Interview Questions Summary](./docs/database/mysql/mysql-questions-01.md)
@@ -290,6 +293,7 @@ Additionally, [GeeksforGeeks](https://www.geeksforgeeks.org/fundamentals-of-algo
 #### Spring/SpringBoot (Must-Read :+1:)
 
 **Knowledge Points/Interview Questions Summary**:
+
 - [Summary of Common Spring Knowledge Points and Interview Questions](./docs/system-design/framework/spring/spring-knowledge-and-questions-summary.md)
 - [Summary of Common SpringBoot Knowledge Points and Interview Questions](./docs/system-design/framework/spring/springboot-knowledge-and-questions-summary.md)
 - [Summary of Common Spring/SpringBoot Annotations](./docs/system-design/framework/spring/spring-common-annotations.md)
@@ -338,7 +342,7 @@ Additionally, [GeeksforGeeks](https://www.geeksforgeeks.org/fundamentals-of-algo
 - [Interpretation of CAP Theory and BASE Theory](https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html)
 - [Interpretation of Paxos Algorithm](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html)
 - [Interpretation of Raft Algorithm](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html)
-- [Detailed Explanation of Gossip Protocol](https://javaguide.cn/distributed-system/protocol/gossip-protocl.html)
+- [Detailed Explanation of Gossip Protocol](https://javaguide.cn/distributed-system/protocol/gossip-protocol.html)
 - [Detailed Explanation of Consistent Hashing Algorithm](https://javaguide.cn/distributed-system/protocol/consistent-hashing.html)
 
 ### RPC
@@ -364,6 +368,7 @@ Additionally, [GeeksforGeeks](https://www.geeksforgeeks.org/fundamentals-of-algo
 - [Design Guide for Distributed ID](https://javaguide.cn/distributed-system/distributed-id-design.html)
 
 ### Distributed Lock
+
 # Distributed Locks
 
 - [Introduction to Distributed Locks](https://javaguide.cn/distributed-system/distributed-lock.html)
@@ -443,4 +448,4 @@ Deploying multiple instances of the same service to avoid single point of failur
 
 If you want to stay up-to-date with my latest articles and share my valuable content, you can follow my official public account.
 
-![JavaGuide Official Public Account](https://oss.javaguide.cn/github/javaguide/gongzhonghaoxuanchuan.png)
+![JavaGuide Official Public Account](https://oss.javaguide.cn/github/javaguide/gongzhonghaoxuanchuan.png)

docs/.vuepress/sidebar/index.ts

@@ -465,7 +465,7 @@ export default sidebar({
             "cap-and-base-theorem",
             "paxos-algorithm",
             "raft-algorithm",
-            "gossip-protocl",
+            "gossip-protocol",
             "consistent-hashing",
           ],
         },

docs/database/mysql/mysql-index.md

@@ -365,7 +365,7 @@ ALTER TABLE `cus_order` ADD INDEX id_score_name(score, name);
 
 最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据，这样可以提高查询效率。
 
-最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配（相关阅读：[联合索引的最左匹配原则全网都在说的一个错误结论](https://mp.weixin.qq.com/s/8qemhRg5MgXs1So5YCv0fQ)）。
+最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配。
 
 假设有一个联合索引 `(column1, column2, column3)`，其从左到右的所有前缀为 `(column1)`、`(column1, column2)`、`(column1, column2, column3)`（创建 1 个联合索引相当于创建了 3 个索引），包含这些列的所有查询都会走索引而不会全表扫描。
 
@@ -476,6 +476,108 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
 - **频繁需要排序的字段**：索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。
 - **被经常频繁用于连接的字段**：经常用于连接的字段可能是一些外键列，对于外键列并不一定要建立外键，只是说该列涉及到表与表的关系。对于频繁被连接查询的字段，可以考虑建立索引，提高多表连接查询的效率。
 
+### 避免索引失效
+
+索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这些：
+
+**`SELECT *` 查询（成本权衡）**
+
+- `SELECT *` **不会直接导致索引失效**。如果 `WHERE` 条件符合索引规则，索引依然会被使用。
+- 它会导致**回表成本增加**。如果查询需要的字段不在索引中（非覆盖索引），数据库需要拿着主键回聚簇索引查数据。当数据量较大时，优化器会对比“索引查找 + 回表”与“直接全表扫描”的成本，若前者成本过高，优化器会**主动放弃索引**选择全表扫描。
+- `SELECT *` 还会网络传输和数据处理的浪费。尽量只查询需要的字段，利用**覆盖索引**减少回表。
+
+**违背最左前缀原则**
+
+- 最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据，这样可以提高查询效率。
+- 最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配。
+- MySQL 8.0.13 版本引入了索引跳跃扫描（Index Skip Scan，简称 ISS），它可以在某些索引查询场景下提高查询效率。在没有 ISS 之前，不满足最左前缀匹配原则的联合索引查询中会执行全表扫描。而 ISS 允许 MySQL 在某些情况下避免全表扫描，即使查询条件不符合最左前缀。不过，这个功能比较鸡肋， 和 Oracle 中的没法比，MySQL 8.0.31 还报告了一个 bug：[Bug #109145 Using index for skip scan cause incorrect result](https://bugs.mysql.com/bug.php?id=109145)（后续版本已经修复）。个人建议知道有这个东西就好，不需要深究，实际项目也不一定能用上。
+
+失效示例：
+
+```sql
+-- 索引：(sname, s_code, address)
+WHERE s_code = 1;                  -- 跳过最左列 sname，失效
+WHERE sname = 'A' AND address = 'Shanghai'; -- 跳过中间列 s_code，仅 sname 走索引
+WHERE sname = 'A' AND s_code > 1 AND address = 'Shanghai'; -- 范围查询后，address 失效
+```
+
+**在索引列上进行计算、函数或类型转换**
+
+- 索引存储的是字段的**原始值**。对字段进行操作后，数据库无法利用索引树的有序性，只能全表扫描后计算。
+- MySQL 8.0 支持**函数索引**，可针对计算后的值建索引，但使用场景有限，首选还是优化 SQL 写法。
+
+失效示例：
+
+```sql
+WHERE height + 1 = 170;            -- 对索引列进行计算
+WHERE DATE(create_time) = '2022-01-01'; -- 对索引列使用函数
+```
+
+优化建议：
+
+```sql
+WHERE height = 169;                -- 将计算移到等号右边
+WHERE create_time BETWEEN '2022-01-01 00:00:00' AND '2022-01-01 23:59:59';
+```
+
+**`LIKE` 模糊查询以通配符开头**
+
+- `LIKE` 查询必须以具体字符开头才能利用索引有序性，例如 `WHERE sname LIKE 'Guide%'; `。
+- 这是因为B+ 树是从左到右排序的。前缀通配符（`%`）破坏了有序性，无法定位起始点。
+
+失效示例：
+
+```sql
+WHERE sname LIKE '%Guide';          -- 前缀模糊，全表扫描
+WHERE sname LIKE '%Guide%';         -- 前后模糊，全表扫描
+```
+
+**`OR` 连接条件使用不当**
+
+- 如果 `OR` 两边的列中**有一列没有索引**，通常会导致整个查询放弃索引，走全表扫描。
+- 确保 `OR` 两边的列都建有索引，或改写为 `UNION ALL`。
+
+失效示例：
+
+```sql
+-- 假设 sname 有索引，address 无索引
+WHERE sname = '学生 1' OR address = '上海'; -- 索引失效，全表扫描
+```
+
+**`N` / `NOT IN` 使用不当**
+
+- **`IN`**：当 `IN` 列表中的值太多（通常超过 200 个，由 `eq_range_index_dive_limit` 参数决定）或查询范围覆盖了太多行，会导致索引失效。
+- **`NOT IN`**：在大多数情况下会引发全表扫描，因为它需要证明“不属于”某个集合，这在 B+ 树中通常需要遍历所有叶子节点。
+
+失效示例：
+
+```sql
+WHERE s_code IN (1, 2, 3 ... 500); -- 列表过长可能失效
+WHERE s_code NOT IN (1, 2, 3);     -- 通常失效
+```
+
+**隐式类型转换**
+
+这是开发中最隐蔽的坑，转换的方向决定了索引的生死。
+
+- 字段类型为字符串，查询条件未加引号（如 `varchar` 字段查 `WHERE col = 123`）；或字段类型为数字，查询条件加了引号且字符集不匹配。
+- MySQL 会自动进行类型转换，导致索引列值发生变化，无法匹配索引树。
+- 详细介绍：[MySQL隐式转换造成索引失效](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html) 。
+
+**`ORDER BY` 排序优化陷阱**
+
+即使 `WHERE` 条件精准，如果 `ORDER BY` 处理不好，依然会出现慢查询。
+
+- 如果查询走了索引 A，但排序要求字段 B，或者需要回表的数据量太大导致优化器放弃索引排序，就会触发 `Using filesort`（内存/磁盘排序）。
+- 利用**覆盖索引**同时满足 `WHERE` 和 `ORDER BY`。例如索引为 `(name, age)`，查询 `SELECT name, age FROM users WHERE name = 'A' ORDER BY age` 是极其高效的。
+
+**最后，总结一个口诀**
+
+- 全值匹配我最爱，最左前缀不能改。
+- 范围之后全失效，函数计算索引败。
+- 模糊首位莫加百分号，类型转换要避开。
+- OR 连接需谨慎，覆盖索引避回表。
+
 ### 被频繁更新的字段应该慎重建立索引
 
 虽然索引能带来查询上的效率，但是维护索引的成本也是不小的。 如果一个字段不被经常查询，反而被经常修改，那么就更不应该在这种字段上建立索引了。
@@ -500,21 +602,6 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
 
 前缀索引仅限于字符串类型，较普通索引会占用更小的空间，所以可以考虑使用前缀索引带替普通索引。
 
-### 避免索引失效
-
-索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这些：
-
-- ~~使用 `SELECT *` 进行查询;~~ `SELECT *` 不会直接导致索引失效（如果不走索引大概率是因为 where 查询范围过大导致的），但它可能会带来一些其他的性能问题比如造成网络传输和数据处理的浪费、无法使用索引覆盖；
-- 创建了组合索引，但查询条件未遵守最左匹配原则；
-- 在索引列上进行计算、函数、类型转换等操作；
-- 以 % 开头的 LIKE 查询比如 `LIKE '%abc';`；
-- 查询条件中使用 OR，且 OR 的前后条件中有一个列没有索引，涉及的索引都不会被使用到；
-- IN 的取值范围较大时会导致索引失效，走全表扫描（NOT IN 和 IN 的失效场景相同）；
-- 发生[隐式转换](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html)；
-- ……
-
-推荐阅读这篇文章：[美团暑期实习一面：MySQl 索引失效的场景有哪些？](https://mp.weixin.qq.com/s/mwME3qukHBFul57WQLkOYg)。
-
 ### 删除长期未使用的索引
 
 删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗。

docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md

@@ -60,7 +60,7 @@ ZooKeeper 将数据保存在内存中，性能是不错的。 在“读”多于
 - **原子性：** 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
 - **单一系统映像：** 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
 - **可靠性：** 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。
-- **实时性：** 一旦数据发生变更，其他节点会实时感知到。每个客户端的系统视图都是最新的。
+- **顺序一致性**：所有客户端看到的数据变更顺序是一致的，按照操作被提交的全局 FIFO 顺序进行更新。但这并不保证变更会立即传播到所有节点。
 - **集群部署**：3~5 台（最好奇数台）机器就可以组成一个集群，每台机器都在内存保存了 ZooKeeper 的全部数据，机器之间互相通信同步数据，客户端连接任何一台机器都可以。
 - **高可用：**如果某台机器宕机，会保证数据不丢失。集群中挂掉不超过一半的机器，都能保证集群可用。比如 3 台机器可以挂 1 台，5 台机器可以挂 2 台。
 

docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md

@@ -10,7 +10,7 @@ tag:
 
 ## 什么是 ZooKeeper
 
-`ZooKeeper` 由 `Yahoo` 开发，后来捐赠给了 `Apache` ，现已成为 `Apache` 顶级项目。`ZooKeeper` 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 `Paxos` 算法的 `ZAB` 协议完成的。其主要功能包括：配置维护、分布式同步、集群管理等。
+`ZooKeeper` 由 `Yahoo` 开发，后来捐赠给了 `Apache` ，现已成为 `Apache` 顶级项目。`ZooKeeper` 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过专门为 ZooKeeper 设计的 **ZAB（ZooKeeper Atomic Broadcast）** 协议完成的。其主要功能包括：配置维护、分布式同步、集群管理等。
 
 简单来说， `ZooKeeper` 是一个 **分布式协调服务框架** 。分布式？协调服务？这啥玩意？🤔🤔