SELECT MIN() 返回 NULL 而不是最小值？检查 WHERE 条件和空值
当
SELECT MIN(column)返回
NULL，常见原因不是数据不存在，而是筛选条件没命中任何行，或目标列全为
NULL。MySQL 的聚合函数在无匹配行时一律返回
NULL，不报错也不提示。 先用
SELECT COUNT(*) FROM table WHERE ...确认 WHERE 是否真有数据
MIN()会自动跳过
NULL值，但如果整列（或 WHERE 后的子集）全是
NULL，结果仍是
NULL若需把空结果转为默认值，用
COALESCE(MIN(column), 0)或
IFNULL(MIN(column), -1)
对日期字段用 MIN() 却得到错误格式？确认字段类型和时区
对
DATETIME或
TIMESTAMP字段执行
MIN(created_at)，结果看起来像字符串（如
'2023-05-12 08:30:45'），这不是问题——这是 MySQL 的标准显示格式。但若实际拿到的是
0000-00-00 00:00:00或乱码，大概率是字段含非法日期值或时区配置不一致。 检查字段是否定义为
DATE/
DATETIME，而非
VARCHAR；字符串存储日期会导致
MIN()按字典序比较，结果不可信 运行
SELECT @@time_zone, @@session.time_zone，确保连接时区与写入时区一致 验证数据质量：
SELECT created_at FROM logs WHERE created_at
GROUP BY 配合 MIN() 出现“only_full_group_by”错误？严格模式下必须显式处理非分组列
在启用
ONLY_FULL_GROUP_BY（MySQL 5.7+ 默认开启）时，
SELECT user_id, MIN(score), name FROM scores GROUP BY user_id会报错，因为
name不在
GROUP BY中，也不在聚合函数里。 正确做法是：只选确定属于该组的字段，例如
MIN()对应的完整记录需用子查询或窗口函数获取 若要查每个用户的最低分及对应那条记录的
name，不能直接
MIN(name)（那是字典最小名，不是同一条记录的名） 推荐解法：
SELECT s1.* FROM scores s1 WHERE score = (SELECT MIN(score) FROM scores s2 WHERE s2.user_id = s1.user_id)
用 MIN() 统计指标变慢？注意索引覆盖和大表扫描
SELECT MIN(price) FROM products在千万级表上执行缓慢，通常是因为缺少索引，或引擎被迫全表扫描。
MIN()和
MAX()可利用 B+ 树索引最左端快速定位，前提是字段上有单列索引或复合索引的最左前缀 执行
EXPLAIN SELECT MIN(price) FROM products，看
type是否为
index或
range；若为
ALL，说明没走索引 避免在表达式上用 MIN：
MIN(price * 1.1)无法使用索引，应先算好再查，或加生成列+索引
没有索引支撑的
MIN()在大数据量下可能比想象中更慢，而且容易被误认为“只是取个值而已”，实际它仍需触达索引树的最底层节点。
