字段错位是列位置不匹配导致的数据错插，而非语法错误；MySQL、Oracle、SQL Server均按SELECT列序与INSERT目标列序严格位置对应，必须显式书写字段名并确保顺序一致，否则易引发静默错存。
INSERT 语句写错字段顺序导致数据错位
MySQL 不校验 INSERT 中值与字段名的语义匹配，只按位置一一对应。如果省略字段列表，又没按建表顺序提供值，数据就会插进错误列。
比如建表是 CREATE TABLE user (id INT, name VARCHAR(20), age TINYINT)，却执行 INSERT INTO user VALUES ('Alice', 25, 1001)，结果 name 存了 'Alice'，age 存了 25，而 id 反而成了 1001——看着像对，实则全乱。
- 始终显式写出字段列表：
INSERT INTO user (id, name, age) VALUES (1001, 'Alice', 25) - 字段列表和
VALUES中的值数量、类型、顺序必须严格一致 - 对可空字段或有默认值的字段，若不想赋值，显式写
NULL或省略该字段（前提是字段定义含DEFAULT或NULL）
批量插入时遇到主键冲突或重复数据
用 INSERT ... VALUES (...), (...), (...) 批量插入时，只要其中一行违反主键/唯一约束，整条语句会失败并回滚（除非启用了 IGNORE 或使用 ON DUPLICATE KEY UPDATE）。
常见场景：前端重复提交、定时任务未去重、导入脚本未判重。
- 想跳过冲突行，加
INSERT IGNORE INTO ...——冲突时静默忽略，不报错也不插入 - 想更新已存在记录，用
INSERT ... ON DUPLICATE KEY UPDATE name=VALUES(name), age=VALUES(age) - 想严格保证全部成功或全部失败，就别用
IGNORE，而是先SELECT检查再插入，或用事务包裹 + 唯一索引约束兜底
中文插入显示问号或乱码
现象是字段存进去后查出来是 ??? 或方块，不是字符损坏，而是客户端、连接、表三者字符集不统一。
关键点不在建表时用了 utf8mb4，而在于连接建立时是否声明了正确编码。
- 确认表字符集：
SHOW CREATE TABLE user，确保含CHARSET=utf8mb4 - 确认连接字符集：执行
SHOW VARIABLES LIKE 'character_set%'，重点关注character_set_client、character_set_connection、character_set_results是否都为utf8mb4 - 应用层连接串中显式指定：
?charset=utf8mb4（如 JDBC 的jdbc:mysql://localhost:3306/db?charset=utf8mb4） - 避免只改表不改连接，或只改连接不改表——三者（客户端、连接、表）缺一不可
自增主键没生效或跳号
INSERT 后查不到刚插入的 ID，或发现 ID 不连续（比如插了 3 条，ID 却是 1、3、6），多数不是 bug，而是设计行为或隐式操作触发。
- 获取刚插入的自增 ID，请用
SELECT LAST_INSERT_ID()（会话级，安全），不要依赖MAX(id) - ID 跳号常见原因：事务回滚、
REPLACE INTO、INSERT ... ON DUPLICATE KEY UPDATE、批量插入部分失败、MySQL 重启后预分配 - 自增 ID 不保证连续，只保证递增和唯一；业务逻辑不应依赖“连续性”
INSERT 时，最容易被忽略的是连接层字符集和事务边界——前者让数据看起来“丢了”，后者让重复插入看似成功实则未持久化。 
