不能直接用 GROUP BY 配合 WHERE 做价格区间统计，因为区间非现成字段、硬编码维护困难且无法动态适配配置表定义的灵活规则；需通过子查询生成区间维度再 LEFT JOIN 关联统计，实现配置驱动、SQL 稳定。
为什么不能直接用 GROUP BY 配合 WHERE 做价格区间统计
电商后台常要查“各价格区间（如 0–99、100–299、300+）的商品数量”，但价格区间不是数据库里现成的字段，也不能靠简单 WHERE price BETWEEN 100 AND 299 一次性覆盖所有段——那样得写一堆 UNION，维护困难，且无法动态适配运营临时调整的区间规则。
更关键的是：区间定义本身可能来自配置表（比如 price_ranges 表含 min_price、max_price、range_name），而商品数据在 products 表。硬编码区间会让 SQL 失去灵活性。
所以必须让区间逻辑可配置、可复用，嵌套查询是轻量又可控的选择。
用子查询生成区间维度再 LEFT JOIN 统计
核心思路是：先用子查询把价格区间“变成一行行数据”，再和商品表关联计数。这样区间变动只需改配置表，SQL 主体不动。
SELECT r.range_name, COUNT(p.id) AS product_count FROM ( SELECT '0-99' AS range_name, 0 AS min_p, 99 AS max_p UNION ALL SELECT '100-299', 100, 299 UNION ALL SELECT '300+', 300, 999999 ) AS r LEFT JOIN products p ON p.price >= r.min_p AND p.price <= r.max_p GROUP BY r.range_name, r.min_p, r.max_p ORDER BY r.min_p;
- 子查询部分模拟了配置表，实际中可替换为
SELECT range_name, min_price, max_price FROM price_ranges - 必须用
LEFT JOIN，否则没有商品的区间会消失（比如“300+”暂时没货），而运营通常需要看到“0”这个数字 -
ORDER BY r.min_p保证输出顺序符合业务预期，不依赖字符串排序（否则 “100-299” 会排在 “0-99” 前）
当区间配置存在 NULL 或边界重叠时怎么防错
真实配置表里，max_price 可能为 NULL（表示“及以上”），或不同区间的 min_p/max_p 有缝隙或重叠。直接用 BETWEEN 会漏数据或重复计数。
-- 安全的区间匹配条件（替代 BETWEEN） ON p.price >= r.min_p AND (r.max_p IS NULL OR p.price <= r.max_p)
- 用
r.max_p IS NULL显式处理“无上限”区间，避免BETWEEN x AND NULL永远为 false - 不要用
OR连接多个区间条件（如WHERE price BETWEEN ... OR price BETWEEN ...），会导致优化器放弃索引，全表扫描 - 如果区间定义有重叠（比如 100–199 和 150–250），一个商品会被计入多次——这不是 bug，而是业务需求是否允许“多区间归属”。若不允许，需在配置层加唯一性约束或用窗口函数排重
性能敏感场景下如何避免嵌套查询拖慢报表
子查询本身不走索引，但关联字段（p.price）如果有索引，JOIN 条件仍能利用。真正拖慢的是：当商品表极大（千万级）、区间数很多（>100）、且每次查询都重新生成子查询时。
- 对固定区间（如常规四档），把子查询提取为物化视图或临时表，避免重复解析
- 对动态区间，优先在应用层预计算区间 ID（如给每个
product加price_range_id字段并建索引），把“运行时分组”转为“存储时归类” - MySQL 8.0+ / PostgreSQL 可考虑用
LATERAL或CROSS JOIN LATERAL替代普通 JOIN，对复杂区间逻辑（如按销量加权分段）更可控
嵌套查询做价格区间统计本身不难，难的是让“区间定义”和“统计逻辑”解耦，同时扛住数据量和配置变更的双重压力。很多人卡在第一步就硬写一堆 UNION ALL，结果改个区间要动三处 SQL——其实只要把区间当成一张小表来 JOIN，后面所有扩展都顺了。
