MySQL Error 1366: Incorrect integer value 根因分析與解決方案

錯誤現場

Windows 遷移至 Linux 後，應用插入數據報錯：

[Err] 1366 - Incorrect integer value: '' for column 'shunxu' at row 1
INSERT INTO doc_main (..., shunxu, ...) VALUES (..., '', ...);

字段 shunxu 定義為 INT，傳入空字符串 '' 導致類型轉換失敗。

核心原因：SQL Mode 差異

STRICT_TRANS_TABLES 啟用後，非法數據 (空串→數字、超範圍、截斷) 直接拋錯而非截斷警告。

三種解決方案 (按推薦度排序)

方案一：修正應用層參數綁定 (根治，最規範)

確保傳入數據庫的值類型與表定義匹配：

• Java: PreparedStatement.setInt() 而非 setString()
• PHP: (int)$val 或 intval() 強制轉型
• Python: int(val) 處理空值邏輯
• Go: 使用 sql.NullInt64 處理可空整數

-- 應用層邏輯示例 (PHP)
$shunxu = isset($_POST['shunxu']) && $_POST['shunxu'] !== '' ? (int)$_POST['shunxu'] : 0;
$stmt->bind_param('i', $shunxu);

方案二：給字段設置 DEFAULT 0 (快速止血)

ALTER TABLE `doc_main` MODIFY COLUMN `shunxu` INT NOT NULL DEFAULT 0;

• INSERT 不指定該列或傳 NULL 時自動填 0
• 傳空串 '' 在 STRICT 模式下仍報錯，需配合應用層修正

方案三：調整 SQL Mode (不推薦生產環境)

-- 會話級臨時關閉 (僅當前連接)
SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';

-- 全局持久化 (需重啟生效，修改 my.cnf)
[mysqld]
sql_mode = "NO_ENGINE_SUBSTITUTION"

風險：關閉嚴格模式會掩蓋數據質量問題，導致臟數據入庫 (如 'abc' 插入 INT 變 0)，長期維護成本極高。

遷移檢查清單

1. SHOW VARIABLES LIKE 'sql_mode'; 對比新舊環境差異
2. 掃描應用代碼：搜尋 setString/bind_param('s') 對應 INT 列的調用
3. 補全所有數值類型列的 NOT NULL DEFAULT 0 (或業務默認值)
4. 啟用測試環境相同 SQL Mode 進行全量回歸測試
5. 上線前備份、灰度發布、監控 Error 1366 日志

相關錯誤擴展

嚴格模式是數據質量的守門員，遷移升級時務必對齊 SQL Mode，從源頭修正參數綁定，而非降級防線。