MySQL PAD_CHAR_TO_FULL_LENGTH 查询 CHAR 尾随空格有什么变化

MySQL 的 CHAR 是定长字符串：写入较短值时，存储宽度会用右侧空格补足；但查询返回时，MySQL 默认会去掉这些填充空格。启用 PAD_CHAR_TO_FULL_LENGTH 后，CHAR 返回值会保留到声明长度，CHAR_LENGTH()、HEX() 和拼接出来的边界符都会随之变化。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/sql-mode.html

这个 SQL mode 只改变 CHAR 值“取出来时保不保留右侧填充空格”。它不改变字段的声明长度，也不改变排序规则对尾随空格的比较规则。需要判断展示、导出或应用层字符串长度时，才值得在会话范围内打开它。

先看清 CHAR 的两个阶段

理解这个选项，关键是把“存储”与“返回”分开。假设字段是 CHAR(6)，写入 ab 后，定长字段的内部宽度仍按 6 个字符处理，可以把它理解为 ab____，其中下划线代表空格。默认 SQL mode 查询时，右侧填充空格会在返回阶段被去掉，所以应用拿到的是两个字符；打开 PAD_CHAR_TO_FULL_LENGTH 后，应用拿到的是完整的六个字符。

VARCHAR(6) 不参与这项开关：它保存和返回的是实际字符串，输入里的尾随空格也按可变长度字符串处理。因而，遇到导出文件列宽、旧系统定长协议或应用层长度判断时，应该先确认字段类型，再看当前会话的 SQL mode。

用 CHAR(6) 和 VARCHAR(6) 做最小对照

下面的表只为观察返回值，不依赖特定客户端的可视化效果。把 CHAR 和 VARCHAR 放在同一行，可以看出 SQL mode 只作用于 CHAR 的读取返回。

-- 创建一组只用于观察尾随空格的字段
DROP TEMPORARY TABLE IF EXISTS pad_demo;
CREATE TEMPORARY TABLE pad_demo (
    c CHAR(6),
    v VARCHAR(6)
);

-- 两列都写入同样的可见内容，CHAR 会按定长语义补齐
INSERT INTO pad_demo (c, v) VALUES ('ab', 'ab');

-- 包裹符号、长度和十六进制值一起显示返回结果
SELECT
    CONCAT('[', c, ']') AS char_view,
    CHAR_LENGTH(c) AS char_length,
    HEX(c) AS char_hex,
    CONCAT('[', v, ']') AS varchar_view,
    CHAR_LENGTH(v) AS varchar_length,
    HEX(v) AS varchar_hex
FROM pad_demo;

在默认设置下，char_view 类似 [ab]，char_length 为 2，char_hex 只包含 6162；VARCHAR 一列也返回 [ab] 和长度 2。这里的方括号只是让结果边界可见，避免终端或客户端把空格显示得像没有内容。

在当前会话打开 PAD_CHAR_TO_FULL_LENGTH

SQL mode 可以按会话设置。为了不影响连接池复用的其他逻辑，示例先保存原值，比较完成后恢复。不要直接把全局配置改掉来做一次排查；全局修改会让新连接也继承不同的返回语义。

-- 保存当前连接的 SQL mode，避免覆盖其他会话选项
SET @old_sql_mode = @@SESSION.sql_mode;

-- 只在当前会话启用 CHAR 的完整长度返回
SET SESSION sql_mode = 'PAD_CHAR_TO_FULL_LENGTH';

-- 用同一组观测字段查看开关后的返回结果
SELECT
    CONCAT('[', c, ']') AS char_view,
    CHAR_LENGTH(c) AS char_length,
    HEX(c) AS char_hex,
    CONCAT('[', v, ']') AS varchar_view,
    CHAR_LENGTH(v) AS varchar_length,
    HEX(v) AS varchar_hex
FROM pad_demo;

-- 完成对照后恢复进入本段之前的会话配置
SET SESSION sql_mode = @old_sql_mode;

启用后，char_view 会显示为带有四个右侧空格的 [ab    ]，char_length 变成 6，char_hex 末尾会出现四组空格对应的十六进制字节（单字节字符集下通常是 20）。VARCHAR 列仍保持长度 2，因为这个 SQL mode 不负责给可变长度列补齐。

如果当前连接原本还有 STRICT_TRANS_TABLES、ONLY_FULL_GROUP_BY 等模式，上面的保存与恢复写法可以避免示例结束后把它们永久丢掉。生产代码中也应明确把这个设置绑定在需要完整定长返回的连接或会话上。

为什么要同时看 CHAR_LENGTH 和 HEX

只看客户端表格容易误判：有些客户端会裁掉末尾空格，有些日志格式会把连续空白压缩，肉眼很难判断返回的是 ab 还是 ab 加四个空格。把值包在方括号里，再观察长度和十六进制值，结论会稳定很多。

十六进制结果与字符集有关，所以表中的 20 只适合作为单字节字符集下的直观示意。真正排查时，以同一连接实际返回的 CHAR_LENGTH 和 HEX 为准，不要把字节数和字符数混为一谈。

不要把返回值变化误认为比较规则变化

PAD_CHAR_TO_FULL_LENGTH 影响的是 CHAR 取值返回时是否保留填充空格。字符串比较和排序仍由列使用的字符集排序规则及其 pad 属性决定；SQL mode 本身不会让所有比较突然变成“空格敏感”。

因此，下面两个问题要分开处理：

• 应用读取后需要固定宽度、导出定长文件或复现旧客户端行为：检查会话是否启用了 PAD_CHAR_TO_FULL_LENGTH。
• 应用比较 'ab' 与 'ab ' 的结果不符合预期：检查列的字符集、排序规则 pad 属性以及是否使用了二进制比较，不要只切换 SQL mode。

如果只是希望查询结果去掉空白，默认行为通常已经足够；如果确实需要完整值，优先使用会话级设置，并在连接池初始化和归还连接时保持配置一致。

常见问题

PAD_CHAR_TO_FULL_LENGTH 会改变 CHAR 的存储长度吗？

不会。它改变的是查询返回阶段的表现，CHAR(6) 仍然是声明为 6 个字符的定长列。

这个 SQL mode 会作用于 VARCHAR 吗？

不会。VARCHAR 的返回长度由实际保存的字符串决定，示例中的 VARCHAR(6) 仍返回长度 2。

为什么客户端里看不到右侧空格？

表格组件、日志格式或复制操作可能隐藏连续空白。使用方括号、CHAR_LENGTH() 和 HEX() 同时确认。

只打开这个模式能修复字符串比较问题吗？

不能。比较结果应回到列排序规则的 pad 属性和比较表达式本身判断；该模式只负责 CHAR 返回值是否保留填充空格。

小结

默认情况下，MySQL 查询 CHAR 会去掉右侧填充空格；启用 PAD_CHAR_TO_FULL_LENGTH 后，返回值保留到字段声明长度。用 CONCAT、CHAR_LENGTH 和 HEX 观测，就能把客户端显示差异变成明确的字段事实。生产环境先决定应用真正需要的是“干净字符串”还是“完整定长值”，再把开关限制在明确的会话边界内。