在SQL中使用聚合函数处理字符串类型数据时，有几个容易忽视的关键点，一旦理解清楚，能帮你避免大量线上Bug。

这就引出了第一个关键判断：MIN()和MAX()对字符串的处理，底层走的是字典序比较，而不是按长度、拼音或笔画来排。它逐字符按ASCII码或当前字符集的排序规则比对，比如'Z'小于'a'，因为大写字母在小写之前——这是很多同学容易踩的坑。举个例子：'apple'和'banana'比较时，先比首字母'a'和'b'，结果立见分晓。但在不同排序规则下结果可能差异很大。

MIN/MAX对字符串是按字典序比较，不是按长度或拼音

当你对字符类型的列使用MIN()或MAX()时，数据库做的是逐字符比较——这个逻辑和中文拼音、笔画、文本长度几乎没有关系。所以处理时要格外小心。

实操上有几点建议：

• 确认你的数据库字符集和排序规则。举个典型例子，MySQL的utf8mb4_unicode_ci和utf8mb4_bin在大小写及重音符号的处理上差异巨大
• 如果到底想按拼音排序来取极值，那不能直接靠MIN()/MAX()搞定。MySQL 8.0+可以用WEIGHT_STRING()配合自定义排序，或者干脆放到应用层处理
• 测试时建议拿带有大小写、数字、符号的样本验证一下。比如SELECT MIN(name) FROM users WHERE name IN ('Alice', 'bob', 'Charlie')，在默认排序规则下通常返回'Alice'

NULL值会被自动忽略，但空字符串不是NULL

再来看一个容易踩坑的细节。MIN()和MAX()默认会跳过NULL值，这和COUNT()的行为不同，但空字符串''是合法的非NULL值，它会参与比较——而且它在字典序中通常排在最前（ASCII码为0）。所以MIN(col)很可能意外返回一个空串，当业务上认为该字段本应有值时，这就会闹乌龙。

常见错误现象包括：

• 查用户表的MIN(nickname)得到''，其实本意是想排除掉空昵称
• 日志表中MAX(status)返回空串，而不是

  'failed'

  或

  'success'

解决办法也很简单：

• 显式过滤：加上WHERE col IS NOT NULL AND col != ''
• 用NULLIF()把空串转成NULL，比如MIN(NULLIF(col, ''))，然后让聚合函数自动跳过
• 注意PostgreSQL中空串和NULL分得很清楚，但某些旧版MySQL配置可能把空串和NULL等价，需要验证

GROUP BY场景下，MIN/MAX字符结果不保证来自同一行

这一点最容易被忽视。当你按部门分组计算MIN(name)和MAX(salary)时，MIN(name)取自张三，MAX(salary)取自李四——它们各自独立计算极值，对应的其他列完全不保证来自同一原始记录。强行拼在一起会严重误导业务逻辑。

使用时的限制条件：

• 如果你只需要纯字符串极值本身，比如“该部门姓名字典序最小者”，那么没问题
• 如果你需要关联极值行的其他字段，比如“姓名最小者的入职日期”，那必须改用窗口函数或子查询
• MySQL 5.7严格模式下，SELECT中混用非GROUP BY列和聚合函数会直接报错；8.0默认开启了ONLY_FULL_GROUP_BY，可以更早暴露问题

替代方案（MySQL 8.0+）示例：

SELECT dept,        FIRST_VALUE(name) OVER (PARTITION BY dept ORDER BY name) AS min_name,       FIRST_VALUE(hire_date) OVER (PARTITION BY dept ORDER BY name) AS min_name_hire_dateFROM employees;

性能影响：索引能否加速MIN/MAX字符查询？

对字符列执行MIN()/MAX()时，如果该列上有有序索引（B-tree），多数引擎（MySQL InnoDB、PostgreSQL、SQL Server）可以直接取索引最左或最右叶子节点，时间复杂度达到O(log n)，完全不需要全表扫描。但这个前提是查询条件不破坏索引的有序性。

关键约束如下：

• 必须是单列索引，或是复合索引的最左前缀列。比如索引(status, name)，对MIN(name)就无法利用，但对MIN(status)可以
• WHERE条件需要匹配索引前缀。举例：索引(region, name)，那么SELECT MIN(name) FROM t WHERE region = 'CN'可以走索引；如果少了

  'region'

  条件，查询就会退化为全索引扫描
• 排序规则需要和索引定义一致，不然也可能无法使用索引。比如建索引时用了utf8mb4_bin，但查询隐式转成utf8mb4_general_ci，性能就大不一样

验证是否走了索引：用EXPLAIN查看type是否为

'index'

'range'