mysql错误代码1062表示唯一约束冲突，需通过SHOW CREATE table定位索引，再查重或改用INSERT … ON DUPLICATE KEY UPDATE；1213是死锁，依日志锁信息调整事务顺序并重试；1045为认证失败，核对user@host、权限及认证插件；“Truncated”警告源于隐式转换截断，应开严格模式并校验数据类型。
MySQL 错误代码 1062：Duplicate entry 是什么，怎么快速定位
这是最常见的写入类错误，表示试图插入或更新的值违反了唯一约束（如 PRIMARY KEY 或 UNIQUE 索引）。错误信息形如：Duplicate entry 'xxx' for key 'yyy'，其中 'xxx' 是冲突的值，'yyy' 是索引名。
实操建议：
- 先用
SHOW CREATE TABLE `table_name`;查看表结构，确认哪个字段/组合有UNIQUE或PRIMARY KEY约束 - 检查 SQL 中插入的值是否已存在，例如执行：
SELECT * FROM table_name WHERE column_name = 'xxx'; - 若业务允许覆盖，改用
INSERT ... ON DUPLICATE KEY UPDATE；若需忽略，用INSERT IGNORE（注意：它会静默跳过，不报错也不返回影响行数） - 避免在应用层靠“先查再插”防重——并发下仍有竞态风险
MySQL 错误代码 1213：Deadlock found when trying to get lock
这不是配置或语法问题，而是两个及以上事务互相等待对方持有的锁，触发了 InnoDB 的死锁检测机制。MySQL 会自动回滚其中一个事务（被选为 victim），抛出该错误。
实操建议：
- 错误日志里紧随其后的
*** (1) WAITING FOR this LOCK TO BE GRANTED和*** (2) HOLDS THE LOCK(S)段落，明确指出了哪条 SQL 在等锁、哪条 SQL 持有锁——这是关键线索 - 确保事务内 DML 操作按相同顺序访问表和行（比如始终先更新
users再更新orders），能大幅降低死锁概率 - 减少事务粒度：把长事务拆成多个短事务；避免在事务中做 rpc、文件读写等耗时操作
- 应用层捕获该错误后应重试（通常最多 1–3 次），而不是直接失败
MySQL 错误代码 1045：access denied for user
认证失败，常见于连接阶段。错误信息中会包含具体用户名、主机（'user'@'host'）和使用的认证插件（如 caching_sha2_password）。
实操建议：
- 确认连接时指定的用户名、密码、host 是否与
mysql.user表中记录完全一致（注意：host 匹配支持%通配，但不匹配 localhost —— 它走 socket 连接，而127.0.0.1才走 TCP） - 检查用户权限：运行
SHOW GRANTS FOR 'user'@'host';，确认是否有对应数据库/表的操作权限 - 如果用的是 MySQL 8.0+ 默认的
caching_sha2_password插件，而客户端（如旧版 PHP mysqli、某些 JDBC 驱动）不支持，需显式降级认证方式：ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password BY 'password'; - 修改后务必执行
FLUSH PRIVILEGES;
错误信息里出现 “Truncated incorrect X value” 怎么查
这类警告（常伴随错误代码 1265）说明 MySQL 在隐式类型转换时丢弃了数据，比如把字符串 '123abc' 转成整数只取了 123，或把超长字符串插入 VARCHAR(10) 字段被截断。
实操建议：
- 开启严格模式（
STRICT_TRANS_TABLES或STRICT_ALL_TABLES）可让这类问题直接报错而非静默截断，便于早期暴露问题 - 检查 SQL 中涉及的字段类型与传入值是否匹配：数字字段别传空字符串或带单位的文本；日期字段别传
'2023-02-30'这种非法日期 - 使用
SHOW WARNINGS;查看最近语句产生的所有截断/转换警告，比单看错误信息更全 - 对用户输入做服务端校验，不要依赖 MySQL 的隐式转换兜底
实际处理时，最易被忽略的是错误上下文——比如 1062 报错时没看清是哪个索引、1213 死锁日志没读完就重启应用、1045 没注意 host 是 localhost 还是 127.0.0.1。这些细节往往决定排查是 5 分钟还是 5 小时。