YashanDB 知识库|MySQL 迁移后 CHAR 字段多出空格? 问题可能出在这里

【问题描述】

某业务场景中，用户将一张表从 MySQL 迁移至 YashanDB，源端字段定义为：

char(2)

实际业务中，写入的数据只有 '0'、'1' 两种值。迁移后，在 YashanDB 中查询该字段时，发现返回值变成 '0 '、'1 '，也就是自动补足了空格。

这导致业务侧字符串比较出现异常，影响功能正常使用。

【问题分析】

这属于 CHAR 类型在不同数据库中处理方式差异导致的表现：

在 MySQL 中：

默认未开启 PAD_CHAR_TO_FULL_LENGTH 模式;

CHAR(n) 实际存储 '0' 时不补空格，查询结果也直接返回 '0';

仅在显式开启该模式后才会补空格。

可通过以下命令确认：

SHOW VARIABLES LIKE 'sql_mode';

如无该项，说明空格不会自动填充。

在 YashanDB 中：

遵循 SQL 标准：CHAR(n) 类型固定长度，若存入字符不足，系统会自动补足尾部空格;

因此，'0' → '0 '(两字符)，这是标准行为，并非异常。

【解决方案】

方法一：字段类型从 CHAR 改为 VARCHAR

最直接有效的方式是调整字段定义：

-- 原定义(容易补空格)CREATE TABLE t_demo (status CHAR(2));

-- 建议改为

CREATE TABLE t_demo (status VARCHAR(2));

VARCHAR 类型只按实际字符存储，不会补尾部空格，可完全兼容业务侧比较逻辑。

【规避建议】

在字段迁移时，避免盲目将 MySQL 中的 CHAR 保留原样;

若字段仅用于存储 'Y'/'N'、'0'/'1' 等标志位，建议统一使用 VARCHAR(1);

如确需保持 CHAR 类型，业务代码中需使用 TRIM() 去除空格，或转为基于 LIKE 的模糊匹配。

【影响范围】

所有版本的 YashanDB;

主要在从 MySQL 平滑迁移后未调整字段类型的场景中出现。

【总结建议】