本文揭示了在 mysql 中对字符串类型字段误用 max()/min() 导致逻辑错误的根本原因：当温度等数值以 varchar 存储时，比较基于字典序而非数值大小，从而返回错误的“最大值”或“最小值”。
在实际开发中，许多开发者会直接使用 MAX() 和 MIN() 聚合函数来快速获取某段时间内的最高/最低温度（如 t1, t2 等字段），但若底层数据类型设计不当，结果将严重失真——正如问题中所示：MIN(t1) 返回 10.00、MAX(t1) 返回 9.63，这显然违背数值逻辑。
根本原因在于数据类型错误：
如果 t1, t2 等字段被定义为 VARCHAR 或 TEXT 类型（例如 '9.63', '10.00'），MySQL 在执行 MIN()/MAX() 时会按字符串字典序比较，而非数值大小。其规则是逐字符比对 ASCII 值：
'10.00' → 首字符 '1' (ASCII 49) '9.63' → 首字符 '9' (ASCII 57) → 因此 '9.63' > '10.00' 字符串意义上成立！
这就是为何 MAX(t1) 返回 '9.63'（字典序最大），而 MIN(t1) 可能返回 '10.00'（若表中还有 '100.5' 等值，则 '10.00' 反而可能不是最小）。
✅ 正确解决方案：修改字段类型为数值型
推荐使用以下两种类型之一（根据精度需求选择）：
| 类型 | 适用场景 | 示例定义 |
|---|---|---|
| DECIMAL(5,2) | 需精确表示（如温度、金额），避免浮点误差 | ALTER TABLE Buapas MODIFY t1 DECIMAL(5,2); |
| FLOAT / DOUBLE | 允许微小舍入误差，支持更大范围和小数位 | MODIFY t1 FLOAT; |
执行变更后，原 SQL 即可正常工作：
SELECT MIN(t1) AS t1min, MAX(t1) AS t1max, MIN(t2) AS t2min, MAX(t2) AS t2max, -- ...其余字段 FROM Buapas WHERE logdate >= NOW() - INTERVAL 1 DAY;
⚠️ 额外注意事项：
- ✅ 务必同时检查 logdate 字段是否为 DATETIME 或 TIMESTAMP 类型，否则 WHERE logdate >= NOW() - INTERVAL 1 DAY 可能失效；
- ❌ 避免在 WHERE 条件中对字段使用函数（如 DATE(logdate)），以免索引失效；建议为 logdate 建立 B-tree 索引；
- ? 若无法立即修改表结构，临时补救方案是强制类型转换（不推荐长期使用）：
SELECT MIN(CAST(t1 AS DECIMAL(5,2))) AS t1min, MAX(CAST(t1 AS DECIMAL(5,2))) AS t1max ...
总结：MAX() 和 MIN() 完全支持多字段并行聚合，语法无误；问题本质是数据建模缺陷。将数值型业务字段（温度、湿度、电压等）始终定义为 DECIMAL 或 FLOAT，是从根源上杜绝此类陷阱的关键实践。
