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是开发阶段最烦人的报错之一，但它往往不是语法本身的问题，而是上下文环境导致的。
常见真因：
用了 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，中间任何延迟都会放大死锁概率
真正难处理的从来不是报错本身，而是错误背后那个没被显式建模的并发假设——比如“这条记录没人会同时改”，结果上线后就被打脸。
