MySQL混合utf8 utf8mb4是否比純utf8mb4更具優(yōu)勢？
問題描述
表太多，僅昵稱和評論設(shè)置utf8mb4，config、tag、router等完全用不到utf8mb4的，依舊utf8這種utf8 utf8mb4混合會(huì)對搜索、索引和log記錄有影響嗎？這種方式比純utf8mb4更快速嗎？是否穩(wěn)定？mysqld配置中是否需要修改什么配置、優(yōu)化utf8mb4
PHP代碼DB_CHARSET設(shè)置utf8mb4，會(huì)對uft8數(shù)據(jù)有影響嗎？
問題解答
回答1：沒有太多優(yōu)勢因?yàn)閡tf8mb4僅在emoji等特殊字符的時(shí)候用到了4個(gè)字節(jié)存儲(chǔ)其余時(shí)候表現(xiàn)和mysql的utf8字符集是一樣的, 存儲(chǔ)漢字仍然是3個(gè)字節(jié)
(因?yàn)閙ysql的utf8字符集的單個(gè)字符的最大長度方面的實(shí)現(xiàn)是錯(cuò)誤的, 所以才冒出個(gè)utf8mb4字符集出來, 實(shí)際上這個(gè)utf8mb4就是標(biāo)準(zhǔn)的utf8)
當(dāng)然, 需要避免使用char, 改用varchar, 因?yàn)閙ysql的char列類型在utf8mb4下, 為了保證所有的數(shù)據(jù)都存的下, char將會(huì)占用字符數(shù)*4的字節(jié)數(shù) (mysql的char列類型utf8將占用字符數(shù)*3的字節(jié)數(shù)), 以保證空間分配足夠. 所以建議用可變長度varchar, 以節(jié)省空間. 可變長度消耗的存儲(chǔ)空間為: 實(shí)際存儲(chǔ)需要的字節(jié)數(shù)+1或2個(gè)字節(jié)表達(dá)的長度.
另外對于純英文字符的列, 你可以另外考慮varbinary(可變長度binary)和binary列(適用于固定長度的英文字符, 例如密碼哈希)類型, 性能比varchar略好, 因?yàn)檫@個(gè)存儲(chǔ)二進(jìn)制數(shù)據(jù)
相關(guān)文章：
1. boot2docker無法啟動(dòng)2. docker-compose中volumes的問題3. 關(guān)docker hub上有些鏡像的tag被標(biāo)記““This image has vulnerabilities””4. nignx - docker內(nèi)nginx 80端口被占用5. javascript - mock.js可以存儲(chǔ)數(shù)據(jù)嗎6. docker安裝后出現(xiàn)Cannot connect to the Docker daemon.7. java - SSH框架中寫分頁時(shí)service層中不能注入分頁類8. golang - 用IDE看docker源碼時(shí)的小問題9. docker api 開發(fā)的端口怎么獲取？10. dockerfile - 為什么docker容器啟動(dòng)不了？
網(wǎng)公網(wǎng)安備