docs: remove stray zero-width-space characters from prose

constraints.md

@@ -48,7 +48,7 @@ Query OK, 1 row affected (0.03 sec)
 
 * The first `INSERT` statement succeeds because it is possible to assign `NULL` to the `AUTO_INCREMENT` column. TiDB generates sequence numbers automatically.
 * The second `INSERT` statement fails because the `age` column is defined as `NOT NULL`.
-* The third `INSERT` statement succeeds because the `last_login` column is not explicitly defined as `NOT NULL`. NULL values ​​are allowed by default.
+* The third `INSERT` statement succeeds because the `last_login` column is not explicitly defined as `NOT NULL`. NULL values are allowed by default.
 
 ## CHECK
 

dashboard/dashboard-diagnostics-report.md

@@ -125,7 +125,7 @@ In the table above,
 
 > **Note:**
 >
-> `CURRENT_CONFIG_VALUE` is the value when the report is generated, not the value within the time range of this report. Currently, some configuration values ​​of historical time cannot be obtained.
+> `CURRENT_CONFIG_VALUE` is the value when the report is generated, not the value within the time range of this report. Currently, some configuration values of historical time cannot be obtained.
 
 #### `TiDB/PD Goroutines Count`
 
@@ -233,7 +233,7 @@ This table shows transaction-related monitoring metrics.
 
 ![Transaction report](/media/dashboard/dashboard-diagnostics-tidb-txn.png)
 
-* `TOTAL_VALUE`: The sum of all values ​​(SUM) during the report time range.
+* `TOTAL_VALUE`: The sum of all values (SUM) during the report time range.
 * `TOTAL_COUNT`: The total number of occurrences of this monitoring metric.
 * `P999`: The maximum P999 value of this monitoring metric.
 * `P99`: The maximum P99 value of this monitoring metric.
@@ -242,7 +242,7 @@ This table shows transaction-related monitoring metrics.
 
 Example:
 
-In the table above, within the report time range, `tidb_txn_kv_write_size`: a total of about 181,296 transactions of KV writes, and the total KV write size is 266.772 MB, of which the maximum P999, P99, P90, P80 values for a single transaction of KV writes ​​are 116.913 KB, 1.996 KB, 1.905 KB, and 1.805 KB.
+In the table above, within the report time range, `tidb_txn_kv_write_size`: a total of about 181,296 transactions of KV writes, and the total KV write size is 266.772 MB, of which the maximum P999, P99, P90, P80 values for a single transaction of KV writes are 116.913 KB, 1.996 KB, 1.905 KB, and 1.805 KB.
 
 ##### DDL Owner
 
@@ -341,7 +341,7 @@ This section introduces `DIFF_RATIO` using the `Instance CPU Usage` table as an
 ![Compare Instance CPU Usage report](/media/dashboard/dashboard-diagnostics-compare-instance-cpu-usage.png)
 
 * `t1.AVG`, `t1.MAX`, `t1.Min` are the average value, maximum value, and minimum value of CPU usage in the `t1`.
-* `t2.AVG`, `t2.MAX`, and `t2.Min` are the average value, maximum value, and minimum value ​​of CPU usage during `t2`.
+* `t2.AVG`, `t2.MAX`, and `t2.Min` are the average value, maximum value, and minimum value of CPU usage during `t2`.
 * `AVG_DIFF_RATIO` is `DIFF_RATIO` of the average values during `t1` and `t2`.
 * `MAX_DIFF_RATIO` is `DIFF_RATIO` of the maximum values during `t1` and `t2`.
 * `MIN_DIFF_RATIO` is `DIFF_RATIO` of the minimum values during `t1` and `t2`.

develop/dev-guide-join-tables.md

@@ -87,7 +87,7 @@ public List<Author> getTop10AuthorsOrderByBooks() throws SQLException {
 
 ### LEFT OUTER JOIN
 
-The left outer join returns all the rows in the left table and the values ​​in the right table that match the join condition. If no rows are matched in the right table, it will be filled with `NULL`.
+The left outer join returns all the rows in the left table and the values in the right table that match the join condition. If no rows are matched in the right table, it will be filled with `NULL`.
 
 ![Left Outer Join](/media/develop/left-outer-join.png)
 
@@ -190,7 +190,7 @@ public List<Book> getLatestBooksWithAverageScore() throws SQLException {
 
 ### RIGHT OUTER JOIN
 
-A right outer join returns all the records in the right table and the values ​​in the left table that match the join condition. If there is no matching value, it is filled with `NULL`.
+A right outer join returns all the records in the right table and the values in the left table that match the join condition. If there is no matching value, it is filled with `NULL`.
 
 ![Right Outer Join](/media/develop/right-outer-join.png)
 

encryption-at-rest.md

@@ -28,7 +28,7 @@ TiKV currently does not exclude encryption keys and user data from core dumps. I
 
 TiKV tracks encrypted data files using the absolute path of the files. As a result, once encryption is turned on for a TiKV node, the user should not change data file paths configuration such as `storage.data-dir`, `raftstore.raftdb-path`, `rocksdb.wal-dir` and `raftdb.wal-dir`.
 
-SM4 encryption is only supported in v6.3.0 and later versions of TiKV. TiKV versions earlier than v6.3.0 only support AES encryption. SM4 encryption affects performance. In the worst-case scenario, it might cause a ​50% to 80% throughput degradation. However, a sufficiently large [`storage.block-cache`](/tikv-configuration-file.md#storageblock-cache) can significantly mitigate this impact, reducing the throughput degradation to around 10%.
+SM4 encryption is only supported in v6.3.0 and later versions of TiKV. TiKV versions earlier than v6.3.0 only support AES encryption. SM4 encryption affects performance. In the worst-case scenario, it might cause a 50% to 80% throughput degradation. However, a sufficiently large [`storage.block-cache`](/tikv-configuration-file.md#storageblock-cache) can significantly mitigate this impact, reducing the throughput degradation to around 10%.
 
 ### TiFlash
 

information-schema/information-schema-data-lock-waits.md

@@ -52,7 +52,7 @@ The `KEY_INFO` column shows the detailed information of the `KEY` column. The in
 * `"table_name"`: The name of the table to which the key belongs.
 * `"partition_id"`: The ID of the partition where the key is located.
 * `"partition_name"`: The name of the partition where the key is located.
-* `"handle_type"`: The handle type of the row key (that is, the key that stores a row of data). The possible values ​​are as follows:
+* `"handle_type"`: The handle type of the row key (that is, the key that stores a row of data). The possible values are as follows:
     * `"int"`: The handle type is int, which means that the handle is the row ID.
     * `"common"`: The handle type is not int64. This type is shown in the non-int primary key when clustered index is enabled.
     * `"unknown"`: The handle type is currently not supported.

information-schema/information-schema-deadlocks.md

@@ -71,7 +71,7 @@ The `KEY_INFO` column shows the detailed information of the `KEY` column. The in
 * `"table_name"`: The name of the table to which the key belongs.
 * `"partition_id"`: The ID of the partition where the key is located.
 * `"partition_name"`: The name of the partition where the key is located.
-* `"handle_type"`: The handle type of the row key (that is, the key that stores a row of data). The possible values ​​are as follows:
+* `"handle_type"`: The handle type of the row key (that is, the key that stores a row of data). The possible values are as follows:
     * `"int"`: The handle type is int, which means that the handle is the row ID.
     * `"common"`: The handle type is not int64. This type is shown in the non-int primary key when clustered index is enabled.
     * `"unknown"`: The handle type is currently not supported.

information-schema/information-schema-tidb-trx.md

@@ -40,7 +40,7 @@ The meaning of each column field in the `TIDB_TRX` table is as follows:
 * `START_TIME`: The start time of the transaction, which is the physical time corresponding to the `start_ts` of the transaction.
 * `CURRENT_SQL_DIGEST`: The digest of the SQL statement currently being executed in the transaction.
 * `CURRENT_SQL_DIGEST_TEXT`: The normalized form of the SQL statement currently being executed by the transaction, that is, the SQL statement without arguments and format. It corresponds to `CURRENT_SQL_DIGEST`.
-* `STATE`: The current state of the transaction. The possible values ​​include:
+* `STATE`: The current state of the transaction. The possible values include:
     * `Idle`: The transaction is in an idle state, that is, it is waiting for the user to input a query.
     * `Running`: The transaction is executing a query.
     * `LockWaiting`: The transaction is waiting for the pessimistic lock to be acquired. Note that the transaction enters this state at the beginning of the pessimistic locking operation, no matter whether it is blocked by other transactions or not.

literal-values.md

@@ -1,6 +1,6 @@
 ---
 title: Literal Values
-summary: This article introduces the literal values ​​of TiDB SQL statements.
+summary: This article introduces the literal values of TiDB SQL statements.
 aliases: ['/docs/dev/literal-values/','/docs/dev/reference/sql/language-structure/literal-values/']
 ---
 
@@ -105,7 +105,7 @@ The year value containing only two digits is ambiguous. It is recommended to use
 * If the year value is in the range of `70-99`, it is converted to `1970-1999`.
 * If the year value is in the range of `00-69`, it is converted to `2000-2069`.
 
-For month or day values ​​less than 10, `'2017-8-4'` is the same as `'2017-08-04'`. The same is true for Time. For example, `'2017-08-24 1:2:3'` is the same as `'2017-08-24 01:02:03'`.
+For month or day values less than 10, `'2017-8-4'` is the same as `'2017-08-04'`. The same is true for Time. For example, `'2017-08-24 1:2:3'` is the same as `'2017-08-24 01:02:03'`.
 
 When the date or time value is required, TiDB selects the specified format according to the length of the value:
 

releases/release-5.1.5.md

@@ -69,7 +69,7 @@ Quick access: [Quick start](https://docs-archive.pingcap.com/tidb/v5.1/quick-sta
 
 + PD
 
-    - Fix the issue that a removed tombstone store appears again after the PD leader transfer ​​[#4941](https://github.com/tikv/pd/issues/4941)
+    - Fix the issue that a removed tombstone store appears again after the PD leader transfer [#4941](https://github.com/tikv/pd/issues/4941)
     - Fix the issue that scheduling cannot start immediately after the PD leader transfer [#4769](https://github.com/tikv/pd/issues/4769)
     - Fix the wrong status code of `not leader` [#4797](https://github.com/tikv/pd/issues/4797)
     - Fix the issue that PD cannot correctly handle dashboard proxy requests [#5321](https://github.com/tikv/pd/issues/5321)

releases/release-5.3.2.md

@@ -84,7 +84,7 @@ TiDB version: 5.3.2
 
     - Fix the PD panic that occurs when a hot region has no leader [#5005](https://github.com/tikv/pd/issues/5005)
     - Fix the issue that scheduling cannot start immediately after the PD leader transfer [#4769](https://github.com/tikv/pd/issues/4769)
-    - Fix the issue that a removed tombstone store appears again after the PD leader transfer ​​[#4941](https://github.com/tikv/pd/issues/4941)
+    - Fix the issue that a removed tombstone store appears again after the PD leader transfer [#4941](https://github.com/tikv/pd/issues/4941)
     - Fix a bug of TSO fallback in some corner cases [#4884](https://github.com/tikv/pd/issues/4884)
     - Fix the issue that when there exists a Store with large capacity (2T for example), fully allocated small Stores cannot be detected, which results in no balance operator being generated [#4805](https://github.com/tikv/pd/issues/4805)
     - Fix the issue that schedulers do not work when `SchedulerMaxWaitingOperator` is set to `1` [#4946](https://github.com/tikv/pd/issues/4946)

releases/release-5.4.3.md

@@ -63,7 +63,7 @@ TiDB version: 5.4.3
 + PD
 
     - Fix the issue that PD cannot correctly handle dashboard proxy requests [#5321](https://github.com/tikv/pd/issues/5321)
-    - Fix the issue that a removed tombstone store appears again after the PD leader transfer ​​[#4941](https://github.com/tikv/pd/issues/4941)
+    - Fix the issue that a removed tombstone store appears again after the PD leader transfer [#4941](https://github.com/tikv/pd/issues/4941)
     - Fix the issue that the TiFlash learner replica might not be created [#5401](https://github.com/tikv/pd/issues/5401)
 
 + TiFlash

releases/release-6.1.0.md

@@ -398,7 +398,7 @@ In 6.1.0, the key new features or improvements are as follows:
 
     - Fix the wrong status code of `not leader` [#4797](https://github.com/tikv/pd/issues/4797)
     - Fix a bug of TSO fallback in some corner cases [#4884](https://github.com/tikv/pd/issues/4884)
-    - Fix the issue that a removed tombstone store appears again after the PD leader transfer ​​[#4941](https://github.com/tikv/pd/issues/4941)
+    - Fix the issue that a removed tombstone store appears again after the PD leader transfer [#4941](https://github.com/tikv/pd/issues/4941)
     - Fix the issue that scheduling cannot start immediately after the PD leader transfer [#4769](https://github.com/tikv/pd/issues/4769)
 
 + TiDB Dashboard

statistics.md

@@ -83,9 +83,9 @@ This section describes three types of statistics: histogram, Count-Min Sketch, a
 
 Histogram statistics are used by the optimizer to estimate selectivity of an interval or range predicate, and might also be used to determine the number of distinct values within a column for estimation of equal/IN predicates in Version 2 of statistics (refer to [Versions of Statistics](#versions-of-statistics)).
 
-A histogram is an approximate representation of the distribution of data. It divides the entire range of values into a series of buckets, and uses simple data to describe each bucket, such as the number of values ​​falling in the bucket. In TiDB, an equal-depth histogram is created for the specific columns of each table. The equal-depth histogram can be used to estimate the interval query.
+A histogram is an approximate representation of the distribution of data. It divides the entire range of values into a series of buckets, and uses simple data to describe each bucket, such as the number of values falling in the bucket. In TiDB, an equal-depth histogram is created for the specific columns of each table. The equal-depth histogram can be used to estimate the interval query.
 
-Here "equal-depth" means that the number of values ​​falling into each bucket is as equal as possible. For example, for a given set {1.6, 1.9, 1.9, 2.0, 2.4, 2.6, 2.7, 2.7, 2.8, 2.9, 3.4, 3.5}, you want to generate 4 buckets. The equal-depth histogram is as follows. It contains four buckets [1.6, 1.9], [2.0, 2.6], [2.7, 2.8], [2.9, 3.5]. The bucket depth is 3.
+Here "equal-depth" means that the number of values falling into each bucket is as equal as possible. For example, for a given set {1.6, 1.9, 1.9, 2.0, 2.4, 2.6, 2.7, 2.7, 2.8, 2.9, 3.4, 3.5}, you want to generate 4 buckets. The equal-depth histogram is as follows. It contains four buckets [1.6, 1.9], [2.0, 2.6], [2.7, 2.8], [2.9, 3.5]. The bucket depth is 3.
 
 ![Equal-depth Histogram Example](/media/statistics-1.png)