MySQL字段NULL属性生效取决于建表或修改时显式声明NULL/NOT NULL约束，图形界面勾选仅是快捷方式；必须用SHOW CREATE TABLE验证真实定义，而非依赖界面或DESCRIBE；应用层须确保传入SQL NULL而非空字符串或字符串'NULL'。
MySQL 字段的 NULL 属性到底怎么设才生效
字段允许为空，不是勾了“允许为空”就完事——真正起作用的是建表语句里的 null 或 not null 约束，图形化工具（比如 phpmyadmin、navicat）里那个勾选框只是生成这个约束的快捷方式。一旦表已存在，改勾选框不等于自动执行 alter table ... modify column，它可能根本没保存。
- 新建字段时：勾选“允许为空” → 生成
xxx VARCHAR(255) NULL；不勾 → 生成xxx VARCHAR(255) NOT NULL - 修改已有字段：必须显式执行
ALTER TABLE t MODIFY COLUMN c INT NULL，否则即使界面显示已勾选，SHOW CREATE TABLE t里仍是NOT NULL - 某些客户端（如旧版 Navicat）在“设计表”里改完点保存，实际只发了
ALTER TABLE ... CHANGE COLUMN但漏掉NULL关键字，结果约束没变
用 DESCRIBE 和 SHOW CREATE TABLE 查真实状态
别信界面，也别只看 DESCRIBE table_name 的 Null 列——它确实显示 YES 或 NO，但这是当前定义值，不是历史操作是否成功。最可靠的是 SHOW CREATE TABLE，它返回建表语句原文，一眼看出字段后跟的是 NULL 还是 NOT NULL。
-
DESCRIBE users显示email行的Null是YES，但若之前改过又回退，可能不准 -
SHOW CREATE TABLE users\G里找`email` VARCHAR(100) NULL这一行，这才是铁证 - 如果字段有默认值（
DEFAULT 'guest'）且没写NULL，MySQL 会隐式加NOT NULL，哪怕你勾了允许为空
INSERT 时传 NULL 却报错：常见三类原因
明明字段设了 NULL，插入 NULL 还报 Column 'x' cannot be null，大概率不是设置问题，而是 SQL 没真传 NULL，或者触发了其他约束。
- PHP/Python 等语言里拼 SQL，把变量写成空字符串
''或字符串'NULL'，不是 SQL 的NULL常量 - 用了预处理，但绑定参数时传了
''而非null（PHP PDO）或None（Python sqlite3） - 字段虽允许
NULL，但加了UNIQUE约束，而表里已有一行该字段是NULL—— 注意：MySQL 中多个NULL不违反UNIQUE，但某些老版本或严格模式下行为异常
JSON 字段、生成列、外键对 NULL 的隐含限制
加了高级特性后，“允许为空”可能被覆盖或失效，不是 UI 勾选能控制的。
-
JSON类型字段可以设NULL，但如果你写了GENERATED ALWAYS AS (json_extract(...)) STORED，生成列默认是NOT NULL，除非显式加NULL - 外键字段设为
NULL是合法的（表示无关联），但父表对应值必须存在或为NULL；如果父表该字段是NOT NULL，子表外键仍可为NULL，这没问题 - 时间类型字段如
TIMESTAMP，若没设NULL且没给默认值，MySQL 5.6+ 会强制设默认为CURRENT_TIMESTAMP，此时插NULL会被转成当前时间，看起来像“不允许为空”
真正麻烦的从来不是勾不勾那个框，而是改完之后没验证语句是否执行、没查 SHOW CREATE TABLE、也没在应用层确认传进去的是 SQL NULL 而不是空字符串或未定义值。
