以前我數據庫字符集用的也是utf-8，但從前年開始，我數據庫都改在用utf8mb4，現在回想改用的原因，忘得差不多了，所以轉載了這篇文章，記錄一些知識點。
如果你要存互聯網emoji表情，例如暱稱，聊天，就需要utf8mb4，而不是utf-8。
MySQL數據庫的 “utf8”並不是真正概念裏的 UTF-8。
首先確實utf8需要超過3個字節的長度。其次目前可見字符集都只需要3個字節，包含了所有字符。目前問題出在unicode6系列編碼上，它們需要4個字節，這部分就是有名的emoji。所以，你只要不是特種編碼還是unicode，且不存emoji，保證不出問題。
MySQL中的“utf8”編碼只支持最大3字節每字符。真正的大家正在使用的UTF-8編碼是應該能支持4字節每個字符。
MySQL的開發者沒有修復這個bug。他們在2010年增加了一個變通的方法：一個新的字符集“utf8mb4”
當然，他們並沒有對外公佈（可能因爲這個bug有點尷尬）。現在很多指南推薦用戶使用“utf8”其實都錯了。
簡單的說:
MySQL中的 “utf8mb4” 纔是 真正意義上的“UTF-8”。
MySQL的“utf8”是個“特殊的字符編碼”。這種編碼很多Unicode字符保存不了。
我強烈建議MySQL和MariaDB用戶使用“utf8mb4”而不是“utf8”。
編碼是什麼？什麼是UTF-8？
Joel on Software上有一遍我最喜歡的介紹，我精簡描述如下：
計算機使用0和1存儲文字。比如第一段第一個字符存儲爲“01000011”表示“C”，計算機通過以下兩個步驟選擇用“C”表示：
計算機讀取到“01000011”後計算出這是數字67。
計算機通過查找Unicode字符集來確認67代表的“C”。
同樣的事情發生在我打字輸入C的時候。
計算機通過Unicode字符集將“C” 映射爲67。
計算機把67編碼爲“01000011”發送給web服務器。
幾乎所有的程序和互聯網應用使用Unicode字符集。
Unicode字符集裏有超過100萬個字符(“C” 和 “” 是兩種不同的字符。)。UTF-32是最簡單的編碼方式，它在表示每個字符的時候使用32個bits。這樣編碼簡單，但是並不實用，明顯浪費了太多的空間。
UTF-8相比UTF-32更加節約空間。在UTF-8中，像“C”這樣的字符佔用8bits，“”這樣的佔用32 bits。其他字符佔用16或者24 bits。如本篇這樣的文章用UTF-8存儲比用UTF-32節省4倍左右的空間。更小的空間佔用也意味着加載速度會快上4倍。
而MySQL中的 “utf8”字符集則和其他應用行爲不一樣。比如根本沒法表示“”。
一點關於MySQL的歷史
爲什麼MySQL的開發者開發了一個奇怪的“utf8”。我們可以通過提交的日誌來揣測一下。
MySQL從4.1版開始支持UTF-8。那是在比今天UTF-8 RFC 3629標準更早的2003年。
在此之前的UTF-8標準,RFC 2279中規定6個bytes表示一個字符。MySQL的開發者在2002.3.28編碼實現了RFC 2279 。併發布了pre-pre-release 的 MySQL 4.1
然後在9月出現了一個神祕的字節調整。“UTF8 now works with up to3 byte sequences only.”
是誰提交了這次更新？爲什麼？我無法解答。MySQL的源碼移到Git後丟失了舊的作者信息（MySQL 曾經和linux內核一樣使用BitKeeper）
但是我大概能猜出來原因。
回到2002年，如果用戶可以保證表中的每一行具有相同的字節數，MySQL就可以提高用戶的速度。爲了得到這個提升，用戶就需要定義保存文字的列爲“CHAR”。一個“CHAR”列總是擁有相同的字符數。如果存入的字符較少則會在最後補齊空白。如果存入的數據過多則會被拋棄多餘的字符。
當MySQL的開發者第一次嘗試以6字節每字符實現UTF-8時，他們意識到CHAR(1)的列會佔用6字節，CHAR(2)會佔用12字節，以此類推。
顯而易見的是，這個沒有被使用的實現方式是正確的，任何一個理解UTF-8的開發者將會認同這一點。
我的猜測是：MySQL的開發者違背了“utf8”編碼去幫助那些1)試圖去優化空間和速度的人，2）嘗試優化空間和速度失敗的人。
這是個無人獲益的改動。那些想要更快性能，更小空間的得到的依然是比他們曾經使用版本更大更慢的實現，而那些想要正確的“utf8”的人得到的是個“”都存儲不了的實現。
MySQL發佈了這個錯誤的版本後，在也沒有修復它：因爲那樣很多使用者將被迫重建他們的數據庫。MySQL最終在2010年更新了一個以“utf8mb4”命名的UTF-8實現。
Why it’s so frustrating
這周我過得很操蛋。我遇到一個很難發現的bug，就因爲我被“utf8”這個名字給愚弄了。而且我也不是個案，我發現幾乎每篇推薦使用“utf8”的文章都錯了。
“utf8”的命名在mysql依然是錯的。這是個專有的實現。這造成了新的問題，而且沒有解決他應該解決的問題。
————————————————
版權聲明：本文爲CSDN博主「冷子夜」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_29180565/article/details/97892680