什麼可能導致文本比較失敗？

數據庫版本：PostgreSQL 8.2.15 (Greenplum Database 4.3.4.1 build 2) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Feb 10 2015 14:15:10

我在我們的一個環境中遇到問題，其中一個模式中的表在執行簡單查詢時似乎行為不正確，字元列未與文字字元串或其他列進行比較。架構內與其他相同列的聯接有效，但與架構外的表的聯接不起作用。這是一個帶有文字字元串的簡單範例。

我這樣做：

SELECT *
FROM carriers
WHERE carrier_code = 'FR'

然後我從字元（32）列中複製並粘貼值並執行以下操作：

SELECT *
FROM carriers
WHERE carrier_hash = '11aedd0e432747c2bcd97b82808d24a0'

這不返回任何內容。這是第一個查詢返回的實際列的直接複製和粘貼。但是，如果我這樣做：

SELECT *
FROM carriers
WHERE carrier_hash like '11aedd0e432747c2bcd97b82808d24a0'

這將返回相同的記錄。這也有效：

SELECT *
FROM carriers
WHERE substring(carrier_hash,1,32) = '11aedd0e432747c2bcd97b82808d24a0'

為什麼使用簡單的字元串而沒有或字元可能=會表現得不同？這已經工作了幾個月。最近唯一改變的是我們已經備份、清除和恢復了數據庫。在恢復過程中是否可能出現問題？like``_``%

我們在其他模式中有其他表具有相同的列，並且工作得很好。

我們的 DBA 最近從備份中恢復了這個環境。不知道這是否相關。

發生這種情況是因為我們的數據分發方式發生了一些變化。我們的一些表的分佈方式與其他表不同 - 記錄位於與分佈算法所說的不同的節點上。因此，當我執行一個查找特定值的查詢時，主節點只將該查詢發送到應該保存該鍵值的節點，但它沒有找到它。連接也會發生同樣的情況 - 段節點假設由於兩個表都分佈在相同的連接鍵上，因此連接可以在本地執行。其中一張表分佈不正確，因此連接失敗。

我還不知道是什麼原因造成的，如果我發現了，我會發布更新。有什麼建議嗎？

我已經刪除了 postgresql 標記，因為這個問題原來是 greenplum 特有的。

好的，這就是發生的事情。我們的 DBA 正在從備份中恢復，但它失敗了，因為備份中的文件與預期的名稱不匹配。恢復需要一個名為 something_0_2_something 和 0_3 和 0_4 的文件，但備份包含 0_22 和 0_23 和 0_24。所以他打電話給 Pivotal，但因為需要一段時間才能得到答复，所以他只是將它們全部重命名為從數字中減去 20，然後繼續進行恢復。似乎這最終導致數據被恢復到錯誤的節點。我們仍在等待 Pivotal 的答复，說明文件名出了什麼問題以及如何修復它。

更多資訊：顯然備份備份了鏡像段，而不是主段，因此文件名不同。我們正在通過拆除原色、恢復鏡像、恢復原色和重新平衡來解決這個問題。我們不知道為什麼會這樣，主要和鏡像狀態看起來都很好。Pivotal 一直在關注 webex 上的系統，他們說他們以前從未見過這種情況，因此取得了成就。

引用自：https://dba.stackexchange.com/questions/139473