performance: add link to tuning methods (#8926)

grafana-performance-overview-dashboard.md

@@ -11,13 +11,13 @@ The Grafana dashboard is divided into a series of sub dashboards which include P
 
 The Performance Overview dashboard orchestrates the metrics of TiDB, PD, and TiKV, and presents each of them in the following sections:
 
-- Overview: Database time and SQL execution time summary. By checking different colors in the overview, you can quickly identify the database load profile and the performance bottleneck.
+- Overview: Database time and SQL execution time summary. By checking different colors in the overview, you can quickly identify the database workload profile and the performance bottleneck.
 
-- Load profile: Key metrics and resource usage, including database QPS, connection information, the MySQL command types the application interactes with TiDB, database internal TSO and KV request OPS, and resource usage of the TiKV and TiDB.
+- Load profile: Key metrics and resource usage, including database QPS, connection information, the MySQL command types the application interacts with TiDB, database internal TSO and KV request OPS, and resource usage of the TiKV and TiDB.
 
-- Top-down latency breakdown: Query latency versus connection idel time ratio, query latency breakdown, TSO/KV request latency during execution, breakdown of write latency within TiKV.
+- Top-down latency breakdown: Query latency versus connection idle time ratio, query latency breakdown, TSO/KV request latency during execution, breakdown of write latency within TiKV.
 
-With the Performance Overview Dashboard, you can analyze performance efficiently, and confirm whether the bottleneck of user response time is in the database. If the bottleneck is in the database, you can identify the bottleneck inside the database, with database time overview, load profile and SQL latency breakdown.
+With the Performance Overview Dashboard, you can analyze performance efficiently, and confirm whether the bottleneck of user response time is in the database. If the bottleneck is in the database, you can identify the bottleneck inside the database, with database time overview, workload profile and SQL latency breakdown. For details, see [Performance Analysis and Tuning](/performance-tuning-methods.md).
 
 The following sections illustrate the metrics on the Performance Overview dashboard.
 
@@ -39,7 +39,7 @@ The SQL execution phase is in green and other phases are in red on general. If n
 - tso_wait: Concurrent TSO waiting time per second during SQL execution
 - kv request type: Time waiting for each KV request type per second during SQL execution. The total KV request wait time might exceed SQL execution time, because KV requests are concurrent.
 
-Green metrics stand for common KV write requests (such as prewrite and commit), blue metrics stand for common read requests, and metrics in other colors stand for unexpected situations which you need to pay attention to. For example, pessimistic lock KV requests are marked red and TSO waiting is marked dark brown. 
+Green metrics stand for common KV write requests (such as prewrite and commit), blue metrics stand for common read requests, and metrics in other colors stand for unexpected situations which you need to pay attention to. For example, pessimistic lock KV requests are marked red and TSO waiting is marked dark brown.
 
 If non-blue or non-green areas are large, it means there is a bottleneck during SQL execution. For example:
 
@@ -92,7 +92,7 @@ Generally, dividing `tso - cmd` by `tso - request` yields the average batch size
 
 - Duration: Execution time
 
-    - The duration from receiving a request from the client to TiDB till TiDB exeucting the request and returning the result to the client. In general, client requests are sent in the form of SQL statements; however, this duration can include the execution time of commands such as `COM_PING`, `COM_SLEEP`, `COM_STMT_FETCH`, and `COM_SEND_LONG_DATA`.
+    - The duration from receiving a request from the client to TiDB till TiDB executing the request and returning the result to the client. In general, client requests are sent in the form of SQL statements; however, this duration can include the execution time of commands such as `COM_PING`, `COM_SLEEP`, `COM_STMT_FETCH`, and `COM_SEND_LONG_DATA`.
     - TiDB supports Multi-Query, which means the client can send multiple SQL statements at one time, such as `select 1; select 1; select 1;`. In this case, the total execution time of this query includes the execution time of all SQL statements.
 
 - avg: Average time to execute all requests
@@ -134,7 +134,7 @@ Average time consumed in executing gRPC requests in all TiKV instances based on
 ## Storage Async Write Duration, Store Duration, and Apply Duration
 
 - Storage Async Write Duration: Time consumed in asynchronous write
-- Store Duration: Time consumed in store loop during asynchronously write 
+- Store Duration: Time consumed in store loop during asynchronously write
 - Apply Duration: Time consumed in apply loop during asynchronously write
 
 All these three metrics include the average duration and P99 duration in all TiKV instances.