diff --git a/Chapter7.md b/Chapter7.md
index 4dfa305..2e8c8f5 100644
--- a/Chapter7.md
+++ b/Chapter7.md
@@ -148,6 +148,8 @@ Figure 7-6. Side effects of redo log optimization at low concurrency: more I/O f
 
 From the figure, it can be observed that with 3 concurrent read-write operations, each transaction averages over 9 flushes, while at 200 concurrency, it decreases to around 1 flush per transaction. These average flush counts can be further optimized, but it requires finding a balance: timely flushing activates user threads more quickly but incurs higher I/O overhead, whereas delaying flushing reduces I/O costs but may increase user response times.
 
+It is important to note that the Redo log improvements are primarily focused on enhancing overall performance in high-concurrency environments, but they perform poorly in scenarios with fewer than 50 concurrent connections. Many users have complained that MySQL 8.0's performance falls short of expectations, and this is the root cause. The next version will provide a detailed explanation of this issue.
+
 ### 7.1.2 Optimizing Lock-Sys Through Latch Sharding
 
 In MySQL 5.7, the lock system experienced significant latch contention problems, which severely impacted throughput under high concurrency. During transaction execution, frequent locking and unlocking operations require acquiring a global latch. When many user threads compete for this global latch, MySQL's scalability becomes a major concern.
diff --git a/Chapter8.md b/Chapter8.md
index 61da482..9511f0d 100644
--- a/Chapter8.md
+++ b/Chapter8.md
@@ -145,7 +145,7 @@ From the figure, it is evident that after applying the patch, the rate of throug
 
 Addressing this problem directly presents considerable challenges, particularly for MySQL developers unfamiliar with query execution plans. Using logical reasoning and a systematic approach to identify and address code differences before and after the problem arose is a more elegant problem-solving method, though it is complex.
 
-It is noteworthy that no regression testing problems were encountered after applying the patch, demonstrating high stability and providing a solid foundation for future performance improvements. Currently, MySQL 8.0.38 still hasn't solved this problem, suggesting potential shortcomings in MySQL's testing system. Given the complexity of MySQL databases, users should exercise caution when upgrading and consider using tools like TCPCopy [60] to avoid potential regression testing problems.
+It is noteworthy that no regression testing problems were encountered after applying the patch, demonstrating high stability and providing a solid foundation for future performance improvements. Currently, MySQL 8.0.39 still hasn't solved this problem, suggesting potential shortcomings in MySQL's testing system. Given the complexity of MySQL databases, users should exercise caution when upgrading and consider using tools like TCPCopy [60] to avoid potential regression testing problems.
 
 ### 8.1.2 Improving Binlog Group Commit Scalability