根本原因是文件编码未被正确识别，VS Code默认用UTF-8解析实际为GBK/GB2312编码的SQL文件；需先Reopen with Encoding→GBK确认，再Save with Encoding→UTF-8转存。
VS Code 打开 SQL 文件中文显示为问号或方块
根本原因是文件编码未被正确识别，编辑器默认用 utf-8 解析，但实际是 gbk/gb2312 编码保存的 sql 脚本。不是字体问题，也不是系统区域设置导致的表面现象。
实操建议：
- 右下角状态栏点击当前编码（如
UTF-8），选择Reopen with Encoding→GBK；如果恢复正常，说明原始文件确实是 GBK 编码 - 确认后点右下角编码位置，选
Save with Encoding→UTF-8，把文件转存为 UTF-8（推荐后续统一使用） - 若常和 MySQL 客户端（如 Navicat、命令行）协作，注意：MySQL 5.7 默认通信字符集是
latin1，但建表时若没显式指定CHARACTER SET utf8mb4，即使文件是 UTF-8，执行也会乱码——这属于 SQL 运行时乱码，和编辑器无关
执行报错 ERROR 1064 (42000)：SQL 语法错误但提示位置不准
MySQL 的语法纠错机制只检查到「第一个明显不合法的 token」，比如漏了逗号、引号不闭合、关键字拼错，但它不会往前回溯找真正起因，所以报错行数经常偏移。
常见错误现象：
- 报错在第 42 行，但实际是第 15 行少了个
)，导致后续所有括号层级错乱 -
INSERT INTO t1 VALUES ('张三', '2023-01-01', );末尾多了一个逗号，报错却指向;后面的空行 - 用反引号包裹字段名时混用了中文全角符号：
`姓名`正确，‘姓名’（中文单引号）会直接触发 1064
排查优先级建议：
- 从报错行向上查 3～5 行，重点看括号
( )、引号' '和" "、反引号` `是否成对 - 复制整段 SQL 到
mysql -e "source /path/to/file.sql"命令中执行，有时终端比 GUI 工具报错更准 - 避免在 SQL 中写中文注释后紧跟英文分号，例如：
-- 插入用户数据; INSERT INTO ...，部分客户端会把分号误判为语句结束
WHERE 条件里中文字段值比较失败，但无报错
表面执行成功，结果为空，其实是字符集校对规则（collation）不匹配导致隐式转换失效。例如字段定义是 VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，但查询时传入的字符串被当成了 utf8mb4_general_ci 处理，某些生僻字或带变音符号的中文就无法命中。
关键判断方式：
- 执行
SHOW CREATE TABLE table_name;查字段 collation；再执行SELECT @@collation_connection;看当前连接默认校对规则 - 临时强制统一：在 WHERE 中加
COLLATE utf8mb4_unicode_ci，例如WHERE name = '张三' COLLATE utf8mb4_unicode_ci - 长期方案：建表时显式指定
COLLATE utf8mb4_unicode_ci，并确保应用层数据库连接参数包含characterEncoding=utf8mb4&collation=utf8mb4_unicode_ci
Navicat / DBeaver 执行 SQL 报错：Client does not support authentication protocol
这是 MySQL 8.0+ 默认启用 caching_sha2_password 插件，而老版本客户端驱动（尤其是 JDBC 8.0 以下、Navicat 12 及更早）只认 mysql_native_password，连接阶段就断开了，根本到不了 SQL 执行环节。
不要改客户端，改服务端兼容性更稳：
- 登录 MySQL 后执行：
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 立即生效，无需重启 MySQL；但要注意该用户此后将不支持 SHA2 加密握手
- 如果必须用新认证协议，升级 Navicat 至 15+ 或 DBeaver 至 7.0+，并确认 JDBC URL 加了
&allowPublicKeyRetrieval=true&useSSL=false
真正棘手的是：这个错误看起来像连接问题，但用户第一反应总去查 SQL 写法——其实 SQL 根本没发出去。
