默认值本身不拖慢insert，真正瓶颈在于索引更新、触发器、事务提交及隐式计算；带函数的默认值需实时求值，orm显式传值反而绕过优化；应避免隐式类型转换、冗余索引，并用批量事务和load data提升性能。
默认值本身不会拖慢 INSERT，真正变慢的是你没意识到的隐式开销：索引更新、触发器执行、事务提交频率，以及字段类型与默认值表达式之间的隐式计算成本。
INSERT 含 DEFAULT 列时性能下降的真实原因
很多人以为 DEFAULT CURRENT_TIMESTAMP 或 DEFAULT 18 是“免费午餐”，其实 MySQL 在每条插入时仍需做几件事：解析默认值表达式、检查是否被显式跳过、在写入行数据前补全字段值、再同步更新所有相关索引。尤其当表上有多个带默认值的列（比如 created_at、updated_at、status），这些操作会叠加。
- 带函数的默认值（如
CURRENT_TIMESTAMP、UUID()）每次都要实时求值，无法预编译 - 如果该列上有索引（哪怕只是普通二级索引），补默认值后仍要写入 B+ 树叶子节点
- 某些 ORM（如旧版 MyBatis）在生成 SQL 时，会把所有字段都显式列出，连带把
DEFAULT值硬编码进去，反而绕过了 MySQL 的默认值机制 -
NOT NULL DEFAULT列若被漏写，报错发生在语义分析阶段，但错误提示常被误读为“默认值没生效”
如何验证 DEFAULT 是否真成了瓶颈
别猜，用 EXPLAIN FORMAT=JSON 或开启慢日志抓取实际执行计划。更直接的方法是临时禁用默认行为做对比：
- 用
SHOW CREATE TABLE users;确认哪些列有DEFAULT及其表达式类型 - 执行
INSERT INTO users (username, email) VALUES ('a', 'a@b.c');（只写必填列），观察耗时 - 再执行
INSERT INTO users (username, email, age, created_at) VALUES ('a', 'a@b.c', 18, NOW());（显式填所有列），对比是否明显变慢 - 若后者显著更慢，说明问题出在客户端拼 SQL 的方式或字段类型隐式转换上，而非默认值本身
真正有效的优化手段
重点不是删默认值，而是减少它被反复触发的上下文：
- 确保 INSERT 语句中**不显式列出**带默认值且无需覆盖的列——让 MySQL 自己补，而不是让应用层传
NULL或空字符串再由数据库转义 - 避免对带默认值的列建冗余索引；例如
status列只有 3 个取值，INDEX(status)几乎无查询收益，却强制每次插入都多一次索引页分裂 - 批量插入时，统一用
START TRANSACTION包裹，否则每个INSERT都要刷一次 redo log + 更新所有默认值相关索引 - 如果使用
LOAD DATA INFILE导入，MySQL 会跳过默认值解析逻辑（除非用SET子句显式赋值），速度提升最明显
容易被忽略的陷阱：隐式类型转换放大默认值开销
这是最隐蔽的一类性能损耗。比如定义了 score INT DEFAULT 0，但应用层传入的是字符串 "0"，MySQL 就得在插入前做 CAST("0" AS SIGNED) —— 这个转换动作会阻止某些优化路径，还会让索引统计失真。更糟的是，如果该列被用于 WHERE score = "0" 查询，整个索引就失效了。
- 检查应用层传参类型是否与列定义严格一致：整型列就传数字，时间列就传
'2026-09-28 14:00:00'字符串，别传 JS 的new Date()对象 - 用
SELECT COLUMN_NAME, DATA_TYPE, COLUMN_DEFAULT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'users';扫描所有默认值列的数据类型 - 对含
JSON或TEXT默认值的列，务必确认是否真需要每次插入都生成新值；很多场景下用NULL+ 应用层兜底更轻量
默认值不是性能敌人，失控的上下文才是。最常出问题的不是 DEFAULT 18，而是你一边写着 INSERT ... VALUES (?, ?, ?)，一边在 PreparedStatement 中把第三个参数设为 null，结果 MySQL 不得不从元数据里查定义、判断是否允许为 NULL、再回退到默认值逻辑——这一来一回，比直接传 18 多花 3 倍 CPU 时间。
