快捷導(dǎo)航

詳解MySQL collation 差異導(dǎo)致的類型比較行為不同

更新時(shí)間：2026年07月29日 09:45:07 作者：寧小法先森︿(￣︶￣)︿

MySQL數(shù)據(jù)庫查詢差異源于collation排序規(guī)則不同,本文就來詳細(xì)的介紹一下MySQL collation 差異導(dǎo)致的類型比較行為不同,感興趣的可以了解一下

CREATE TABLE `users_amoe_record` (
  `id` int NOT NULL AUTO_INCREMENT,
  `user_id` int NOT NULL DEFAULT '0',
  `key` varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
  `code` char(12) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
  `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0 初始化；1已創(chuàng)建；3 成功收到來信 4收到但過期 5收到但異常',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_id` (`user_id`,`code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=37494 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

但是另外數(shù)據(jù)庫的數(shù)據(jù)表, code為int也可以查詢到

CREATE TABLE `users_amoe_record` (
  `id` int NOT NULL AUTO_INCREMENT,
  `user_id` int NOT NULL DEFAULT '0',
  `key` varchar(255) NOT NULL DEFAULT '',
  `code` char(12) NOT NULL DEFAULT '',
  `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0 初始化；1已創(chuàng)建；3 成功收到來信 4收到但過期 5收到但異常',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_id` (`user_id`,`code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=460090 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

MySQL collation 差異導(dǎo)致的類型比較行為不同

根本原因

兩個庫的區(qū)別：

	問題庫	正常庫
code 列 collation	utf8mb4_general_ci	utf8mb4_0900_ai_ci
MySQL 版本	通常 5.7 或早期 8.0	MySQL 8.0+ 默認(rèn)

當(dāng) PHP 通過 PDO 綁定整數(shù)參數(shù)時(shí)：

utf8mb4_0900_ai_ci：MySQL 8.0 新排序規(guī)則，對 CHAR 列和整數(shù)的混合類型比較做了正確處理，能找到記錄
utf8mb4_general_ci：舊排序規(guī)則，PDO 以 PDO::PARAM_INT 傳入整數(shù)時(shí)，MySQL 對 CHAR(12) 列的類型推導(dǎo)出現(xiàn)偏差，比較失敗，查不到記錄

本質(zhì)是：PDO 發(fā)送整數(shù)類型參數(shù) + CHAR 字符列 + general_ci 排序規(guī)則 = MySQL 類型推導(dǎo)錯誤。

修復(fù)方案

在 callback() 里對 $code 強(qiáng)轉(zhuǎn)為字符串，讓 PDO 以字符串參數(shù)發(fā)送，與 CHAR(12) 列類型一致：

Read AmoeService.php (lines 120-129)Edit AmoeService.php

Modified

同理，getCaptcha 里查記錄時(shí)也用了整數(shù)查詢，也應(yīng)該修：

Read AmoeService.php (lines 70-77)

getCaptcha 的查詢已經(jīng)有 (string) 強(qiáng)轉(zhuǎn)，不需要改。只需要修 callback 的這一處。

總結(jié)

項(xiàng)	說明
根因	utf8mb4_general_ci 排序規(guī)則下，PDO 整數(shù)參數(shù)無法匹配 CHAR(12) 列
為什么另一庫沒問題	utf8mb4_0900_ai_ci（MySQL 8.0 默認(rèn)）正確處理了混合類型比較
修復(fù)	$code = (string)$params["code"] — PDO 以字符串傳參，與列類型一致
診斷日志	確認(rèn)問題后可以清理掉 ioLog("1") 等調(diào)試打點(diǎn)

到此這篇關(guān)于詳解MySQL collation 差異導(dǎo)致的類型比較行為不同的文章就介紹到這了,更多相關(guān)MySQL collation 差異內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: