PostgreSQL 字符集烏龍導致資料查詢排序的問題，與 MySQL 穩定 "PG不穩定"

來源：AustinDatabases

有意思的事情每天都有，最近一個客戶的公司的PG資料庫在執行中，出現了一個問題，客戶在對資料進行排序的過程中，發現資料雖然一致，但兩個儲存同樣資料的資料庫，在進行語句查詢的時候，給出的結果不同，基於他們只取結果集的前兩條，導致同樣的資料庫表，同樣的資料，最終在介面上給客戶展示的資料不同。

開發人員隨即提出，之前在MySQL 上從未發生這樣的問題，而基於一些政府機構的要求，不能使用MySQL 而將應用程式轉移到了PostgreSQL上就問題百出，隨即甩出不負責的一句， MySQL就是比 PostgreSQL 要穩定，出問題少。

基於客戶的隱私，這裡只能用測試機和自己的測試資料代替，參見上圖，的確兩個都是PG的資料庫，在輸入同樣的資料後，在對中文字元進行排序後，發現次序不同。

基於這個問題的情況看，大機率是字符集及字符集的排序不同導致，但是客戶的開發人員，咬定說一起裝的，沒有分別，生產資料庫不能亂動，就是PG的問題等。 

這裡溝通，僅僅針對兩個系統進行引數和系統的關於字符集的引數的搜取，不會對系統進行任何的改變和設定。

1  檢視作業系統當前的字符集支援，透過locale -a 針對兩個資料庫系統的作業系統支援的字符集進行了檢查，明顯兩個系統支援的字符集的數量非常不一樣。

當然這裡，並不是產生問題的關鍵，但兩個系統的字符集支援，並非像開發人員提出的，兩個系統一模一樣，基於這個部分後，我們找到突破口，將結果展示，並告知，排序的不同，與資料庫的字符集有關，基於之前提出的兩個系統一模一樣，目前看並不是這樣。

對方則同意給我們相關的資料庫賬號，進行進步一的分析。這裡我們針對資料庫中客戶登陸的字符集兩個物理資料庫中的邏輯庫的 encoding 都進行了校對，兩個資料庫在這裡是一致的。

select datname,datcollate,datctype from pg_database where datname = 'test';

到了這裡，明顯是datcollate 的是不一樣的，但開發提出為什麼會不一樣。

postgres=# select datname,datcollate,datctype from pg_database where datname = 'test';
 datname | datcollate |  datctype  
---------+------------+------------
 test    | zh_CN.utf8 | zh_CN.utf8

postgres=# select datname,datcollate,datctype from pg_database where datname = 'test';
 datname | datcollate |  datctype  
---------+------------+------------
 test    | en_US.utf8 | en_US.utf8

然後針對疑問，我們對於資料庫伺服器中的配置檔案進行了檢查，明顯兩個資料庫在初始化的時候，就有不同，至少在藍色圖中的資料庫，初始化的時候，的配置項 locale=zh_CN.UTF-8  當然這個我們是無法進行復原資料庫初始化的場景，但從配置檔案中，locale 的部分應該不是預設的，而白色的資料庫的locale應該是沒有動過的，按照預設進行設定。

同時在我們透過pg_admin 想檢視資料庫建立語句的嘗試中，發現系統直擊報錯。

而另一個資料庫本身可以直接顯示資料庫的預設建庫的語句。

最後我們找到他出問題的語句，將排序後面新增了對方資料庫的 collate 在此核驗資料庫的結果，完全一致。

開發人員問，那這我也不能帶著後面的部分去執行呀，我還的改程式，你有沒有辦法？ 

此時我看向那個口出狂言的開發人員，MySQL 比 PostgreSQL穩定不穩定我不清楚，但我看你們的穩定性一定沒有PostgreSQL的穩定性高。

順便買本書，好好學學吧 ！

另外建議某些開發的同學，不會可以，但做一個資料庫“種族主義”者 就不大好了！！！！！！！！！！！