根本原因是MySQL服务端、客户端连接、表结构、字段定义四层字符集未全部对齐为utf8mb4，任一层为utf8（utf8mb3）即触发ERROR 1366；须逐层验证：my.cnf中character_set_server= utf8mb4并重启，连接后SHOW VARIABLES确认client/connection/results均为utf8mb4，SHOW CREATE TABLE确保各字段显式声明CHARACTER SET utf8mb4，SQL文件头部加SET NAMES utf8mb4。
为什么加了 utf8mb4 还报 Incorrect string value
根本原因不是“没设 utf8mb4”，而是四层字符集没对齐：MySQL 服务端、客户端连接、表结构、字段定义，任意一层卡在 utf8（即 utf8mb3）就会触发该错误。常见现象是 DBeaver 显示“导入成功”，但 emoji 或生僻中文存成 ??? 或直接报错 ERROR 1366 (HY000)。
必须逐层验证：
-
character_set_server在my.cnf的[mysqld]段设为utf8mb4，且已重启 MySQL 服务（SET GLOBAL不持久） - 连接后立刻执行
SHOW VARIABLES LIKE 'character_set_client';，确认值是utf8mb4，不是utf8 -
SHOW CREATE TABLE your_table;中每个VARCHAR字段都显式带CHARACTER SET utf8mb4，不能只靠CONVERT TO CHARACTER SET—— 它不改已有字段定义 - SQL 文件头部需有
SET NAMES utf8mb4;，否则 DBeaver 即使连上了，解析文件时仍用默认字符集
DBeaver 导入 SQL 时怎么透传 utf8mb4
GUI 工具默认不把字符集参数透传给底层 mysql 客户端，所以“恢复”向导经常失效。最稳的方式是绕过 GUI，调用原生命令。
操作路径：工具 → 执行 → 客户端选 mysql → 参数框里写完整命令：
mysql --default-character-set=utf8mb4 -u root -p your_db <p>注意点：</p>
- 路径用双引号包裹，避免空格或中文路径出错
- 不要用
mysqldump当客户端，它只导出，不执行导入 - 如果目标库不存在，先手动建库：
CREATE DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs; - DBeaver 不会自动帮你加
--default-character-set，不手输就等于没设
连接配置里哪些驱动属性真起作用
DBeaver 的 JDBC 连接参数不是全都能生效，关键就三个，缺一不可：
-
characterEncoding：值必须填utf8mb4（不是UTF-8或utf8） -
useUnicode：必须设为true，否则characterEncoding被忽略 -
serverTimezone：建议同步设为Asia/Shanghai，避免时区转换干扰字符解析
这些都在「编辑连接 → 连接设置 → 驱动属性」里手动添加。别信“自动检测”——DBeaver 启动时读的是系统 locale，Windows 默认是 GBK，跟 MySQL 服务端完全无关。
导入 CSV 或 Excel 时的编码陷阱
这类文件本身带编码，DBeaver 不会自动猜对。即使数据库和连接都设好了 utf8mb4，导入时选错编码照样乱码。
关键动作：
- 导入向导第二步「处理器属性」中，
encoding必须显式选UTF-8（不是“自动”） - 如果源文件是 Windows 记事本保存的，大概率带 BOM，勾选「插入 BOM」能提升兼容性
- 分隔符别用逗号，优先选
\t（Tab），避免中文字段里的顿号、逗号被误切 - 字段类型映射时，确保目标列是
VARCHAR且CHARACTER SET utf8mb4，否则 DBeaver 会静默截断或转义
最易被忽略的是：DBeaver 对 CSV 的编码识别发生在“导入前”，而不是“执行 SQL 前”。一旦选错，数据进库就是错的，回溯成本远高于提前验证文件编码。
