# Using the Sync-diff-inspector - Considerations

__*Using sync-diff-inspector*__
__*Sync-diff-inspector considerations*__

+ Avoiding verification during peak business hours
+ It is recommended to gather table statistics before validating
+ SQL repair data needs to be confirmed before execution
+ sync-diff-inspector with sharding validation enabled by default
+ If the table's primary or unique key is of type varchar, you need to add the collation setting in the sync-diff-inspector configuration file

-------------------------------------------------------------
The sync-diff-inspector consumes a certain amount of server resources when validating data, and it is necessary to avoid checking during peak business hours.

Before comparing the data, pay attention to the collation settings in the table. If the primary key or unique key of the table is of type varchar, and the collation settings in the upstream and downstream databases are different, the final validation result may be incorrect due to sorting issues, and the collation setting needs to be added to the sync-diff-inspector configuration file.

The sync-diff-inspector uses TiDB statistics to divide chunks first. It is necessary to ensure that the statistics are as accurate as possible. You can manually execute the analyze table {table_name} during the idle period of the service.

The rules of table-rule require special attention. For example, if schema-pattern="test1" and table-pattern="t*1", target-schema="test2", target-table = “t*2" are set, the table test1.t*1 and the table test2.t in target*2 in the source will be compared. By default, sync-diff-inspector sharding is enabled. If the source also contains table test2.t*2, the table test1.t on the source side will be placed*1 and table test2.t*2 as table test2.t in sharding and target*2 for consistency check.

The generated SQL file is only used as a reference for the repair data and needs to be confirmed before executing the SQL repair data.