Add Chinese translations for book content

Translate the following files to Chinese:
- README.md -> README_zh.md
- Preface.md -> Preface_zh.md
- Part1-5.md -> Part1-5_zh.md
- Chapter1-4 and subchapters -> Chapter*_zh.md
- Chapter6, 7, 12 -> Chapter*_zh.md
- References.md -> References_zh.md
- Appendix.md -> Appendix_zh.md

Total: 28 translated files

Author: claude

Appendix_zh.md

@@ -0,0 +1,82 @@
+# 第 12 章：未来方向
+
+坚实的基础对于推动 MySQL 朝着更复杂的目标发展至关重要。一旦解决了可扩展性和高可用性问题，重点可以转移到以下发展领域。
+
+## 12.1 超图算法的改进
+
+目标是使超图算法实用化并增强其性能，重点探索并行方法。
+
+## 12.2 Paxos 日志持久化功能的实际实现
+
+目前，Paxos 日志持久化已被证明是可行的。可以努力实现基于 Paxos 日志的崩溃恢复，从而使 Paxos 日志持久化真正实用化。
+
+## 12.3 解决并发视图变更挑战
+
+目前，组复制面临具有挑战性的并发视图变更问题。尽管这些问题发生的频率不高，但可以努力完全解决它们。
+
+## 12.4 进一步提高可扩展性
+
+MySQL 的可扩展性可以在以下领域进一步提高：
+
+1. 消除额外的锁存器瓶颈，特别是在非分区环境中。
+2. 提高长期性能测试的稳定性。
+3. 在主流 NUMA 环境中提高 MySQL 的 NUMA 感知能力。
+4. 解决 Performance Schema 在 MySQL 从库回放过程中对 NUMA 环境的不利影响。
+
+## 12.5 进一步提高低并发下的 SQL 性能
+
+与 5.7 相比，MySQL 8.0 在低并发下的性能明显较差，这需要纠正以避免影响升级到 8.0 的用户。
+
+## 12.6 进一步增强分析型 SQL 查询的性能
+
+目前，MySQL 使用单线程模式处理单个 SQL 查询，这可能导致某些统计查询的处理时间过长，严重影响用户体验。未来的改进将专注于为统计 SQL 查询实现多线程处理，以减少处理时间并提高性能。
+
+## 12.7 提高 Binlog 文件压缩效率和运行稳定性
+
+降低用户存储成本是一个关键重点。优化 MySQL binlog 压缩率和运行稳定性具有显著的改进潜力，这可能带来实质性的好处。
+
+## 12.8 推进 MySQL 主库对大事务的管理
+
+在主流 NUMA 环境中，MySQL 主库在处理大事务方面的效率不佳。这一领域具有显著的优化潜力，可能成为未来改进的关键点之一。
+
+## 12.9 进一步探索更好的内存分配工具
+
+目前，jemalloc 4.5 是找到的最好的内存分配工具，但它在 ARM 架构上存在内存消耗高和不稳定的问题。未来的关键重点可能是开发更高效和更稳定的内存分配工具。
+
+## 12.10 集成高性能文件系统
+
+为 MySQL 增强更好的文件系统，特别是提高 MySQL 从库回放的性能。
+
+## 12.11 将 AI 引入 MySQL 系统
+
+将 AI 与 MySQL 集成以实现自动化参数调优和基于学习的数据库监控可能是未来的另一个关键重点。
+
+### 12.11.1 参数调优
+
+集成 AI 进行参数优化可以显著减少 DBA 的工作量。适合 AI 驱动优化的关键参数包括：
+
+1. 缓冲池大小
+2. 自旋延迟设置
+3. 基于环境的动态事务节流限制
+4. 动态 XCom 缓存大小调整
+5. MySQL 从库工作线程最大队列大小
+6. Paxos 流水线实例的数量和批处理的大小
+7. 在高负载下自动调整参数以提高处理能力
+
+### 12.11.2 基于学习的数据库监控
+
+AI 可以通过确定跟踪各种数据库指标的最佳时间和方法来优化数据库监控。
+
+## 12.12 总结
+
+编程需要强大的逻辑推理能力，这对于问题解决、算法设计、调试、代码理解、性能优化和测试至关重要。它有助于分析问题、创建解决方案、纠正错误并确保软件可靠性。发展逻辑推理能力对于程序员系统性思考和构建高效、可靠的软件至关重要 [56]。
+
+MySQL 开发通常主要关注使用测试工具进行简单测试，这可能会错过发现许多问题的机会。测试 MySQL 本身就是一项艰巨的任务，仅依靠测试工具不足以暴露所有问题。不同项目和环境的优化各不相同，使用真实的在线流量使其更具针对性和有效性。因此，基于实时流量的 MySQL 优化非常有价值。
+
+MySQL 性能优化在很大程度上依赖于缓解可扩展性问题。增强版的 MySQL 已经解决了大部分可扩展性问题，为进一步优化奠定了坚实的基础。配置文件引导优化（PGO）对 MySQL 至关重要，随着可扩展性问题的改善，其重要性将继续增长。使用更好的内存分配工具可以显著提高 MySQL 主库和从库回放的性能。
+
+我们坚信，基于 Paxos 日志持久化的高可用性解决方案将成为未来的趋势。我们在组复制长期转型方面的丰富经验为实现真正的高可用性奠定了坚实的基础。MySQL 从库回放的速度决定了 MySQL 高可用性的质量。实现数百万 tpmC 范围内的回放速度是可能的，但需要持续的努力。
+
+虽然 MySQL 优化是一个漫长而曲折的过程，但我们相信 MySQL 将随着时间的推移不断改进。
+
+[下一页](References_zh.md)

Chapter12_zh.md

@@ -0,0 +1,121 @@
+# 第1章：解决 MySQL 问题的传统方法
+
+## 1.1 解决 MySQL 问题的现状
+
+解决与 MySQL 使用相关的问题通常比较简单，涉及收集信息和应用逻辑推理，这些问题通常是可以解决的。然而,解决 MySQL 本身的固有问题则要复杂得多。幸运的是,MySQL 用户足智多谋,已经设计了各种解决方案,例如实施线程池来缓解可扩展性挑战。
+
+要有效解决 MySQL 的各种问题,仅仅依靠外围的修复和补丁是不够的。必须深入问题的核心本质,全面解决这些问题才能取得有意义的进展。例如,MySQL Group Replication 一直在不稳定性方面挣扎。尽管有强大的开发努力,但持续的挑战在于采用正确的问题解决方法,导致难以减少缺陷。
+
+## 1.2 MySQL 问题是如何解决的?
+
+以下列出了一些经典问题,以及在实际 MySQL 使用场景中的典型解决方案。
+
+### 1.2.1 解决 MySQL 5.7 中的可扩展性问题
+
+下图展示了在特定配置下 MySQL 5.7.39 中 TPC-C 吞吐量与并发度之间的关系。这包括将事务隔离级别设置为读已提交(Read Committed),并调整 *innodb_spin_wait_delay* 参数以缓解吞吐量下降。
+
+<img src="media/image-20240829080057376.png" alt="image-20240829080057376" style="zoom:150%;" />
+
+图 1-1. 在 BenchmarkSQL 测试期间 MySQL 5.7.39 的可扩展性问题。
+
+从图中可以明显看出,可扩展性问题显著限制了 MySQL 吞吐量的增长。例如,在 100 并发之后,吞吐量开始下降。由于 MySQL 历史上的可扩展性挑战,Percona 甚至开源了一个线程池来解决这些问题。下图展示了配置 Percona 线程池后 TPC-C 吞吐量与并发度之间的关系。
+
+<img src="media/image-20240829080659528.png" alt="image-20240829080659528" style="zoom:150%;" />
+
+图 1-2. Percona 线程池缓解了 MySQL 5.7.39 的可扩展性问题。
+
+对于 MySQL 5.7.39,线程池有效地缓解了吞吐量下降,尽管由于固有的开销成本,它也略微降低了峰值吞吐量。在比较低并发级别的性能时,这种开销变得更加明显。
+
+随着 MySQL 8.0 版本改进了可扩展性,线程池在缓解吞吐量下降方面的效果也随之减弱。后续章节将提供实际案例来证实这一观察结果。
+
+### 1.2.2 提升 MySQL 中的 Join 性能
+
+由于 MySQL 5.7 中缺乏哈希连接(hash join)支持,以下统计 SQL 查询执行时间为 3.82 秒。
+
+![](media/47b077e25be1755b8c698aea97f51f7f.png)
+
+图 1-3. MySQL 5.7 中的非哈希连接性能。
+
+在 MySQL 8.0 中,执行计划中引入了哈希连接,提高了连接性能。对于前面提到的相同 SQL 查询,通过注释指定哈希连接将执行时间缩短到仅 1.22 秒,相比之前观察到的 3.82 秒有了显著改进。
+
+![](media/12c296b6f5d91c71b24391af9c293363.png)
+
+图 1-4. MySQL 8.0 中的哈希连接性能。
+
+这说明了 MySQL 8.0 中引入的连接执行改进,突出了其关键进步之一。
+
+### 1.2.3 MySQL 半同步复制在大规模部署中的挑战
+
+自 Paxos 协议引入以来,越来越多的数据库采用状态机复制来构建高可用集群。
+
+Paxos 协议依赖于基于集合论的多数派机制来达成共识。例如,在一个包含 3 个 MySQL 节点的集群中,2 个节点可以形成多数派。如果这 2 个节点达成共识,系统就可以持续运行。理论上,遵守这种多数派机制应该可以防止在任何异常情况下出现分歧或脑裂问题。
+
+Raft 是另一个广泛使用的协议,本质上是 Paxos 协议的简化版本。以下部分描述了 Meta 使用 Raft 协议实现 MySQL 高可用性的方案 [38],该方案简化了传统的高可用性流程。
+
+<img src="media/91bc13de07d658b009ae498b5afa4ac1.gif" style="zoom: 50%;" />
+
+图 1-5. Meta 使用 Raft 的原因。
+
+Meta 的案例研究表明,基于 Raft 协议的新解决方案简化了高可用性挑战。Raft 通常被视为 Paxos 协议的精简版本。同样,基于 Paxos 协议的 Group Replication 解决方案,如果实现正确,也可以提供一个优雅的解决方案。
+
+### 1.2.4 多数派机制的性能及其准确性
+
+在事务隔离级别设置为读已提交的情况下,基于 Group Replication 在各种网络延迟条件下进行了模拟。
+
+Group Replication 的部署设置如下:在机器 A 上,部署了两个 MySQL 实例——一个作为主节点,另一个作为从节点。这两个实例形成多数派,并通过 localhost 通信。机器 B 承载第三个实例,部署为集群的成员,网络延迟为 X 毫秒。
+
+![](media/792556dcff5f267dcc5aefeb5ef0d035.png)
+
+图 1-6. 多数派机制性能测试的部署图。
+
+理论上,在多数派机制下,一个 3 节点的集群只需要 2 个节点的响应就可以向客户端提供结果。按照这个逻辑,本地 SysBench 测试应该表现出非常高的效率。
+
+已经对机器 B 在同一数据中心内以及跨数据中心延迟为 10ms、100ms 和 1000ms 的场景下进行了随时间变化的吞吐量比较。具体结果如下图所示。
+
+<img src="media/image-20240829081015123.png" alt="image-20240829081015123" style="zoom:150%;" />
+
+图 1-7. 默认多领导者 Paxos 算法的性能测试结果。
+
+从图中可以明显看出,在 Group Replication 的默认模式下,跨数据中心的吞吐量与理论预期有很大偏差。例如,在网络延迟为 10ms 的场景中,集群的吞吐量降至原来水平的五分之一。为了解决这一差异,从 MySQL 8.0.27 开始,引入了 *group_replication_paxos_single_leader* 选项。启用此选项将使用单领导者 Paxos 算法而不是默认的多领导者 Paxos 算法。
+
+将 Group Replication 配置为使用单领导者 Paxos 算法后,使用 SysBench 测试工具在相同条件下进行了测试。测试结果如下。
+
+<img src="media/image-20240829081049988.png" alt="image-20240829081049988" style="zoom:150%;" />
+
+图 1-8. 单领导者 Paxos 算法的性能测试结果。
+
+从图中可以明显看出,单领导者模式的结果明显优于之前的结果。然而,缺点是单领导者模式只能在 MySQL 的单主模式下运行,其应用范围有限,无法应用于需要读写操作强一致性的场景。
+
+对底层 Paxos 算法的这种修改真的是最优解决方案吗?这将在接下来的章节中深入探讨。
+
+### 1.2.5 Group Replication:本地主机部署报告不可达
+
+在同一台机器上部署两个节点的 Group Replication,这些节点之间通过 localhost 通信,理论上在正常条件下不应遇到与网络相关的抖动、丢包或对等节点不可达的问题。
+
+![](media/4a72da4d419da7730675d64c4d060128.png)
+
+图 1-9. Performance Schema 显示的本地主机部署关系。
+
+在使用 BenchmarkSQL 进行 TPC-C 数据加载测试的正常压力下,MySQL 错误日志显示主节点和从节点多次报告对方不可达。
+
+以下是 MySQL 主节点错误日志的部分截图:
+
+![](media/4f558a475444869186a0641f934db534.gif)
+
+图 1-10. MySQL 主节点错误日志的部分截图。
+
+以下是 MySQL 从节点错误日志的部分截图:
+
+![](media/974f0f1b091afaba18ea375a73d87441.gif)
+
+图 1-11. MySQL 从节点错误日志的部分截图。
+
+从这些日志中,可以明显看到指示"已变得不可达(has become unreachable)"的警告。在正常条件下,像这样在本地主机场景中频繁出现"不可达"报告是意料之外的。将 Group Replication 延迟问题处理归咎于网络并非最佳做法。未来的章节将探讨对网络探测机制的增强,以解决这些误报问题。
+
+## 1.3 总结
+
+本章分析了用户如何解决 MySQL 问题。MySQL 8.0 在改进方面取得了长足进步,特别是在缓解可扩展性问题和引入对哈希连接的支持方面,这是一个积极的发展。然而,仍然存在许多未解决的问题,既有长期存在的问题,也有新出现的问题。有效解决 MySQL 问题需要对问题和相关理论有透彻的理解;否则,理解可能不完整。
+
+下一章将通过各种案例研究展示解决晦涩的 MySQL 问题所面临的巨大挑战。需要广泛的知识基础和大量的逻辑推理才能找出这些问题的根本原因。
+
+[下一页](Chapter2_zh.md)