為什么在MySQL中將ENUM（“ 0”，“ 1”）保存為空字符串？

Question

我有一個MYSQL表，其中包含一個名為“ offset ”的ENUM字段和一些其他列。 該字段定義為：

ENUM（0,1）可以為NULL ，預定義值NULL

現在我有兩個服務器。 生產服務器和開發服務器以及用於創建和更新數據庫的相同PHP腳本。

第一步 ：應用程序創建記錄，並在CREATE查詢中傳遞“ offset ”。

第二步 ：應用程序向用戶詢問一些數據（不是“ offset”值），讀取第一步中插入的行並創建一個數組，更新某些字段（不是“ offset”字段），自動創建查詢設置樣式並使用更新后的值再次保存該行。

自動查詢構建器只需讀取數組中傳遞的所有字段並創建UPDATE字符串即可。

在兩個系統中，我都獲得此數組：

$values = array(... 'offset' => null);

並通過傳遞mysql_real_escape_string中的值的相同查詢將其轉換：

UPDATE MyTable SET values..., `offset` = '' WHERE id = '10';

現在有問題了。 當我在生產系統中啟動查詢時，該行被保存，在開發系統中，我收到一個錯誤，並且數據庫顯示偏移數據錯誤而不保存該行。

從phpmyadmin第一步創建行時，它在offset字段中顯示NULL。 將字段保存在沒有錯誤的系統中后，它顯示了一個空字符串。

兩種系統都使用MySQL 5，但生產在Linux上使用5.0.51，在Windows上使用5.0.37。

問題：

為什么一個系統給我一個錯誤而另一個系統給我一個錯誤呢？ 配置不同嗎？

為什么當我保存為枚舉“ 0”或“ 1”的字段時，為什么保存“”而不是NULL？

Answer 1

strager的答案似乎很好地解釋了為什么您的代碼在兩種環境下的行為不同。

問題出在其他地方。 如果要在查詢中將值設置為NULL，則應使用完全NULL，但要使用mysql_real_escape_string（），其結果始終是字符串：

$ php -r 'var_dump(mysql_real_escape_string(null));'
string(0) ""

您應該以不同的方式處理。 例如：

$value = null
$escaped_value = is_null($value) ? "NULL" : mysql_real_escape_string($value);
var_dump($escaped_value);
// NULL

一些DB層（例如PDO）可以很好地解決這一問題。

Answer 2

為什么一個系統給我一個錯誤而另一個系統給我一個錯誤呢？ 配置不同嗎？

大概。 見下文。

為什么當我保存為枚舉“ 0”或“ 1”的字段時，為什么保存“”而不是NULL？

根據MySQL ENUM文檔 ：

在某些情況下，該值也可以是空字符串（''）或NULL：

• 如果您在ENUM中插入無效值（即，在允許值列表中不存在的字符串）， 則將空字符串作為特殊錯誤值插入 。 通過將該字符串的數值設置為0，可以將該字符串與“常規”空字符串區分開。...

  如果啟用了嚴格的SQL模式，則嘗試插入無效的ENUM值將導致錯誤。

（已添加重點。）

Answer 3

如果您希望它為NULL ，那么為什么不首先這樣做：

UPDATE MyTable SET values..., `offset` = NULL WHERE id = 10;