mysql中字符串的max()/min()按字典序逐字符比较unicode码点，首字符不同时直接决定结果；存数字字符串时需显式转换（如cast或乘1）或重构字段结构，不可依赖默认排序规则。
字符串比较按字典序逐字符进行，不是看长度或语义
MAX() 和 MIN() 对 CHAR、VARCHAR 类型字段求极值时，底层是逐字符比对 Unicode（或 ASCII）码点，首字符不同时直接决定结果；首字符相同时才比第二位，依此类推。比如 MIN('v1.2', 'v1.10', 'v2.1') 返回 'v1.10'，因为 '1' 的 ASCII 码（49）小于 '2'（50），所以 'v1.10' 'v1.2' —— 这不是 bug，是字符串比较的必然行为。
常见误判场景包括：
- 把版本号、IP 地址、编号类字符串直接丢给
MAX()，结果不符合业务预期 - 以为中文会按笔画/部首/常用度排序，实际走拼音首字母（如
'李四''张三'，因'李'的 Unicode 码点 U+674E 小于'张'的 U+5F20） - 忽略 collation 设置：MySQL 中
utf8mb4_0900_as_cs区分大小写且按码点比，utf8mb4_general_ci则忽略大小写并做宽松匹配
GROUP BY 分组统计字符串范围时，NULL 和全 NULL 要分开判断
执行类似 SELECT category, MIN(name), MAX(name) FROM products GROUP BY category 时，MIN() 和 MAX() 会跳过每组内的 NULL 值，但若某组所有 name 都是 NULL，结果就是两个 NULL，而不是报错或留空。
这容易掩盖数据质量问题。比如“图书”分类下本该有书名，却全为 NULL，报表里只显示空白，你可能误以为没数据，其实是录入缺失。
补救方法是加 COUNT(name) 辅助识别：
-
COUNT(name) = 0→ 该组无有效字符串值 -
COUNT(name) > 0但MIN(name)仍为NULL→ 不会发生，因为COUNT()已过滤掉NULL - 真要补默认值，可用
COALESCE(name, '[unknown]')，但注意这会污染真实范围（'[unknown]'可能比所有合法值都小）
想按数值逻辑比较字符串？必须显式转换或重构存储结构
当字段存的是数字字符串（如 '123'、'45'）或带前缀的编号（如 'ID001'、'ID100'），直接 MAX() 会按字典序返回错误结果。这时候不能靠改 collation 解决，得动手处理。
可行路径有三条：
- 运行时转换：MySQL 用
MAX(score * 1)或MAX(CAST(score AS SIGNED))；PostgreSQL 用MAX(score::integer) - 标准化前缀：提取纯数字部分再转，例如
MAX(CAST(SUBSTRING(code, 3) AS UNSIGNED))处理'ID001' - 根本性修复：把版本号拆成
major、minor、patch三列存整数，或把 IP 地址转为INET_ATON()存 unsigned int
别指望数据库自动“理解”你的业务意图——它只认字节和 collation。
不同数据库对中文排序的实际表现差异很大
MySQL 默认按 collation 决定中文比较方式：utf8mb4_unicode_ci 走 Unicode 码点（即拼音序），utf8mb4_zh_0900_as_cs（MySQL 8.0+）才支持真正按汉字字典序；SQL Server 若用 Chinese_PRC_CI_AS 才按《GB2312》字典序，否则仍走拼音；PostgreSQL 完全依赖系统 LC_COLLATE，运行时无法切换，建库就得定死。
这意味着跨库迁移或联合查询时，同一串 SQL 在不同环境可能返回不同 MIN() 结果。最稳妥的做法是：只要涉及中文排序逻辑，就不要依赖默认行为，而是在应用层标准化（如预存拼音字段 name_pinyin），或在 SQL 层显式调用转换函数（如 MySQL 的 CONVERT(name USING gbk) + 指定 collation）。
真正麻烦的不是语法怎么写，而是你得清楚当前数据库到底用什么规则在比——查 SHOW CREATE TABLE 和 SELECT COLLATION(column_name) 是第一步，不是可选项。
