mysql 從 4.1 版本開始支援 utf-8，也就是 2003 年，而今天使用的 utf-8 標準（rfc 3629）是隨後才出現的。
舊版的 utf-8 標準（rfc 2279）最多支援每個字元 6 個位元組。2002 年 3 月 28 日，mysql 開發者在第乙個 mysql 4.1 預覽版中使用了 rfc 2279。
2002 年，mysql 做出了乙個決定：如果使用者可以保證資料表的每一行都使用相同的位元組數，那麼 mysql 就可以在效能方面來乙個大提公升。為此，使用者需要將文字列定義為「char」，每個「char」列總是擁有相同數量的字元。如果插入的字元少於定義的數量，mysql 就會在後面填充空格，如果插入的字元超過了定義的數量，後面超出部分會被截斷。
mysql 開發者在最開始嘗試 utf-8 時使用了每個字元 6 個位元組，char(1) 使用 6 個位元組，char(2) 使用 12 個位元組，並以此類推。
應該說，他們最初的行為才是正確的，可惜這一版本一直沒有發布。但是文件上卻這麼寫了，而且廣為流傳，所有了解 utf-8 的人都認同文件裡寫的東西。
不過很顯然，mysql 開發者或廠商擔心會有使用者做這兩件事：
使用 char 定義列（在現在看來，char 已經是老古董了，但在那時，在 mysql 中使用 char 會更快，不過從 2005 年以後就不是這樣子了）。
將 char 列的編碼設定為「utf8」。
我的猜測是 mysql 開發者本來想幫助那些希望在空間和速度上雙贏的使用者，但他們搞砸了「utf8」編碼。
所以結果就是沒有贏家。那些希望在空間和速度上雙贏的使用者，當他們在使用「utf8」的 char 列時，實際上使用的空間比預期的更大，速度也比預期的慢。而想要正確性的使用者，當他們使用「utf8」編碼時，卻無法儲存像「」這樣的字元。
在這個不合法的字符集發布了之後，mysql 就無法修復它，因為這樣需要要求所有使用者重新構建他們的資料庫。最終，mysql 在 2010 年重新發布了「utf8mb4」來支援真正的 utf-8。
永遠不要在 MySQL 中使用 utf8
永遠不要在 mysql 中使用 utf8 最近我遇到了乙個 bug，我試著通過 rails 在以 utf8 編碼的 mariadb 中儲存乙個 utf 8 字串，然後出現了乙個離奇的錯誤 incorrect string value xf0 x9f x98 x83 for column summar...
永遠不要在MySQL中使用UTF 8
最近我遇到了乙個bug，我試著通過rails在以 utf8 編碼的mariadb中儲存乙個utf 8字串，然後出現了乙個離奇的錯誤 incorrect string value xf0 x9f x98 x83 for column summary at row 1我用的是utf 8編碼的客戶端，伺服...
不要在MySQL使用UTF 8
最近我遇到了乙個bug，我試著通過rails在以 utf8 編碼的mariadb中儲存乙個utf 8字串，然後出現了乙個離奇的錯誤 incorrect string value xf0 x9f x98 x83 for column summary at row 1 我用的是utf 8編碼的客戶端，伺...