关闭Navicat导出时的“使用十六进制”选项即可解决低版本MySQL报错问题，因其会将BLOB/TEXT等字段转为0x...格式，而MySQL 5.7及更早版本不支持该字面量；关闭后改用标准字符串字面量（如'Hello'、'?'）并自动转义，确保兼容性。
Navicat导出SQL时“使用十六进制”导致低版本MySQL报错
开启「使用十六进制」后，navicat会把blob、text甚至部分varchar字段的值转成0x...格式写入sql文件。mysql 5.7及更早版本对这种写法支持不完整，执行时直接报error 1064 (42000)或unknown character set——不是语法错，是解析器根本认不出这个字面量。
典型现象包括：
- INSERT语句里出现
INSERT INTO t1 VALUES (0x48656C6C6F, 0x776F726C64)，而目标库报“unexpected hexadecimal literal” - 含emoji或中文的字段变成乱码或空值，即使字符集设对了也无效
- 导出的SQL在MySQL 8.0能跑，一到5.7就卡在第一条INSERT
解决方法很简单：导出前关闭该选项。
- 在Navicat「导出向导」中，点「高级」选项卡
- 取消勾选
使用十六进制（位置通常在“BLOB/TEXT导出方式”附近） - 确保
导出数据和导出结构都启用，且字符集显式设为utf8mb4
为什么关掉它就能兼容低版本？
关闭后，Navicat改用标准字符串字面量，比如'Hello'、'?'，并自动加转义。MySQL 5.7完全支持这种写法，只要连接层和表定义的字符集一致，就不会出问题。
但要注意两个隐性依赖：
-
sql_mode不能含STRICT_TRANS_TABLES以外的强约束，否则' '插入到NOT NULL字段可能失败 - 目标库必须已存在，且建库时指定了
DEFAULT CHARSET=utf8mb4，否则CREATE TABLE语句里的CHARSET=utf8mb4可能被忽略
导出后仍报错？优先检查USE语句和库名前缀
Navicat导出的SQL常带USE `db_name`;和全限定表名INSERT INTO `db_name`.`t1`。如果目标库不存在，或当前连接没切换过去，就会触发ERROR 1146 (42S02): Table doesn't exist——这跟十六进制无关，但容易误判。
快速验证和修复：
- 用文本编辑器打开SQL文件，删掉所有以
CREATE DATABASE、DROP DATABASE、USE开头的行（注意USE后面有空格） - 把
INSERT INTO `myapp`.`users`批量替换成INSERT INTO `users` - 手动在Navicat里先执行
USE myapp;，再运行清理后的SQL文件
真正麻烦的从来不是十六进制开关，而是导出脚本里混着跨库操作、权限语句、视图定义这些上下文强依赖项。它们不会报错，但会让单表导入变成一场排查游戏。
