SQL 语法解析阶段就可能报错
MySQL 在收到客户端发来的 SQL 后，第一件事是做词法和语法分析。只要语句不符合 MySQL 的语法规则，就会在这一阶段直接报错，不进入后续流程。
常见现象包括：
ERROR 1064 (42000)，提示
You have an error in your SQL syntax。比如漏写引号、关键字拼错（
SELEC而非
SELECT）、括号不匹配、用中文标点等。 检查错误信息里的行号和位置（如
near '...' at line 1），重点看那附近 用
mysql --verbose或客户端的「显示完整错误」功能，避免截断提示 对动态拼接的 SQL（如 Python 的
f-string或 PHP 的
mysqli_real_escape_string），先
print()/
echo出原始 SQL 再贴到命令行验证
权限校验阶段失败会触发 ERROR 1142
语法没问题，但用户没有对应表/库的操作权限时，MySQL 会在权限检查阶段拒绝执行，返回类似
ERROR 1142 (42000): INSERT command denied to user的错误。
这类错误常出现在应用部署后首次写入、或切换数据库用户之后。
用当前用户登录 MySQL，执行SHOW GRANTS;确认是否包含目标操作权限（如
INSERT,
UPDATE,
EXECUTE） 注意权限作用域：是
@'localhost'还是
@'%'？是否对具体库（
mydb.*）或表（
mydb.mytable）授权？ 权限变更后需执行
FLUSH PRIVILEGES;（仅当用
INSERT INTO mysql.user等直接改系统表时才需要；用
GRANT语句通常自动生效）
表结构不匹配导致运行时报错
语句合法、权限也够，但执行时发现字段不存在、类型不兼容、主键冲突等，属于「语义检查」或「执行期校验」阶段出错，典型错误码有
ERROR 1054 (42S22)（Unknown column）、
ERROR 1364 (HY000)（Field doesn't have a default value）、
ERROR 1062 (23000)（Duplicate entry）。
这类问题往往在数据内容变化后才暴露，比如新增 NOT NULL 字段却没设默认值，或应用升级后写了旧版不存在的字段。
用DESCRIBE table_name;或
SHOW CREATE TABLE table_name\G对照 SQL 中涉及的字段名、类型、约束 插入/更新前加
SELECT验证字段是否存在、是否可为空、是否有唯一索引限制 对批量操作，开启事务 +
SELECT ... FOR UPDATE可提前暴露锁冲突类问题
执行计划异常引发超时或资源耗尽
SQL 能跑通、没报错，但响应极慢、连接被 kill、或触发
ERROR 2013 (HY000): Lost connection to MySQL server during query，大概率是优化器选了低效执行路径，比如全表扫描、临时表过大、磁盘排序等。
这类“不报错但不可用”的情况最难定位，需结合
EXPLAIN和慢日志。 对慢 SQL 执行
EXPLAIN FORMAT=TRADITIONAL，重点关注
type（是否为
ALL）、
key（是否用了索引）、
rows（预估扫描行数）、
Extra（是否出现
Using filesort或
Using temporary） 确认
slow_query_log = ON，并设置合理阈值（如
long_query_time = 1），定期查
mysqld_slow.log避免在 WHERE 条件中对字段用函数（如
WHERE DATE(create_time) = '2024-01-01'），会导致索引失效
EXPLAIN SELECT * FROM orders WHERE status = 'paid' AND create_time > '2024-01-01';
实际排查时，别只盯着错误码数字——
ERROR 1062看似是主键冲突，但可能是业务逻辑重复提交；
ERROR 2006表示连接断开，根源可能是网络抖动、wait_timeout 设置过短、或查询真的卡死了。最有效的办法，是把错误信息、完整 SQL、表结构、MySQL 版本、执行上下文（如是否在事务中）一起看。
