場景：
主庫DB：utf8字符集
備庫DB：gbk字符集

需求：
校驗主備數據是否一致，并且修復

校驗過程：
設置主庫連接為utf8，設置備庫連接為gbk，分別進行查詢，將返回的的結果集按記錄逐字段比較。

顯示結果：
原本相同的漢字字符，數據校驗認為不一致。

原因分析：
對于主庫而已，由于建立連接的字符集為UTF8，則返回的漢字字符編碼為UTF8格式；對于備庫而言則是GBK格式，而程序中通過字符串比較函數strcasecmp進行比較，顯然不同的字符集編碼，相同的字符有不同的二進制，因此結果肯定不會相等。

進一步分析：
那么對于這種情況，建立連接應該采用哪種字符集呢？GBK or UTF8。其實選擇任何一種字符集都是OK的，只要是訪問主庫和備庫的字符集保持一致即可，唯一的區別在于，若選擇的字符集與客戶端的字符集不一致，可能導致無法正常顯示字符，即字符顯示為亂碼。

我們以客戶端的字符集為例，詳細說說三種情況：【這里的客戶端可以認為是SecureCRT】
備注：綠色框代表DB字符集，黃色框代表連接字符集，橙色框代表客戶端
第一種情況：

就是上述的情況，主庫返回字符的GBK編碼，備庫返回字符的UTF8編碼，因此進行字段比對，則會出現誤差。

第二種情況：

訪問主庫的連接不變，備庫連接由UTF8變為GBK，因此進行返回時，數據庫會將DB的字符集轉為GBK返回給客戶端，那么對于客戶端而已，相同字符都是通過GBK編碼表示，因此二進制相等，校驗結果正確。

第三種情況：

   訪問主庫和備庫的連接都是UTF8，因此對于主庫而已，返回給客戶端的字符編碼由GBK轉為UTF8，此時主庫和備庫都是UTF8編碼，校驗結果正確。但由于客戶端實質是GBK編碼方式顯示，因此返回的漢字字符都是亂碼，但不影響校驗結果的正確性。

修復：

      既然選擇與主備庫任一一個相同的字符集去訪問，都不會影響校驗結果的正確性，那么影響修復呢？由于UTF8的編碼范圍比GBK編碼范圍要大，因此若采用GBK連接訪問UTF8編碼DB，有可能出現部分字符GBK不能表示的情況。

我們拿第二種情況說明，此時主庫為GBK，備庫為UTF8，使用GBK訪問UTF8。假設存在UTF8轉為GBK過程中部分字符丟失，這時候主備庫肯定是不一致的，因為存在部分字符GBK無法表示。 假設修復語句如下：