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 小时。
