Error 2002、1045、1064、1030、1213 分别对应连不上、登不了、查不动、写不进、锁不住五大典型问题，本质是mysql明确提示具体故障环节：socket路径/进程状态、认证与权限配置、sql语法兼容性、磁盘空间与存储引擎、事务设计与死锁。
ERROR 2002、ERROR 1045、ERROR 1064、ERROR 1030、ERROR 1213——这五个错误，覆盖了你日常连不上、登不了、查不动、写不进、锁不住的绝大多数现场。它们不是随机报错，而是 MySQL 在明确告诉你：“这里卡住了，原因很具体”。
连不上 MySQL？先盯死 socket 路径和进程状态
现象：ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'，或者远程连提示 Connection refused。
本质不是“网络不通”，而是 MySQL 根本没在听。
实操建议：
• 用 ps aux | grep mysqld 确认进程是否存在；不存在就 sudo systemctl start mysql；
• 存在但连不上？立刻查 socket 路径：mysql --socket=/tmp/mysql.sock -u root -p（手动指定路径试连）；
• 路径不一致？去 /etc/mysql/my.cnf 或 /etc/my.cnf 检查 socket 配置项是否和 ls -l /var/run/mysqld/ 下真实文件匹配；
• 别忽略权限：如果 socket 文件属主是 mysql:mysql，而你用普通用户连，可能被拒绝——临时可加 sudo，长期应配好用户组或改 mysql 用户启动方式。
登不进账号？别急着重置密码，先分清是认证失败还是权限缺失
现象：ERROR 1045 (28000): access denied for user 'root'@'localhost' (using password: YES)。
这不是“密码错了”就能一语带过的——它可能是：
• 密码本身错误；
• 用户只允许从 'root'@'127.0.0.1' 登录，但你用 localhost（MySQL 会走 socket，视为不同 host）；
• 用户没被授予任何权限，甚至没被创建（select User, Host FROM mysql.user; 看一眼）；
• skip-grant-tables 后忘了删配置重启，导致权限系统未加载。
实操建议：
• 先确认 host 匹配：mysql -h 127.0.0.1 -u root -p 和 mysql -h localhost -u root -p 行为可能完全不同；
• 授权要带 host：GRANT ALL ON *.* TO 'root'@'localhost' IDENTIFIED BY 'xxx'; FLUSH PRIVILEGES;；
• 修改密码别用已弃用的 PASSWORD() 函数（MySQL 8.0+ 不支持），改用 ALTER USER 'root'@'localhost' IDENTIFIED BY 'xxx';。
SQL 一执行就报错？1064 往往不是语法问题，而是版本/引号/保留字陷阱
现象：ERROR 1064 (42000): You have an error in your SQL syntax，但语句在别的环境能跑。
常见真因：
• MySQL 版本差异：比如 JSON_EXTRACT 在 5.7 才正式支持，5.6 里用会直接报 1064；
• 引号混用：字段名用了双引号 "id"（标准 SQL），但 MySQL 默认用反引号 `id`，开启 ANSI 模式才认双引号；
• 用了保留字当列名：比如 order、group、rank，不加反引号必报错；
• 客户端自动补全了 bom 或不可见字符（尤其从 excel 或网页复制 SQL 时）。
实操建议：
• 查版本：SELECT VERSION();；
• 所有标识符统一用 ` 包裹，哪怕看起来没必要；
• 在命令行用 mysql -e "your_sql_here" 直接执行，绕过 GUI 工具的转义干扰；
• 用 EXPLAIN format=TREE（8.0+）或 EXPLAIN 看执行计划前，先确保语句能 parse 通。
查着查着就断连？2013 错误背后是 wait_timeout + 连接池健康检查缺位
现象：pymysql.err.OperationalError: (2013, 'Lost connection to MySQL server during query')，尤其在 flask/django 等框架中高频出现。
这不是网络抖动那么简单——它是连接池把“过期连接”当活连接发给了你。
根本原因：
• MySQL 的 wait_timeout（默认 28800 秒）比应用层连接池的 idle timeout 长，连接在 DB 层已被关，池子还不知道；
• 连接池没开 ping 检查（如 SQLAlchemy 的 pool_pre_ping=True），或没设 pool_recycle 主动轮换；
• 查询本身超时（max_execution_time 触发中断），但错误码仍显示为 2013。
实操建议：
• 永久调参：[mysqld] 下加 wait_timeout = 3600（1小时），避免过长空闲；
• 应用层必须启用健康检查：create_engine(..., pool_pre_ping=True, pool_recycle=3600)；
• 别依赖 set global wait_timeout 临时改——它不作用于已存在的连接，只影响新连接；
• 日志里看到 2013，第一反应不是查网络，而是看 SHOW PROCESSLIST 里有没有大量 Sleep 状态连接堆积。
真正卡住人的，从来不是报什么错，而是错在哪个环节没人盯——比如 ERROR 1030 看似存储引擎故障，结果发现只是磁盘 df -h 剩 200MB；又比如 ERROR 1213 死锁日志里明明写着两行 UPDATE，却没人去看应用代码里事务是否跨了 http 请求边界。错误码是路标，不是终点。