ERROR 1045 是权限问题，非密码错误，根本原因是 MySQL 中未创建对应 host 的用户（如 'root'@'%'），需检查 mysql.user 表并注意 localhost 与 127.0.0.1 的区别及 MySQL 8.0+ 认证插件兼容性。
ERROR 1045：Access denied 是权限问题，不是密码输错了就重装
这个错误最常被误判为“密码错了”，其实它真正想说的可能是：root 用户根本没被授权从你当前的 host 连接。比如你在服务器上用 mysql -u root -p 登录失败，但本地 localhost 能连——大概率是因为 MySQL 里只建了 'root'@'localhost'，没建 'root'@'127.0.0.1' 或 'root'@'%'。
检查方法很简单：
- 先用有权限的账号（如另一个
root）登录，执行SELECT User, Host FROM mysql.user;看实际存在的用户记录 - 确认你要连的 host 是否匹配，
localhost和127.0.0.1在 MySQL 中是两个不同用户，不能混用 - 如果是 MySQL 8.0+，还要注意认证插件：默认是
caching_sha2_password，老客户端不认，得手动切回mysql_native_password：ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES;
ERROR 2002 / 2003：连不上服务，先别急着改配置
Can't connect to local MySQL server 或 Can't connect to MySQL server 这类报错，90% 不是配置写错，而是服务压根没跑起来，或者被防火墙/SELinux 挡住了。
快速排查顺序：
- 查服务状态：
systemctl status mysqld（CentOS/RHEL）或systemctl status mysql（Ubuntu/Debian），看是不是active (running) - 查端口监听：
ss -tuln | grep :3306，如果没输出，说明 mysqld 没监听 TCP；再试ls -l /var/lib/mysql/mysql.sock，确认 socket 文件存在且路径和my.cnf里socket=配置一致 - 远程连接失败？先关防火墙临时测试：
systemctl stop firewalld（或ufw disable），再 telnet 测试端口通不通
ERROR 1064：SQL 语法错误，别只盯着少个分号
You have an error in your SQL syntax 是开发阶段最烦人的报错之一，但它往往不是语法本身的问题，而是上下文环境导致的。
微信公众号推文写作助手
下载
微信公众号推文写作与发布助手。支持深度文章撰写（1500+ 字）、智能配图搜索、API 配置引导、草稿箱上传、一键排版等全流程功能。 每篇文章默认 1500 字以上，配备 1 张相关配图（放在第一段后），包含清晰的分段标题结构。
常见真因：
- 用了 MySQL 8.0+ 的保留字当字段名，比如
group、rank、json，没加反引号：`group` - 客户端字符集不一致，比如建表时用 utf8mb4，但连接时用 latin1，某些符号（如 emoji、中文引号）会被截断成非法字符
- 复制粘贴带隐藏控制符，特别是从 Notion、微信、网页复制的 SQL，看似正常，实则含不可见 Unicode 字符，建议在 vim 或 VS Code 里打开「显示不可见字符」开关再检查
- MySQL 版本差异：5.7 支持
CREATE TABLE t AS SELECT ...，但某些旧版不支持子查询中用 LIMIT，报错位置却指向最外层
ERROR 1213 / 1205：死锁不是 bug，是并发设计暴露了逻辑缺陷
Deadlock found when trying to get lock 这类错误容易让人以为是数据库坏了，其实它是 InnoDB 主动“杀掉”了一个事务来保全整体一致性。重点不在“为什么死锁”，而在“为什么这两个事务会按相反顺序争抢资源”。
定位和规避要点：
- 立刻执行
SHOW ENGINE INNODB STATUS\G，看LATEST DETECTED DEADLOCK区域，它会明确告诉你哪两条 SQL、哪个事务 ID、锁住了哪些行 - 典型模式：事务 A 先更新 users 表再更新 orders 表，事务 B 反过来先 orders 再 users —— 必死。解决方案不是加锁粒度，而是统一访问顺序
- 应用层必须做重试：捕获这个错误码（1213），sleep 几百毫秒后重试，最多 2–3 次。别指望数据库自动重试
- 避免长事务：一个事务里做了 SELECT + 大量业务逻辑 + UPDATE，中间任何延迟都会放大死锁概率
真正难处理的从来不是报错本身，而是错误背后那个没被显式建模的并发假设——比如“这条记录没人会同时改”，结果上线后就被打脸。
