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也就夠了。
二、內容描述
那上面說了既然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。
4樓：愛可生雲資料庫
整理 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問題,為什麼設定為允許為空的欄位卻差不進去控值呢
如果你允許為空的欄位資料型別為int或其他數字型別，則不允許插入null，插入的時候什麼都不寫就行insert into table 欄位1,欄位2 int,允許空 欄位3 values value1,value3 上面是個簡單的例子，可能mysql語法有點不一樣 除了數字型別的欄位，直接插入nul...
為什麼要設定eclipse workspace
這是你建立工程之後的儲存的路徑，你建立的檔案都放在這個目錄的中的。如果每次開啟之後都會出現這個，就選中下面的框，意思是預設的路徑是這個，以後開啟就不會再彈出了，當然了，你自己也可以建立路徑的。解釋的很清楚了，希望能幫到你.專案工程目錄，並且新加的外掛 和使用習慣也會儲存在下面 這個是 eclipse...
phpstudy啟動後為什麼mysql無法啟動
1.安裝準備 拷貝my.ini檔案到c windows下，確定my.ini中的配置正確 2.安裝 mysqld install 3.啟動服務 net start mysql 4.使用 mysql uroot p 看埠是不是被佔了 請叫我園成 phpstudy啟動後為什麼mysql無法啟動 1.安裝準...