显式列名可避免表结构变更导致的插入失败，提升可读性与维护性，并支持部分字段插入、默认值及跨数据库兼容。
显式列名能避免表结构变更导致的插入失败
当你用 INSERT INTO table VALUES (...) 时，SQL 会按表定义的字段顺序（从第2列开始，跳过自增 ID）一一匹配值。一旦有人在表中间加了个新字段（比如在 name 和 email 之间加了 phone），所有没写列名的 VALUES 插入就会错位——email 值被塞进 phone 字段，phone 值被塞进 email，轻则数据错乱，重则因类型不匹配直接报错 ERROR 1265 (01000): Data truncated for column 'phone'。
显式写 INSERT INTO table (name, email) VALUES ('a', 'b') 就完全绕开这个风险：新增字段不影响已有语句，缺失字段走默认值或 NULL（前提是允许）。
显式列名让代码可读性和维护性直线上升
看到 INSERT INTO user VALUES (1, 'alice', 'alice@x.com', '2025-01-01')，你得翻表结构才能确认第3个值是邮箱还是注册时间；而 INSERT INTO user (id, username, email, created_at) VALUES (1, 'alice', 'alice@x.com', '2025-01-01') 一眼就懂。
- 协作时别人不用查文档就能改代码
- 字段顺序调整、重命名、删字段时，只需改列名列表，不用动值顺序
- ORM 或迁移脚本生成 SQL 时，显式列名是唯一安全选项
隐式 VALUES 不支持部分字段插入，也不兼容 NULL 和 DEFAULT
如果只想插 username 和 email，其他字段走默认值，用隐式 VALUES 必须填满所有非 ID 字段——哪怕填 NULL 或重复写 DEFAULT，既啰嗦又易出错。显式写法直接省略不需要的字段：
INSERT INTO user (username, email) VALUES ('bob', 'bob@x.com');
数据库自动对未指定字段应用 DEFAULT 或允许 NULL（按字段定义）。更关键的是：某些字段类型（如 TIMESTAMP 自动填充）在隐式模式下可能被误覆盖为 NULL，导致逻辑错误。
性能和执行计划其实没差别，但隐式写法容易引发隐式转换
很多人以为 * 或隐式 VALUES 更快——实际执行计划几乎一样。真正危险的是类型隐式转换：比如 INSERT INTO log (msg) VALUES (123)，数字 123 被转成字符串，可能触发全表扫描或索引失效；而显式写 INSERT INTO log (msg) VALUES ('123') 类型明确，优化器更容易选对索引。
最常被忽略的一点：不同数据库对隐式 VALUES 的列序解释略有差异（比如 InterSystems IRIS 把 ID 当第1列跳过，PostgreSQL 则严格按 pg_attribute 顺序），跨库迁移时这类语句几乎必然挂掉。
