mysql默认值无效主因是sql_mode启用严格模式（如strict_trans_tables），导致空字符串或null插入时拒绝隐式转换为默认值，而非初始化阶段问题；应修正数据或约束，而非关闭严格模式。
MySQL初始化不报“默认值无效”错误，这个错误实际发生在建表或插入阶段，不是初始化阶段的问题。你看到的“默认值无效”，比如 DECIMAL 字段设了 DEFAULT 0 却插入 NULL 或空值后变成 NULL，根源几乎总是 sql_mode 中启用了严格模式（如 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES），而非初始化本身出错。
为什么初始化成功后建表却提示默认值被忽略
MySQL 5.7+ 默认启用严格 SQL 模式，尤其在 mysqld --initialize 生成的配置中，sql_mode 通常包含 STRICT_TRANS_TABLES。此时：
- 若字段定义为
DECIMAL(10,2) DEFAULT 0 NOT NULL，但插入时传了空字符串''或NULL（即使没显式写该字段），严格模式会拒绝并报错，而不是静默转成0 - Navicat 等 GUI 工具批量导入时可能发空字符串，触发该行为
-
INSERT INTO t() VALUES()这种全默认插入是安全的；但只要某列值非法（如类型不匹配、超出精度），严格模式就中断
如何确认当前 sql_mode 是否启用严格模式
连接 MySQL 后执行：
SELECT @@sql_mode;
输出中若含 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES，就是它在起作用。常见组合如：
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
注意：NO_AUTO_VALUE_ON_ZERO 是另一个独立开关，和默认值生效无关，别混淆。
临时绕过：建表前动态调整 sql_mode
仅用于调试或迁移场景，不建议长期关闭严格模式：
- 会话级修改（当前连接有效）：
SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
- 立即生效，建表/插入即可用默认值兜底（如空字符串转
0） - 但该设置重启连接即失效，且不能解决应用层传错值的根本问题
生产环境正确做法：不改 sql_mode，而是修正数据和定义
严格模式是保护机制，关掉它等于掩盖问题。更健壮的解法是：
- 检查应用代码或导入脚本：是否把空字符串、
'-'、'N/A'当作数值传给DECIMAL字段？应提前过滤或转换 - 建表时明确约束：
price DECIMAL(10,2) DEFAULT 0 NOT NULL—— 强制非空，避免 NULL 污染 - 使用
COALESCE()或触发器做兜底，而不是依赖隐式转换 - 若必须兼容宽松行为，可在
my.cnf的[mysqld]段落中注释或删掉sql_mode行，让 MySQL 用编译默认值（MySQL 8.0 默认仍含 STRICT，所以删掉才真正禁用）
最后提醒：修改 my.cnf 后必须重启 MySQL，且 sql_mode 是全局变量，SET GLOBAL 修改需 SUPER 权限，普通用户不可行。最易被忽略的是——你以为改了配置文件，其实 mysqld --verbose --help | grep "Default options" 显示 MySQL 实际加载的是 /etc/mysql/my.cnf 而不是你编辑的 /etc/my.cnf。
