我們使用varchar（255）在mysql中存儲「關鍵字」。我們正面臨着一個問題，即mysql會忽略所有的尾部空格，以便在「=」中進行比較。它確實在「類似」比較中尊重尾隨空格，但它不會讓我們在varchar列中存儲具有和不帶空格的相同單詞，前提是它具有「UNIQUE」索引。mysql varbinary vs varchar
所以，我們正在考慮切換到varbinary。任何人都可以建議在列值中有多字節字符時可能會產生什麼影響？
這就是MySQL manual說，關於後續空格：
尾隨空格的處理是 版本相關。從MySQL 5.0.3開始， 當 值被存儲和檢索時，尾隨空格被保留， 與標準SQL一致。 MySQL 5.0.3之前，尾隨空格 從 存儲到VARCHAR列的值中刪除;這個 意味着空間也從檢索值中缺失 。
由於您的問題表明MySQL不會聲明尾隨空格，所以我認爲您的版本低於5.0.3。考慮爲你的列使用TEXT類型;這些保留了尾隨空格。 TEXT將爲您處理字符串的encoding and decoding，因此您不必擔心多字節字符。
TEXT的確執行速度比VARBINARY慢。如果實際數據顯示性能不可接受，則可能需要選擇VARBINARY（或BLOB）。在這種情況下，您需要以特定編碼存儲字符串，例如UTF-8。只要所有的客戶端使用相同的編碼，對於多字節字符就可以正常工作。不要考驗你的客戶提供不同的區域設置:)
Andomar，
我們使用的版本5.0.5。所有的mysql版本都會忽略尾隨空格進行比較。從手冊：
所有的MySQL排序規則類型爲 PADSPACE。這意味着將MySQL中的所有CHAR和 VARCHAR值進行比較 而不考慮任何尾隨空格。 這適用於所有的MySQL版本， 並沒有區別存儲 他們
而且MySQL的認爲文本有/無尾隨空格前 您的版本是否剪裁VARCHAR值的尾部空格 複製的指標：
對於其中後墊 字符被剝離或比較 忽略它們，如果列具有需要唯一值的索引 的那些情況下，在插入 轉換爲僅在尾部數字 字符將會導致 重複鍵錯誤 不同的列值。例如，如果 表包含'a'，則嘗試存儲'a'會導致重複鍵 錯誤。
而且，我們絕對需要一個關鍵字索引。 所以，我想我們有兩個選擇：varbinary或文本。我們將評估「文本」的性能，以及varbinary的多字節功能。
除了尾隨空間問題，MySQL中的UNIQUE INDEX將被限制爲767個字節（這使3個字節的UTF8的767/3〜= 255）成爲可能。另請參見：
這個答案是有點誤導，因爲它忽略了完全獨特索引consquences。有關更多信息，請參閱ashweta自己的答案 – 2014-02-27 10:04:21