MAX()/MIN()包裹未分组字段不解决语义问题，仅掩盖报错；数据库不校验组内一致性，值有差异时结果不可靠，仅当字段在每组中100%相同时才安全。
直接用 MAX() 或 MIN() 包裹未分组字段，是常见但高风险的“绕过”方式——它不解决语义问题，只掩盖报错。数据库不会校验该字段在组内是否真的一致，一旦值有差异，返回结果就不可靠。
为什么 MAX(name) 看似能用，实际很危险
当你写 SELECT dept, MAX(name), COUNT(*) FROM employees GROUP BY dept，数据库确实不报错，但它返回的 name 是字典序最大（MAX）或最小（MIN）的那个，和业务想表达的“部门负责人姓名”“首条录入姓名”或“最新注册姓名”完全无关。
- 如果一个部门有
name = 'Alice'和'Bob'两行，MAX(name)固定返回'Bob'，但没人能保证这人就是你要的 -
MAX()对日期、数字、字符串行为不统一：对created_at返回最新时间，对id返回最大 ID，对status返回字母最靠后的状态（比如'pending'vs'success'） - MySQL 的
ANY_VALUE()比MAX()更诚实——它不假装有序，但同样不保证业务正确性
什么场景下可以勉强用 MAX/MIN
仅当你能**100% 确认该字段在每个分组内值完全相同**，且这种一致性由业务逻辑或唯一约束保障，而非偶然。
- 关联表带外键 + 唯一约束：比如
orders JOIN customers ON orders.cust_id = customers.id，查MAX(customers.name)是安全的，因为每个cust_id只对应一个name - 字段本身是分组依据的派生值：如
SELECT DATE(created_at), MAX(id), COUNT(*) FROM logs GROUP BY DATE(created_at)，若id是自增主键，则同一天的MAX(id)确实代表最后一条记录（但不如显式用窗口函数可靠） - 字符串字段经过去重清洗：如
name在入库前已通过 ETL 统一为部门标准名称，且有数据质量监控
比 MAX/MIN 更可控的替代方案
真正需要“每组挑一行某字段”，应放弃 GROUP BY 单挑逻辑，改用明确语义的操作。
- 取最新/最早记录：用
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY created_at DESC)+ 外层过滤rn = 1 - 补关联信息：先 GROUP BY 得聚合结果，再
JOIN原表或维度表（注意 ON 条件要精确，避免笛卡尔积） - 字符串拼接：用
STRING_AGG(name, ', ')（PostgreSQL）、GROUP_CONCAT(name)（MySQL）或STRING_AGG(name, ', ') WITHIN GROUP (ORDER BY name)（SQL Server） - NULL 值干扰分组时：别依赖
MAX()躲避，先用COALESCE(name, 'unknown')统一空值再分组
用 MAX() 或 MIN() 显示未分组字段，本质是拿确定性换执行权。它在开发初期可能“跑得通”，但只要数据稍有波动（比如某部门新增一个同名不同人、某条记录 name 字段为空），结果就悄然错位——而这类错误往往上线后才暴露，且难以回溯。
