MAX()和MIN()对字符串按字典序逐字符比较，依据collation规则而非数值或语义；如'Zebra'>'apple'，'v1.10'<'v1.2'，空字符串参与比较而NULL被忽略。
因为MAX()对字符串、日期字符串等非数值类型字段，不做隐式类型转换，而是严格按底层排序规则（collation）或字典序逐字符比较——它不是在“找最大时间”或“最大数字”，而是在“找字典里最靠后的字符串”。
字符串字段的MAX()返回'Zebra'而不是'apple'？查校对规则
MySQL、PostgreSQL等引擎对VARCHAR字段执行MAX()时，实际调用的是该列定义的COLLATE规则。比如：
-
utf8mb4_bin：逐字节比，'Z'（ASCII 90）'a'（ASCII 97），所以MAX(name)可能返回'apple' -
utf8mb4_0900_as_cs：区分大小写但按Unicode规范排，'Z'仍小于'a'，结果同上 -
utf8mb4_0900_as_cs下'张'和'李'按拼音排序，但MAX()取的是拼音字典序最大者，未必是业务意义上的“最新姓名”
验证方法：SHOW CREATE TABLE your_table;看字段的COLLATE；临时测试：SELECT MAX(name COLLATE utf8mb4_0900_as_cs) FROM t;
日期存成VARCHAR，MAX()返回'2023-13-01'？必须先转类型
如果字段类型是VARCHAR，哪怕所有值都长这样：'2023-01-01'、'2023-12-31'，MAX(date_str)仍是字符串比较：
-
'2023-13-01'>'2023-12-31'（因为'1'>'0'在第8位） - 非法日期如
'9999-01-01'或'zzzz-xx-xx'只要字典序靠后，就会被当作“最大”
正确做法不是修排序规则，而是归一化类型：SELECT MAX(STR_TO_DATE(date_str, '%Y-%m-%d')) FROM t;（MySQL）或SELECT MAX(date_str::DATE)（PostgreSQL）。注意：STR_TO_DATE()对非法格式返回NULL，会被MAX()跳过——所以先清理脏数据比硬扛更重要。
GROUP BY中同时取MIN(name)和MAX(salary)，结果不来自同一行
这是最容易被忽略的语义陷阱：MIN()和MAX()各自独立扫描全组，不保证它们对应的其他字段（如id、created_at）属于同一条原始记录。
- 例如部门分组中，
MIN(name)来自员工A，MAX(salary)来自员工B，拼在一起会误导业务 - 若需“工资最高者的姓名”，不能写
SELECT MIN(name), MAX(salary) FROM t GROUP BY dept，得用窗口函数：ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)，再过滤rn = 1 - MySQL 5.7+开启
ONLY_FULL_GROUP_BY后，这种混用非聚合字段的写法会直接报错，反而是好事
空字符串''和NULL都存在时，MIN()可能意外返回''
MAX()和MIN()默认忽略NULL，但''（空字符串）是合法非NULL值，在字典序中通常排最前（ASCII 0），所以MIN(col)可能返回空串而非业务上有效的最小值。
- 常见于昵称、备注等允许为空的字段
- 修复方式：显式过滤
WHERE col IS NOT NULL AND col != ''，或用MIN(NULLIF(col, ''))把空串转为NULL再让聚合跳过 - 注意PostgreSQL对
''和NULL区分严格；某些旧版MySQL配置可能把空串等价于NULL，需实测验证
真正关键的是：校对规则不是“排序开关”，而是整个比较逻辑的底层契约；改COLLATE可能影响索引有效性、JOIN条件匹配，甚至已有应用的大小写敏感逻辑——动之前先评估副作用。
