commit some suggestions

Signed-off-by: Jianjun Liao <jianjun.liao@outlook.com>

Author: Leavrth

br/backup-and-restore-overview.md

@@ -147,7 +147,15 @@ This section introduces the BR compatibility information for all [Long-Term Supp
 >
 > - Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717).
 >
-> - Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore.
+> - Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. If the upstream cluster still exists before the restore, you can manually execute the following three sets of SQL statements in the upstream cluster to verify data compatibility across different collations by confirming that the COUNT results are consistent:
+> - SQL 1：SELECT COUNT(1) FROM mysql.db;
+> - SQL 1：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User FROM mysql.db GROUP BY Host, DB COLLATE utf8mb4_general_ci, User) as a;
+>
+> - SQL 2：SELECT COUNT(1) FROM mysql.tables_priv;
+> - SQL 2：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci FROM mysql.tables_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci) as a;
+>
+> - SQL 3：SELECT COUNT(1) FROM mysql.columns_priv;
+> - SQL 3：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci FROM mysql.columns_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci) as a;
 
 The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0.