為什麼MYSQL要設定用UTF8MB4編碼UTF8MB

2022-12-02 19:56:01 字數 5949 閱讀 8581

1樓:

mysql在5.5.3之後增加了這個utf8mb4的編碼,mb4就是most bytes

4的意思,專門用來相容四位元組的unicode。好在utf8mb4是utf8的超集,除了將編碼改為utf8mb4外不需要做其他轉換。當然,為了節省空間,一般情況下使用utf8也就夠了。

二、內容描述

那上面說了既然utf8能夠存下大部分中文漢字,那為什麼還要使用utf8mb4呢? 原來mysql支援的 utf8

編碼最大字元長度為 3 位元組,如果遇到 4 位元組的寬字元就會插入異常了。三個位元組的 utf-8 最大能編碼的 unicode 字元是

0xffff,也就是 unicode 中的基本多文種平面(bmp)。也就是說,任何不在基本多文字平面的 unicode字元,都無法使用

mysql 的 utf8 字符集儲存。包括 emoji 表情(emoji 是一種特殊的 unicode 編碼,常見於 ios 和 android

手機上),和很多不常用的漢字,以及任何新增的 unicode 字元等等。

三、問題根源

最初的 utf-8 格式使用一至六個位元組,最大能編碼 31 位字元。最新的 utf-8 規範只使用一到四個位元組,最大能編碼21位,正好能夠表示所有的 17個 unicode 平面。

utf8 是 mysql 中的一種字符集,只支援最長三個位元組的 utf-8字元,也就是 unicode 中的基本多文字平面。

mysql 中的 utf8 為什麼只支援持最長三個位元組的 utf-8字元呢?我想了一下,可能是因為 mysql

剛開始開發那會,unicode 還沒有輔助平面這一說呢。那時候,unicode 委員會還做著 「65535

個字元足夠全世界用了」的美夢。mysql 中的字串長度算的是字元數而非位元組數,對於 char 資料型別來說,需要為字串保留足夠的長。當使用

utf8 字符集時,需要保留的長度就是 utf8 最長字元長度乘以字串長度,所以這裡理所當然的限制了 utf8 最大長度為 3,比如

char(100) mysql 會保留 300位元組長度。至於後續的版本為什麼不對 4 位元組長度的 utf-8

字元提供支援,我想一個是為了向後相容性的考慮,還有就是基本多文種平面之外的字元確實很少用到。

要在 mysql 中儲存 4 位元組長度的 utf-8 字元,需要使用 utf8mb4 字符集,但只有 5.5.3

版本以後的才支援(檢視版本: select version();)。我覺得,為了獲取更好的相容性,應該總是使用 utf8mb4 而非 utf8.

對於 char 型別資料,utf8mb4 會多消耗一些空間,根據 mysql 官方建議,使用 varchar 替代 char。

2樓:愛可生雲資料庫

整理 mysql 8.0 文件時發現一個變更:

預設字符集由 latin1 變為 utf8mb4。想起以前整理過字符集轉換文件,升級到 mysql 8.0 後大概率會有字符集轉換的需求,在此正好分享一下。

當時的需求背景是:

部分系統使用的字符集是 utf8,但 utf8 最多隻能存 3 位元組長度的字元,不能存放 4 位元組的生僻字或者表情符號,因此打算遷移到 utf8mb4。

遷移方案一1. 準備新的資料庫例項,修改以下引數:[mysqld]## character settingsinit_connect='set names utf8mb4'#連線建立時執行設定的語句,對super許可權使用者無效character-set-server = utf8mb4collation-server = utf8mb4_general_ci#設定服務端校驗規則,如果字串需要區分大小寫,設定為utf8mb4_binskip-character-set-client-handshake#忽略應用連線自己設定的字元編碼,保持與全域性設定一致## innodb settingsinnodb_file_format = barracudainnodb_file_format_max = barracudainnodb_file_per_table = 1innodb_large_prefix = on#允許索引的最大位元組數為3072(不開啟則最大為767位元組,對於類似varchar(255)欄位的索引會有問題,因為255*4大於767)

2. 停止應用,觀察,確認不再有資料寫入

可通過 show master status 觀察 gtid 或者 binlog position,沒有變化則沒有寫入。

3. 匯出資料

先匯出表結構:mysqldump -u -p --no-data --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=off --databases testdb > /backup/testdb.sql

後匯出資料:mysqldump -u -p --no-create-info --master-data=2 --flush-logs --routines --events --triggers --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=off --database testdb > /backup/testdata.sql

4. 修改建表語句

修改匯出的表結構檔案,將表、列定義中的 utf8 改為 utf8mb4

5. 匯入資料

先匯入表結構:mysql -u -p testdb < /backup/testdb.sql

後匯入資料:mysql -u -p testdb < /backup/testdata.sql

6. 建使用者

查出舊環境的資料庫使用者,在新資料庫中建立

7. 修改新資料庫埠,啟動應用進行測試

關閉舊資料庫,修改新資料庫埠重啟,啟動應用

為什麼mysql要設定用utf8mb4編碼utf8mb4

3樓:匿名使用者

mysql在5.5.3之後增加了這個utf8mb4的編碼,mb4就是most bytes

4的意思,專門用來相容四位元組的unicode。好在utf8mb4是utf8的超集,除了將編碼改為utf8mb4外不需要做其他轉換。當然,為了節省空間,一般情況下使用utf8也就夠了。

為什麼mysql要設定用utf8mb4編碼utf8mb4

4樓:匿名使用者

mysql在5.5.3之後增加了這個utf8mb4的編碼,mb4就是most bytes

4的意思,專門用來相容四位元組的unicode。好在utf8mb4是utf8的超集,除了將編碼改為utf8mb4外不需要做其他轉換。當然,為了節省空間,一般情況下使用utf8也就夠了。

二、內容描述

那上面說了既然utf8能夠存下大部分中文漢字,那為什麼還要使用utf8mb4呢? 原來mysql支援的 utf8

編碼最大字元長度為 3 位元組,如果遇到 4 位元組的寬字元就會插入異常了。三個位元組的 utf-8 最大能編碼的 unicode 字元是

0xffff,也就是 unicode 中的基本多文種平面(bmp)。也就是說,任何不在基本多文字平面的 unicode字元,都無法使用

mysql 的 utf8 字符集儲存。包括 emoji 表情(emoji 是一種特殊的 unicode 編碼,常見於 ios 和 android

手機上),和很多不常用的漢字,以及任何新增的 unicode 字元等等。

三、問題根源

最初的 utf-8 格式使用一至六個位元組,最大能編碼 31 位字元。最新的 utf-8 規範只使用一到四個位元組,最大能編碼21位,正好能夠表示所有的 17個 unicode 平面。

utf8 是 mysql 中的一種字符集,只支援最長三個位元組的 utf-8字元,也就是 unicode 中的基本多文字平面。

mysql 中的 utf8 為什麼只支援持最長三個位元組的 utf-8字元呢?我想了一下,可能是因為 mysql

剛開始開發那會,unicode 還沒有輔助平面這一說呢。那時候,unicode 委員會還做著 「65535

個字元足夠全世界用了」的美夢。mysql 中的字串長度算的是字元數而非位元組數,對於 char 資料型別來說,需要為字串保留足夠的長。當使用

utf8 字符集時,需要保留的長度就是 utf8 最長字元長度乘以字串長度,所以這裡理所當然的限制了 utf8 最大長度為 3,比如

char(100) mysql 會保留 300位元組長度。至於後續的版本為什麼不對 4 位元組長度的 utf-8

字元提供支援,我想一個是為了向後相容性的考慮,還有就是基本多文種平面之外的字元確實很少用到。

要在 mysql 中儲存 4 位元組長度的 utf-8 字元,需要使用 utf8mb4 字符集,但只有 5.5.3

版本以後的才支援(檢視版本: select version();)。我覺得,為了獲取更好的相容性,應該總是使用 utf8mb4 而非 utf8.

對於 char 型別資料,utf8mb4 會多消耗一些空間,根據 mysql 官方建議,使用 varchar 替代 char。

5樓:愛可生雲資料庫

整理 mysql 8.0 文件時發現一個變更:

預設字符集由 latin1 變為 utf8mb4。想起以前整理過字符集轉換文件,升級到 mysql 8.0 後大概率會有字符集轉換的需求,在此正好分享一下。

當時的需求背景是:

部分系統使用的字符集是 utf8,但 utf8 最多隻能存 3 位元組長度的字元,不能存放 4 位元組的生僻字或者表情符號,因此打算遷移到 utf8mb4。

遷移方案一1. 準備新的資料庫例項,修改以下引數:[mysqld]## character settingsinit_connect='set names utf8mb4'#連線建立時執行設定的語句,對super許可權使用者無效character-set-server = utf8mb4collation-server = utf8mb4_general_ci#設定服務端校驗規則,如果字串需要區分大小寫,設定為utf8mb4_binskip-character-set-client-handshake#忽略應用連線自己設定的字元編碼,保持與全域性設定一致## innodb settingsinnodb_file_format = barracudainnodb_file_format_max = barracudainnodb_file_per_table = 1innodb_large_prefix = on#允許索引的最大位元組數為3072(不開啟則最大為767位元組,對於類似varchar(255)欄位的索引會有問題,因為255*4大於767)

2. 停止應用,觀察,確認不再有資料寫入

可通過 show master status 觀察 gtid 或者 binlog position,沒有變化則沒有寫入。

3. 匯出資料

先匯出表結構:mysqldump -u -p --no-data --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=off --databases testdb > /backup/testdb.sql

後匯出資料:mysqldump -u -p --no-create-info --master-data=2 --flush-logs --routines --events --triggers --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=off --database testdb > /backup/testdata.sql

4. 修改建表語句

修改匯出的表結構檔案,將表、列定義中的 utf8 改為 utf8mb4

5. 匯入資料

先匯入表結構:mysql -u -p testdb < /backup/testdb.sql

後匯入資料:mysql -u -p testdb < /backup/testdata.sql

6. 建使用者

查出舊環境的資料庫使用者,在新資料庫中建立

7. 修改新資料庫埠,啟動應用進行測試

關閉舊資料庫,修改新資料庫埠重啟,啟動應用

mysql隔離級別設定為什麼比較好

一 首先什麼是事務?事務是應用程式中一系列嚴密的操作,所有操作必須成功完成,否則在每個操作中所作的所有更改都會被撤消。也就是事務具有原子性,一個事務中的一系列的操作要麼全部成功,要麼一個都不做。事務的結束有兩種,當事務中的所以步驟全部成功執行時,事務提交。如果其中一個步驟失敗,將發生回滾操作,撤消撤...

mysql資料庫表用什麼做主鍵,mysql設定主鍵的程式碼是什麼?

1 主鍵定義 表中經常有一個列或多列的組合,其值能唯一地標識表中的每一行。這樣的一列或多列稱為表的主鍵,通過它可強制表的實體完整性。當建立或更改表時可通過定義 primary key 約束來建立主鍵。一個表只能有一個 primary key 約束,而且 primary key 約束中的列不能接受空值...

出納知識 為什麼要設定出納崗位現金出納

答 1 現金bai 收付時,要當面點清du金額,並注意票面的zhi真偽。搞清dao楚這筆現金是什麼款回項,是否 答已開具發票 收據之類的憑據。2 把每日收到的現金送到銀行,不得 坐支 4 每日做好日常的現金盤存工作,做到賬實相符。做好現金結報單,防止現金盈虧。5 一般不辦理大面額現金的支付業務,支付...