diff --git a/releases/release-3.0.3.md b/releases/release-3.0.3.md
index b604bf2c6c9f9..6688ecb79f8a5 100644
--- a/releases/release-3.0.3.md
+++ b/releases/release-3.0.3.md
@@ -66,7 +66,7 @@ TiDB Ansible version: 3.0.3
 
 + TiDB Binlog
     - Modify the default value of `defaultBinlogItemCount` in Drainer from 65536 to 512 to reduce the chance of OOM on Drainer startup [#721](https://github.com/pingcap/tidb-binlog/pull/721)
-    - Optimize the offline logic for pump server to avoid potential offline congestions [#701](https://github.com/pingcap/tidb-binlog/pull/701)
+    - Optimize the offline logic for Pump server to avoid potential offline congestions [#701](https://github.com/pingcap/tidb-binlog/pull/701)
 + TiDB Lightning:
     - Skip the system databases `mysql`, `information_schema`, `performance_schema`, and `sys` by default when importing [#225](https://github.com/pingcap/tidb-lightning/pull/225)
 
diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md
index 22c95272eb1ad..70307b9ec70b0 100644
--- a/releases/release-6.1.1.md
+++ b/releases/release-6.1.1.md
@@ -59,7 +59,7 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v6.1/quick-start-with-
 
     + TiDB Data Migration (DM)
 
-        - Users can manually set the amount of concurrency for lightning loader [#5505](https://github.com/pingcap/tiflow/issues/5505) @[buchuitoudegou](https://github.com/buchuitoudegou)
+        - Users can manually set the amount of concurrency for TiDB Lightning loader [#5505](https://github.com/pingcap/tiflow/issues/5505) @[buchuitoudegou](https://github.com/buchuitoudegou)
 
     + TiCDC
 
diff --git a/system-variables.md b/system-variables.md
index 3df4ec239a6af..615d3732071fa 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -3522,7 +3522,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
 - Type: Float
 - Default value: `0`
 - Range: `[0, 18446744073709551615]`
-- This variable determines whether to apply a penalty cost to the selection of index join, which reduces the likelihood of the optimizer selecting index join, and increases the likelihood of selecting alternative join methods such as hash join and tiflash join.
+- This variable determines whether to apply a penalty cost to the selection of index join, which reduces the likelihood of the optimizer selecting index join, and increases the likelihood of selecting alternative join methods such as hash join and TiFlash join.
 - When index join is selected, many table lookup requests are triggered, which consumes too many resources. You can use this variable to reduce the likelihood of the optimizer selecting index join.
 - This variable takes effect only when the [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620) variable is set to `2`.
 
diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md
index 0835dcd9e5eb6..9ceca6b2776e8 100644
--- a/tiflash/create-tiflash-replicas.md
+++ b/tiflash/create-tiflash-replicas.md
@@ -47,7 +47,7 @@ ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0;
 
 * For versions earlier than v4.0.6, if you create the TiFlash replica before using TiDB Lightning to import the data, the data import will fail. You must import data to the table before creating the TiFlash replica for the table.
 
-* If TiDB and TiDB Lightning are both v4.0.6 or later, no matter a table has TiFlash replica(s) or not, you can import data to that table using TiDB Lightning. Note that this might slow the TiDB Lightning procedure, which depends on the NIC bandwidth on the lightning host, the CPU and disk load of the TiFlash node, and the number of TiFlash replicas.
+* If TiDB and TiDB Lightning are both v4.0.6 or later, regardless of whether a table has TiFlash replicas, you can import data to that table using TiDB Lightning. Note that this might slow down the TiDB Lightning process, which depends on the NIC bandwidth on the TiDB Lightning host, the CPU and disk load of the TiFlash node, and the number of TiFlash replicas.
 
 * It is recommended that you do not replicate more than 1,000 tables because this lowers the PD scheduling performance. This limit will be removed in later versions.