diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md
index 8181c2ade399..f41681d2ae63 100644
--- a/performance-tuning-practices.md
+++ b/performance-tuning-practices.md
@@ -414,13 +414,13 @@ Query 平均延迟从 533 us 下降到 313 us。execute 平均延迟从 466 us 
 
 | 指标  |   场景 1 | 场景 2   | 场景 3 | 场景 4 |场景 5 | 场景 6 | 场景 7 | 对比场景 5 和场景 2 (%) | 对比场景 7 和场景 3(%) |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- |  --- |
-| query duration  | 479μs | 1120μs | 528μs | 426μs |690μs  | 533μs | 313μs | -38% | -51% |
+| query duration  | 479μs | 1120μs | 528μs | 426μs |690μs  | 533μs | 313μs | -38% | -41% |
 | QPS            | 56.3k |  24.2k | 19.7k | 22.1k | 30.9k | 34.9k | 40.9k | +28% | +108% |
 
 其中，场景 2 是应用程序使用 Query 接口的常见场景，场景 5 是应用程序使用 Prepared Statement 接口的理想场景。
 
-- 对比场景 2 和场景 5，可以发现通过使用 Java 应用开发的最佳实践以及客户端缓存 Prepared Statement 对象，每条 SQL 只需要一次命令和数据库交互，就能命中执行计划缓存，从而使 Query 延迟下降了 38%，QPS 上升 28%，同时，TiDB CPU 平均利用率从 936% 下降到 577%。
-- 对比场景 2 和场景 7，可以看到在场景 5 的基础上使用了 RC Read、小表缓存等 TiDB 最新的优化功能，延迟降低了 51%，QPS 提升了 108%，同时，TiDB CPU 平均利用率从 936% 下降到 478%。
+- 对比场景 5 和场景 2，可以发现通过使用 Java 应用开发的最佳实践以及客户端缓存 Prepared Statement 对象，每条 SQL 只需要一次命令和数据库交互，就能命中执行计划缓存，从而使 Query 延迟下降了 38%，QPS 上升 28%，同时，TiDB CPU 平均利用率从 936% 下降到 577%。
+- 对比场景 7 和场景 3，可以看到在场景 5 的基础上使用了 RC Read、小表缓存等 TiDB 最新的优化功能，延迟降低了 41%，QPS 提升了 108%，同时，TiDB CPU 平均利用率从 936% 下降到 478%。
 
 通过对比各场景的性能表现，可以得出以下结论：