窗口函数配合MAX()和MIN()可高效实现Min-Max标准化，避免子查询导致的多次全表扫描、WHERE不一致、多列分组归一化困难等问题，且天然保留行结构；关键写法为SELECT ..., (col - MIN(col) OVER()) / NULLIF(MAX(col) OVER() - MIN(col) OVER(), 0) FROM tbl。
窗口函数配合 MAX() 和 MIN() 是做列内标准化（如 Min-Max 归一化）最直接、最高效的方式，无需子查询或自连接，且能保留原始行结构。
为什么不能直接用子查询做 Min-Max 标准化
有人尝试先用子查询算出整列极值，再 JOIN 回原表做除法：SELECT price, (price - (SELECT MIN(price) FROM products)) / ((SELECT MAX(price) FROM products) - (SELECT MIN(price) FROM products)) AS norm_price FROM products。这看似可行，但问题明显：
- 三次全表扫描 ——
MIN()、MAX()各扫一次，主表再扫一次，I/O 开销翻倍 - 若表有 WHERE 条件（如
WHERE category = 'Electronics'），子查询却没同步过滤，结果错得离谱 - 无法在同一个查询中同时对多列做不同范围的归一化（比如 price 按全局归一，quantity 按 category 分组归一）
用 MAX() OVER() 和 MIN() OVER() 一步到位
窗口函数天然支持“不压缩行数 + 全局/分组极值广播”，正好匹配标准化需求。关键写法是：
SELECT id, price, (price - MIN(price) OVER()) / NULLIF(MAX(price) OVER() - MIN(price) OVER(), 0) AS price_norm FROM products;
说明与要点：
-
OVER()不带参数 = 整个结果集为一个窗口，MIN(price) OVER()就是全局最小值，自动广播到每一行 -
NULLIF(..., 0)必须加 —— 否则当所有price值相等时，分母为 0，触发 division by zero 错误 - 若需按分组归一化（如每类商品独立缩放到 [0,1]），把
OVER()改成OVER(PARTITION BY category) - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持，但旧版 MySQL（5.7 及之前）完全不支持，别硬套
处理 NULL 和边界值的陷阱
MIN() 和 MAX() 窗口函数仍遵循聚合函数规则：自动跳过 NULL。但这在标准化中容易埋雷：
- 如果某行
price是NULL，归一化结果仍是NULL—— 这没问题，但你要确认业务是否允许缺失值参与计算 - 更危险的是：若整列
price全为NULL，MIN() OVER()和MAX() OVER()都返回NULL，导致分子分母全NULL，整个表达式结果为NULL，而非报错；你可能误以为计算成功，实际没数据 - 想强制补默认值？可用
COALESCE(MIN(price) OVER(), 0)，但注意：补 0 会扭曲真实范围，仅适用于明确知道缺失即为零的场景（如库存字段）
性能与索引的实际影响
窗口版 Min-Max 标准化在有索引时并不自动提速 —— 因为 OVER() 默认要看到全部行，优化器通常走全表扫描。但有两个例外可提速：
- 如果加了
WHERE过滤（如WHERE status = 'active'），且该字段上有索引，数据库会先过滤再开窗，实际只扫描有效行 - 某些引擎（如 PostgreSQL）对
ORDER BY+ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING的写法能利用排序索引，但纯OVER()不保证 - 真正影响性能的其实是后续操作：如果归一化后立刻
ORDER BY price_norm或WHERE price_norm > 0.9，而没对原始price建索引，就可能慢——归一化本身不产生新索引
复杂点在于：归一化结果不可索引，必须靠原始列索引支撑；而 NULLIF 和 COALESCE 这类包装会让优化器放弃索引下推，这点极易被忽略。
