快捷導(dǎo)航

MySQL編碼不一致可能引起的一些問題

更新時(shí)間：2020年11月23日 09:21:12 作者：arstercz

這篇文章主要給大家介紹了關(guān)于MySQL編碼不一致可能引起的一些問題的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

存儲過程與編碼

MySQL 存儲過程中, 表和數(shù)據(jù)的編碼與數(shù)據(jù)庫和存儲過程默認(rèn)的編碼不同則可能出現(xiàn) sql 不會使用索引的情況, 因?yàn)?MySQL 會對條件列的數(shù)據(jù)做相應(yīng)的編碼轉(zhuǎn)換, 比如以下, 表數(shù)據(jù)為 latin1, MySQL 解析器會做一些轉(zhuǎn)換:

... WHERE namecolumn = NAME_CONST('in_namecolumn',_utf8'MP201022' COLLATE 'utf8_general_ci')

可以在存儲過程中進(jìn)行相應(yīng)的編碼轉(zhuǎn)換(通常修改 varchar/char 字段)使得可以正常使用索引, 更多見: mysql-slow-when-run-as-stored-proc

... WHERE namecolumn = convert(in_namecolumn using latin1) collate latin1_swedish_ci

jdbc 直連執(zhí)行 sql

通過 jdbc 連接執(zhí)行 sql 的時(shí)候, 如果編碼不一致, 同樣需要對 varchar, char 類型進(jìn)行轉(zhuǎn)換, 如下所示:

... WHERE namecolumn = convert(in_namecolumn using latin1) collate latin1_swedish_ci

否則可能出現(xiàn)以下編碼不一致的錯(cuò)誤(隨 mysql-connector 版本不同可能有不同的行為):

SQL state [HY000]: error code [1267]: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '='

jdbc useSSL 參數(shù)變更

在 mysql-connector-java 配置中, useSSL 參數(shù)有以下不同, 從 5.1.38 開始 useSSL 開始按 MySQL 5.5.45+, 5.6.26+ or 5.7.6+ 的版本默認(rèn)開啟, 對應(yīng)的 requireSSL, verifyServerCertificate 兩個(gè)參數(shù)也會跟著開啟:

< 5.1.38:
 ConnectionProperties.useSSL=Use SSL when communicating with the server (true/false), defaults to 'false'

>= 5.1.38
 ConnectionProperties.useSSL=Use SSL when communicating with the server (true/false), default is 'true' when connecting to MySQL 5.5.45+, 5.6.26+ or 5.7.6+, otherwise default is 'false'

MySQL 5.7.x 及以上的版本, 默認(rèn)會啟用 ssl, 客戶端連接的時(shí)候會自協(xié)商加密, 除非顯示指定不加密. mysql-connector-java 從 5.1.38 開始默認(rèn)開啟 useSSL. 所以用低版本 jdbc 連接 MySQL 5.7.x 不會有加密的問題, 用高版本 jdbc 連接 5.7.6+ 以上會有加密問題, 需要顯示指定 useSSL=false, 用高版本的 jdbc 連接 MySQL 5.5, 5.6 不會有加密問題.

到此這篇關(guān)于MySQL編碼不一致可能引起的一些問題的文章就介紹到這了,更多相關(guān)MySQL編碼不一致引起的問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: