MySQL中CHAR类型读取时自动忽略尾部空格是其固有语义，源于SQL标准对定长字符串的PAD SPACE校对规则；该行为发生在查询层而非存储层，SELECT、WHERE比较及函数（如LENGTH）均隐式去空格，不可关闭且与sql_mode、字符集无关。
CHAR读取时自动去除尾部空格是MySQL的默认行为
不是“截断”，而是“检索时隐式去空格”——CHAR字段在被SELECT、WHERE比较或参与函数计算（如LENGTH()、CONCAT()）时，MySQL会自动去掉尾部空格。这不是存储阶段的操作，而是查询层的语义处理。
根本原因是MySQL对CHAR类型的语义定义：它代表“定长字符串”，而SQL标准要求这类类型在比较和显示时忽略尾随空格，以保持逻辑一致性（比如'abc'和'abc '应视为等价值）。
-
CHAR(10)存'a'，实际磁盘存的是'a '（9个空格），但SELECT c FROM t返回的永远是'a' -
SELECT LENGTH(c)返回1，不是10；SELECT CONCAT("'", c, "'")结果是'a'，不是'a ' - 该行为不可关闭，与
sql_mode、字符集、校对规则均无关，是CHAR类型固有语义
VARCHAR不会自动去空格，但等值比较仍忽略尾部空格
VARCHAR在存储和读取时都保留原始尾部空格，SELECT出来就是你插入的样子，LENGTH()也如实返回。但注意：一旦进入=比较，它和CHAR一样，受PAD SPACE校对规则影响，尾部空格仍被忽略。
- 插入
VARCHAR(10)值'x '（含1空格），SELECT v, LENGTH(v)返回'x '和2 - 但
WHERE v = 'x'仍能命中该行，因为=比较走的是校对逻辑，不是字节逐一对比 - 想精确匹配尾部空格，必须用
v LIKE 'x '或v = BINARY 'x '（注意BINARY要写在右边）
为什么BINARY能绕过空格忽略？
BINARY不是函数，是类型转换运算符，它把右侧字符串强制转为二进制字符串（BLOB语义），此时比较退化为字节级逐位对比，完全跳过字符集和校对规则。
-
name = BINARY 'lingyejun '只匹配真正以空格结尾的记录，不匹配'lingyejun' - 关键点：
BINARY必须放在=右侧，否则无法利用索引（如BINARY name = 'xxx'会导致全表扫描） - 若字段本身是
utf8mb4_bin或utf8mb4_0900_as_cs这类NO PAD校对，=本身就不忽略空格，但这类校对需显式指定，且不兼容老业务
实际开发中最容易踩的坑
空格问题往往在“看似正常”的地方突然爆发：前端传'admin '，后端没trim()，查数据库时却命中了'admin'用户，导致权限错乱或数据覆盖。
- 不要依赖
CHAR来“自动清理空格”，它只在读取时生效，INSERT/UPDATE仍按原样存（只是CHAR会补足空格） -
VARCHAR字段如果业务上需要区分空格（如密码盐、token、命令参数），务必在应用层trim()后再入库，并在查询时用LIKE或BINARY - 建表时若字段长度固定且允许空格语义模糊（如国家代码
CHAR(2)），用CHAR没问题；但凡涉及用户输入、日志、配置项，优先选VARCHAR并自行控制空格
最麻烦的其实是混合场景：一个VARCHAR字段，既要用=做快速索引查询，又要偶尔精确匹配空格——这时只能拆成两个字段，或加生成列索引，没有银弹。
