mysql數據校驗進程中的字符集成績處置。本站提示廣大學習愛好者：（mysql數據校驗進程中的字符集成績處置）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql數據校驗進程中的字符集成績處置正文
場景：
主庫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沒法表現。 假定修復語句以下：
Update t set c1=master_value where c1=slave_value and id=?
個中t表現表名，id是主鍵表現某一行，master_value為主庫c1列的值，slave_value為備庫c1列的值。此時，slave_value因為UTF8轉為GBK曾經喪失，是以語句履行終究影響0行記載，沒法修復。
結論：
客戶端拜訪兩個分歧字符集庫停止數據校驗時，銜接采取表現規模更年夜的字符集。好比我們經常使用的字符集表現規模以下：
Latin<gb2312<gbk<utf8
附：mysql客戶端與辦事器通訊時字符集編碼轉換流程
相干參數：
– character_set_client：客戶端起源數據應用的字符集
– character_set_connection：銜接層字符集
– character_set_results：查詢成果字符集
– character_set_database：以後選中數據庫的默許字符集
– character_set_system：體系元數據(字段名等)字符集
1.客戶端要求辦事器
1)將client的字符集轉為connection字符集
2)將connection字符集轉為DB外部的字符集
2.辦事器前往成果給客戶端
1)將DB外部字符集轉為connection字符集
2)將connection字符集轉為character_set_results字符集
3.設置字符集敕令：set names 字符編碼
指定客戶端與辦事器通訊的字符集，包含要求與前往。
SET NAMES 'x' 等價於：
SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;
附圖：
