error 1062 表示主键或唯一索引冲突，应先查重再排查id生成逻辑，禁用insert ignore掩盖问题，优先用on duplicate key update；插入后须执行show warnings检查隐式截断或转换。
看到 ERROR 1062 就该查唯一键，不是先改代码
MySQL 报 ERROR 1062: Duplicate entry 'xxx' for key 'PRIMARY' 或类似提示时，本质是主键或唯一索引冲突，不是语法错、也不是连不上——它非常明确地告诉你：你正试图插入一条“身份已存在”的记录。
- 立刻执行
SELECT * FROM table_name WHERE id = 'xxx'（把报错里的值代入），确认是否真有重复 - 检查 INSERT 语句是否漏写了自增字段却显式赋了已存在的值；或者用程序生成 ID 时没做去重
- 别急着加
INSERT IGNORE掩盖问题：它会静默跳过，可能掩盖业务逻辑缺陷（比如注册时邮箱重复却没给用户提示） - 真正需要“存在则更新”的场景，用
ON DUPLICATE KEY UPDATE更安全可控
导入大 SQL 文件失败？先看 ERROR at line X 和 BOM 头
用 mysql -u user -p db_name 导入时报错，但没说清哪条语句出问题，常见原因是文件本身带隐藏干扰项，而非 SQL 写错。
- 错误信息里出现
Unknown command '\ufeff'？说明文件开头有 UTF-8 BOM 头，用编辑器另存为“UTF-8 无 BOM”即可解决 -
ERROR at line 1234提示的行号，是 MySQL 解析器计数的行号，不等于文本编辑器显示的行号（空行、注释都算）；打开文件后往前多看几行，常会发现上一条 INSERT 缺少右括号或分号 - 中文乱码导致插入失败？检查三处字符集是否一致：
source data.sql文件编码、客户端连接字符集（SET NAMES utf8mb4）、目标表字段字符集（SHOW CREATE TABLE t）
PHP 中插入失败却不报错？开启 PDO::ATTR_ERRMODE 是底线
很多 PHP 插入失败“无声无息”，其实是 PDO 默认不抛异常，只返回 false，而开发者没检查返回值，就当成功了。
- 初始化 PDO 时必须设置：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)，否则execute()出错只会返回false，不会触发catch - 错误信息里出现
SQLSTATE[HY000]: General error: 1366 Incorrect string value？大概率是往utf8字段插了 emoji，但字段实际是旧utf8（非utf8mb4）编码 - 不要拼接变量进 SQL 字符串！哪怕只是调试也容易引入语法错误或注入风险；预处理语句才是唯一靠谱写法：
$stmt = $pdo->prepare("INSERT INTO t (name) VALUES (?)"); $stmt->execute([$name]);
SHOW WARNINGS 比日志更及时，尤其当插入“看似成功”却丢数据
有些插入操作 MySQL 不报错，只发警告（Warning），比如字符串超长被截断、数值超出范围自动转为边界值——这时 INSERT 返回成功，但数据已失真。
- 每次执行完 INSERT 后，紧跟着执行
SHOW WARNINGS，查看是否有Data truncated或Out of range类提示 - 严格模式（
STRICT_TRANS_TABLES）下这类警告会升级为错误，但很多老库没开；别依赖它，主动查才保险 - 批量插入时，
SHOW WARNINGS只显示最后一条语句的警告，如需逐行验证，得拆成单条执行或加日志埋点
最常被忽略的是：插入成功不等于数据正确。截断、隐式转换、时区偏移、外键静默置空……这些都不会中断执行，却悄悄破坏数据一致性。定位失败，不能只盯着“报错”，得盯住“没报错但不对劲”的地方。
