mysql的min()/max()对字符串按校对规则比较而非数值大小，如'10'

MySQL 的 MIN() 和 MAX() 对字符串返回“错”的最大值？

不是函数错了，是它真正在比 ASCII 或 Unicode 码点 —— 比如 '10' 会排在 '2' 前面，因为 '1' 的 ASCII 是 49，'2' 是 50，首字符就决定了大小。这种“字典序”行为在 MIN()/MAX() 里完全一致，但常被误认为“数值逻辑”。

为什么 COLLATE 校对规则直接影响 MIN/MAX 结果

MIN() 和 MAX() 在字符串列上执行时，底层依赖当前列的 COLLATION（校对规则）做比较。不同校对规则对大小写、重音、汉字拼音甚至空格的处理完全不同：

• utf8mb4_general_ci：不区分大小写，但排序不稳定（已弃用）
• utf8mb4_0900_as_cs：区分大小写 + 区分重音 + Unicode 9.0 排序规则，汉字按拼音、英文按字典序
• utf8mb4_bin：逐字节比较，'A' 和 'a' 被视为不同且严格按 ASCII 排

执行 SHOW CREATE TABLE your_table; 查看字段实际 COLLATE；若未显式指定，由表或数据库默认值继承。错误的校对规则会导致 MAX(name) 返回 '张三' 而不是 '李四'（因拼音排序异常）。

如何验证并修复字符串字段的 MIN/MAX 行为

先确认问题是否来自校对规则本身，而不是数据或类型：

• 用 SELECT name, HEX(name) FROM t_book ORDER BY name LIMIT 5; 看原始字节和排序顺序是否符合预期
• 临时强制指定校对： SELECT MAX(name COLLATE utf8mb4_0900_as_cs) FROM t_book;
• 永久修正： ALTER TABLE t_book MODIFY name VARCHAR(50) COLLATE utf8mb4_0900_as_cs;
• 若字段本意是存数字字符串（如 '1', '10', '2'），别依赖 COLLATE 修——直接转数值：MAX(CAST(name AS UNSIGNED)) 或 MAX(name + 0)（注意 NULL 会变 0）

NULL 值和隐式类型转换带来的干扰

MIN()/MAX() 默认忽略 NULL，这点没问题；但一旦你加了隐式转换（比如 name + 0），NULL 就变成 0，而非法字符串（如 'abc'）也转成 0，结果就失真了。

• 检查是否有非数字内容：SELECT name FROM t_book WHERE name REGEXP '^[^0-9]';
• 安全转换推荐：MAX(CAST(NULLIF(TRIM(name), '') AS UNSIGNED))，先去空再判空
• 避免 name + 0 在含中文/符号字段上使用——它只会截断到第一个非数字字符，'2024年' → 2024，但 '年2024' → 0

真正容易被忽略的是：校对规则不是“排序开关”，而是整个比较逻辑的底层契约；改了 COLLATE 可能影响索引有效性、JOIN 条件匹配，甚至已有应用的 case-insensitive 查询逻辑。动之前务必在测试环境跑全量排序+聚合验证。