CONVERT函数仅用于数据类型转换，不能解决字符集转换问题；它不改变底层字节解释逻辑，也无法纠正因存储编码与声明编码不一致导致的乱码。
SQL 的 CONVERT 函数不能解决字符集转换问题，它只做数据类型转换，不是字符编码转换工具。 想靠 CONVERT 把 latin1 字段里的中文“救”出来，或者把乱码字段“转正”，基本会失败。
CONVERT 函数的真实作用：类型转换，不是编码转换
CONVERT 在 SQL Server 和 MySQL（兼容模式）中用于显式转换数据类型，比如 INT 转 VARCHAR、DATETIME 转 CHAR。它不触碰底层字节序列的解释逻辑，也不改变字段的列级字符集定义。
常见误用场景：
- 把一个实际存的是
utf8mb4字节但被错误声明为latin1的字段，用CONVERT(VARCHAR, col)试图“修复”——结果仍是乱码 - 在 MySQL 中对
BLOB字段用CONVERT(col USING utf8mb4)——这其实是 MySQL 特有的语法变体，本质是CAST(... AS ...)的别名，且仅在特定上下文中生效，不是通用解法
真正需要字符集转换时该怎么做
字符集问题本质是“存储编码”和“声明编码”不一致，或客户端/连接层编码错配。解决路径与 CONVERT 无关，而取决于具体环节：
- 建表时明确指定字符集：
CREATE TABLE t (c VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci) - 连接初始化时设置编码：
SET NAMES utf8mb4（MySQL），或在连接字符串中加;charset=utf8mb4 - 导入数据前确认源文件编码，并用对应参数加载（如
LOAD DATA INFILE ... CHARACTER SET utf8mb4） - 若已有乱码数据且确定原始字节未损坏，可尝试用双重转换“绕过”声明（仅限 MySQL）：
SELECT CONVERT(CAST(CONVERT(col USING latin1) AS BINARY) USING utf8mb4)—— 这本质是欺骗 MySQL 重新解释字节，风险高，需严格验证结果
SQL Server 中的特殊情况：没有 “USING” 语法，更不能换编码
SQL Server 的 CONVERT 完全不支持类似 MySQL 的 CONVERT(... USING ...) 形式。它的 CONVERT 只接受目标类型和表达式，例如 CONVERT(NVARCHAR(50), col)。即使源列是 VARCHAR（对应单字节编码），转成 NVARCHAR 也只是按当前代码页解释后转为 Unicode，**不会纠正错误的原始解码**。
典型陷阱：
- 源列用
VARCHAR存了本该是 UTF-8 编码的字节（SQL Server 不原生支持 UTF-8 列，除非 2019+ 且显式声明UTF8排序规则） - 执行
CONVERT(NVARCHAR, col)后仍显示问号或方块——因为 SQL Server 用 Windows-1252 或其他默认代码页去读那些 UTF-8 字节，早已失真
字符集问题从来不是单靠一个函数能翻盘的。最常被忽略的是：乱码一旦写入，且原始编码信息丢失，就不可逆。所有“转换”操作都建立在字节未损坏、原始编码可推断的前提下。动手前先用 HEX()（MySQL）或 CONVERT(VARBINARY, col)（SQL Server）看真实字节，比盲目套 CONVERT 有用得多。
