使用 CONVERT TO CHARACTER SET 僅更改排序規則？

我認為這個問題的答案是肯定的，但我很難找到它的確認。所有與字元集相關的問題似乎都與更改字元集有關，而不僅僅是排序規則。

所以我在 utf8mb4_general_ci 中有表，我想將其轉換為 utf8mb4_unicode_ci。我可以安全地執行以下查詢來完成任務嗎？

ALTER TABLE mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci

我會在 information_schema 中的表排序規則設置為 utf8mb4_general_ci 的所有表上執行它。在開始這項任務之前我需要注意什麼？我應該仔細檢查表中的列是否也具有相同的字元集集？我收到一個警告，即使只是更改排序規則也會導致字元集問題在之後彈出，但不確定這有多少真相……

我在這些數據庫中也有 latin1-tables 和 utf8-tables 來轉換。但我想我一次只嘗試解決一個挑戰。由於我不想更改列類型，我想我必須以比使用該命令更複雜的方式來完成它。

（我正在嘗試修復我們擁有的眾多數據庫中表之間的字元集不一致）

所以我想首先統一那些已經 utf8mb4 的表上的排序規則，然後從那裡逐漸繼續。

伺服器版本：5.7.16-10-log Percona Server (GPL)，Release ‘10’，Revision ‘a0c7d0d’

有一些用於管理字元集轉換的選項。正如您所發現的，有 alter table 選項，您可以在語句中使用字元集子句或 collat​​e 子句或同時使用兩者。

其他選項包括更改整個數據庫的字元集和排序規則（我可以看到您還不想這樣做）。

或者在免費和開源的Percona Toolkit中有一個工具非常受開發人員歡迎，pt-online-schema-change，它可以幫助您管理具有主鍵的表的此類遷移。

獨立於 Percona 的顧問 David Berube 在我們的社區部落格上寫了一篇詳細的部落格文章，介紹了更改字元集和排序規則時可能遇到的一些問題。您可以在https://www.percona.com/community-blog/2018/06/12/character-sets-migrating-utf8mb4-pt_online_schema_change/閱讀該內容

潛在的缺陷包括數據庫版本兼容性、應用程序“期望”、密鑰長度管理（長度可能會改變），以及您可能會看到誤報的事實，即說它是 latin1 的列可能不是！

這次在 Percona 網站上，有許多部落格文章和一個免費的網路研討會疑難解答 MySQL 字元集問題https://www.percona.com/resources/webinars/troubleshooting-issues-mysql-character-sets

希望其中一些能幫助您找到處理場景的最佳方法。

– 披露：我為 Percona 工作。

既然你只改變了，COLLATION我會考慮

ALTER TABLE t MODIFY col1 VARCHAR(...) COLLATION utf8mb4_unicode_520_ci ...,
                    col2 VARCHAR(...) COLLATION utf8mb4_unicode_520_ci ...,
                    ...;

不幸的是，沒有簡單的方法可以讓“…”正確——這需要重複大小、NULL/NOT NULL等。

相反，正如你所建議的，

ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;

可能是最好的。潛在問題：

• 我建議utf8mb4_unicode_520_ci（基於 Unicode 標準版本 5.20）比utf8mb4_unicode_ci（基於 Unicode 4.0）更好。
• CONVERT TO也會更改所有非 utf8mb4 列。當你有一個列時，這並不好，比如country_code CHAR(2) CHARACTER SET ascii. 當你擁有的是 ascii 時，不要使用 utf8mb4 的複雜性和大小。（這是一個小問題。）
• 表會在一定程度上被鎖定，任何涉及文本列的索引都必然會被重建。
• 當連接具有不同排序規則的兩個表時（例如在一個ALTER和下一個之間），索引可能會被忽略，從而導致查詢緩慢。
• 5.7 沒有 utf8mb4 困擾 5.5 和 5.6 的“767”問題。如果您以前對這個問題有一些困惑，那麼現在是清理它的時候了。
• 是pt-osc（或gh-ost）對於任何大表來說可能是一個好主意。（小桌子的轉換速度足夠快，不會成為問題。）
• 多主 / Galera / 組複製——這些可能有其他問題和/或其他技術。

除了這些評論，我不預測任何問題。

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