MySQL編碼utf8升級utf8mb4

上篇文章咱們介紹了utf8和utf8mb4的區別，這篇文章咱們主要介紹utf8升級utf8mb4的步驟

utf8升級utf8mb4具體步驟：首先將咱們數據庫默認字符集由utf8更改成utf8mb4，而後將表默認字符集也更改成utf8mb4，最後再把存儲表情的字段默認字符集也作相應的調整。

SQL 語句

# 修改數據庫
> ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

# 修改表
> ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

# 修改表字段
> ALTER TABLE table_name CHANGE column_name column_name VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

修改MySQL配置文件，新增以下參數：

default-character-set = utf8mb4
default-character-set = utf8mb4
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect='SET NAMES utf8mb4'

解釋：
– character_set_server：默認的內部操做字符集
– character_set_client：客戶端來源數據使用的字符集
– character_set_connection：鏈接層字符集
– character_set_results：查詢結果字符集
– character_set_database：當前選中數據庫的默認字符集
– character_set_system：系統元數據(字段名等)字符集
– 還有以collation_開頭的同上面對應的變量，用來描述字符序。

檢查環境變量 和測試 SQL 以下：

SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';

注意：MySQL版本必須爲5.5.3以上版本，不然不支持字符集utf8mb4

建議：

• 建議普通表使用utf8， 若是這個表須要支持emoji就使用utf8mb4
• 新建mysql庫或者表的時候還有一個排序規則
• utf8_unicode_ci比較準確，utf8_general_ci速度比較快。一般狀況下 utf8_general_ci的準確性就夠咱們用的了，在我看過不少程序源碼後，發現它們大多數也用的是utf8_general_ci，因此新建數據 庫時通常選用utf8_general_ci就能夠了
• 若是是utf8mb4那麼對應的就是 utf8mb4_general_ci utf8mb4_unicode_ci

utf8_unicode_ci與utf8_general_ci的區別
當前，utf8_unicode_ci校對規則僅部分支持Unicode校對規則算法。一些字符仍是不能支持。而且，不能徹底支持組合的記號。這主要影響越南和俄羅斯的一些少數民族語言，如：Udmurt 、Tatar、Bashkir和Mari。
utf8_unicode_ci的最主要的特點是支持擴展，即當把一個字母看做與其它字母組合相等時。例如，在德語和一些其它語言中‘ß’等於‘ss’
utf8_general_ci是一個遺留的校對規則，不支持擴展。它僅可以在字符之間進行逐個比較。這意味着utf8_general_ci校對規則進行的比較速度很快，可是與使用utf8_unicode_ci的校對規則相比，比較正確性較差

例如，使用utf8_general_ci和utf8_unicode_ci兩種 校對規則下面的比較相等：
Ä = A
Ö = O
Ü = U

兩種校對規則之間的區別是，對於utf8_general_ci下面的等式成立：ß = s
可是，對於utf8_unicode_ci下面等式成立：ß = ss

對於一種語言僅當使用utf8_unicode_ci排序作的很差時，才執行與具體語言相關的utf8字符集 校對規則。例如，對於德語和法語，utf8_unicode_ci工做的很好，所以再也不須要爲這兩種語言建立特殊的utf8校對規則。
utf8_general_ci也適用與德語和法語，除了‘ß’等於‘s’，而不是‘ss’以外。若是你的應用可以接受這些，那麼應該使用utf8_general_ci，由於它速度快。不然，使用utf8_unicode_ci，由於它比較準確。

案例
sql語句

CREATE TABLE test_session (
  sessionId varchar(255) NOT NULL,
  userId int(10) unsigned DEFAULT NULL,
  createAt datetime DEFAULT NULL
)

執行上面的代碼會報一個錯誤：Specified key was too long; max key length is 767 bytes
當使用utf8mb4編碼後，主鍵id的長度設置255，太長，只能設置小於191的

報錯緣由：utf8編碼下，255長度的varchar長度約767，更改爲utf8mb4後，最大隻能支持191長度
max key length is 767 bytes
utf8: 767/3=255.6666666666667
utf8mb4: 767/4=191.75

---

歡迎訂閱「K叔區塊鏈」 - 專一於區塊鏈技術學習

博客地址： http://www.jouypub.com
簡書主頁： https://www.jianshu.com/u/756c9c8ae984
segmentfault主頁： https://segmentfault.com/blog/jouypub
騰訊雲主頁： https://cloud.tencent.com/developer/column/72548