Remove all non-English characters

Author: wangbin579

Appendix.md

@@ -203,7 +203,7 @@ Profile-Guided Optimization (PGO) is a compiler technique that uses profiling da
 
 **24 Read Committed Isolation Level**
 
-Put simply, the Read Committed isolation level ensures that any data read during a transaction is committed at the time of reading. It prevents the reader from seeing uncommitted or 'dirty' data. However, it doesn¡¯t guarantee that if the transaction reads the same data again, it will be the same; the data can change after being read.
+Put simply, the Read Committed isolation level ensures that any data read during a transaction is committed at the time of reading. It prevents the reader from seeing uncommitted or 'dirty' data. However, it doesn't guarantee that if the transaction reads the same data again, it will be the same; the data can change after being read.
 
 **25 Replication**
 
@@ -285,7 +285,7 @@ MySQL uses the classic request-response model: clients send SQL queries to the M
 
 ![](media/f3b8490d4e41a8da5e954aabf0a4aacf.png)
 
-Here¡¯s how MySQL Server processes a SQL request with a detailed example. Suppose a user sends the following SQL statement from a MySQL client to MySQL Server:
+Here's how MySQL Server processes a SQL request with a detailed example. Suppose a user sends the following SQL statement from a MySQL client to MySQL Server:
 
 ```
 select name from student where id=1;
@@ -369,14 +369,17 @@ The execution plan for this SQL query can be viewed using the *'explain'* statem
 
 The execution process with an index is as follows:
 
-1.  The executor requests the storage engine to locate the first index record matching the query condition (e.g., name LIKE 'wang%').
-2.  The storage engine retrieves and returns the matching index record to the Server layer.
-3.  The executor checks if the record meets the additional query conditions (e.g., id \< 3).
+1. The executor requests the storage engine to locate the first index record matching the query condition (e.g., name LIKE 'wang%').
 
-    If conditions are met, the corresponding name is added to the network buffer, unless it is full. If conditions are not met, the executor skips the record and requests the next one from the storage engine.
+2. The storage engine retrieves and returns the matching index record to the Server layer.
 
-4.  This cycle continues as the executor repeatedly requests and evaluates the next index record that matches the query condition until all relevant index records are processed.
-5.  Once the storage engine indicates that all relevant index records have been processed, the executor exits the loop and sends the collected results to the client.
+3. The executor checks if the record meets the additional query conditions (e.g., id \< 3).
+
+   If conditions are met, the corresponding name is added to the network buffer, unless it is full. If conditions are not met, the executor skips the record and requests the next one from the storage engine.
+
+4. This cycle continues as the executor repeatedly requests and evaluates the next index record that matches the query condition until all relevant index records are processed.
+
+5. Once the storage engine indicates that all relevant index records have been processed, the executor exits the loop and sends the collected results to the client.
 
 Using an index allows the storage engine to quickly locate necessary records, bypassing the need to scan the entire table. In general, this significantly improves execution efficiency and speeds up the query.
 

Chapter1.md

@@ -14,13 +14,13 @@ Here are some classic problems listed, along with typical resolutions in real-wo
 
 The following figure illustrates the relationship between TPC-C throughput and concurrency in MySQL 5.7.39 under a specific configuration. This includes setting the transaction isolation level to Read Committed and adjusting the *innodb_spin_wait_delay* parameter to mitigate throughput degradation.
 
-<img src="media\image-20240829080057376.png" alt="image-20240829080057376" style="zoom:150%;" />
+<img src="media/image-20240829080057376.png" alt="image-20240829080057376" style="zoom:150%;" />
 
 Figure 1-1. Scalability problems in MySQL 5.7.39 during BenchmarkSQL testing.
 
 From the figure, it is evident that scalability problems significantly limit the increase in MySQL throughput. For example, after 100 concurrency, the throughput begins to decline. Due to MySQL's historical scalability challenges, Percona even open-sourced a thread pool to address these problems. The following figure illustrates the relationship between TPC-C throughput and concurrency after configuring the Percona thread pool.
 
-<img src="media\image-20240829080659528.png" alt="image-20240829080659528" style="zoom:150%;" />
+<img src="media/image-20240829080659528.png" alt="image-20240829080659528" style="zoom:150%;" />
 
 Figure 1-2. Percona thread pool mitigates scalability problems in MySQL 5.7.39.
 
@@ -62,7 +62,7 @@ Meta's case study demonstrates that the new solution based on the Raft protocol
 
 With the transaction isolation level set to Read Committed, simulations based on Group Replication were conducted under various network latency conditions.
 
-The deployment setup of Group Replication is illustrated as follows: On machine A, two MySQL instances are deployed¡ªone serving as the primary and the other as the secondary. These two instances form the majority and communicate via localhost. Machine B hosts a third instance deployed as a member of the cluster, with a network latency of X milliseconds.
+The deployment setup of Group Replication is illustrated as follows: On machine A, two MySQL instances are deployed—one serving as the primary and the other as the secondary. These two instances form the majority and communicate via localhost. Machine B hosts a third instance deployed as a member of the cluster, with a network latency of X milliseconds.
 
 ![](media/792556dcff5f267dcc5aefeb5ef0d035.png)
 
@@ -72,15 +72,15 @@ In theory, with a majority-based mechanism, a cluster of 3 nodes only needs resp
 
 Throughput comparisons over time have been conducted for machine B in scenarios within the same data center and across data centers with latencies of 10ms, 100ms, and 1000ms. Specific results are illustrated in the following figure.
 
-<img src="media\image-20240829081015123.png" alt="image-20240829081015123" style="zoom:150%;" />
+<img src="media/image-20240829081015123.png" alt="image-20240829081015123" style="zoom:150%;" />
 
 Figure 1-7. Performance testing results of the default multi-leader Paxos algorithm.
 
 From the figure, it is evident that under the default mode of Group Replication, throughput across data centers deviates significantly from theoretical expectations. For example, in scenarios with 10ms network latency, the cluster's throughput decreases to one-fifth of its original level. To address this discrepancy, starting with MySQL 8.0.27, the *group_replication_paxos_single_leader* option was introduced. Enabling this option utilizes the single leader Paxos algorithm instead of the default multi-leader Paxos algorithm.
 
 After configuring Group Replication to use the single leader Paxos algorithm, tests were conducted under the same conditions using the SysBench testing tool. The test results are as follows.
 
-<img src="media\image-20240829081049988.png" alt="image-20240829081049988" style="zoom:150%;" />
+<img src="media/image-20240829081049988.png" alt="image-20240829081049988" style="zoom:150%;" />
 
 Figure 1-8. Performance testing results of the single-leader Paxos algorithm.