MySQL的MIN()/MAX()对字符串按校对规则比较而非数值大小，如'10'<'2'因字典序；COLLATE决定大小写、重音、汉字排序等行为，错误规则会导致结果异常；修复需验证当前校对规则，临时用COLLATE指定或永久修改字段，数字字符串应转数值处理。
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 查询逻辑。动之前务必在测试环境跑全量排序+聚合验证。
