4、范围分区裁剪实战：日期范围查询优化、数值范围裁剪、边界值处理技巧

范围分区，说白了就是按数据值的区间来分堆。日期是最常见的，数值次之。但很多人建了分区，查询却没快多少——问题往往出在裁剪没生效。

我见过太多这样的案例：明明分了区，执行计划却扫了全部分区。为什么？因为SQL写法没让优化器认出「我只查这一个区」。今天咱们就把日期、数值、边界值这三个场景彻底聊透。

核心原则：分区裁剪生效的前提是——分区键出现在WHERE条件中，且条件形式能被优化器静态推导出具体分区号。

4.1 日期范围查询优化

日期分区是最常见的场景。我习惯按月分区，因为大多数业务系统的查询窗口都在1-3个月内。

先看一个典型的慢查询：

-- ❌ 裁剪可能失效
SELECT * FROM orders
WHERE order_date >= '2024-01-01'
  AND order_date <= '2024-03-31';

这个写法本身没问题。但如果你把分区键包在函数里，裁剪就废了：

-- ❌ 裁剪失效！函数包裹分区键
SELECT * FROM orders
WHERE DATE_FORMAT(order_date, '%Y-%m') = '2024-01';

为什么会这样？因为优化器在编译阶段不知道 DATE_FORMAT(order_date, '%Y-%m') 对应哪个分区。它只能老老实实扫所有分区，再逐行过滤。

正确的做法是：

-- ✅ 裁剪生效
SELECT * FROM orders
WHERE order_date >= '2024-01-01'
  AND order_date <  '2024-02-01';

我个人习惯在写日期范围查询时，遵循两个原则：

  • 分区键裸写——不加函数、不加计算
  • 用半开区间——>= 和 < 组合，避免 BETWEEN 带来的边界歧义

小技巧：如果业务必须按周查询，可以在分区表上建一个「周起始日」的计算列，然后按这个列分区。这样查询条件直接写 week_start = '2024-01-01'，裁剪精准命中一个分区。

4.2 数值范围裁剪

数值分区常用于订单金额、用户积分、传感器读数等场景。我遇到过一个大促活动表，按订单金额分了5个区：0-100、100-500、500-2000、2000-10000、10000以上。

数值裁剪的关键点在于——条件要能映射到分区边界。

-- ✅ 裁剪精准
SELECT * FROM orders
WHERE amount >= 500 AND amount < 2000;

但如果你写成这样：

-- ❌ 裁剪可能失效
SELECT * FROM orders
WHERE amount * 1.1 > 550;

嗯，这里要注意：amount * 1.1 让优化器无法直接判断 amount 的原始值落在哪个分区。它只能扫全部分区，再逐行计算。

我曾经在项目中排查过一个慢查询，就是因为在WHERE里写了 amount + 100 > 600。改成 amount > 500 后，查询从扫5个分区变成只扫1个分区，耗时从2秒降到0.1秒。

避坑指南：我曾经见过有人把数值分区键和另一个字段做运算，然后抱怨分区没效果。记住——分区键在WHERE里必须是「裸列」，不能有任何包装。

4.3 边界值处理技巧

边界值是最容易出Bug的地方。你想想看，2024-01-01 00:00:00 到底算1月分区还是12月分区？

我总结了一套边界值处理规则：

场景 推荐写法 说明
查某一天 date >= '2024-01-01' AND date < '2024-01-02' 半开区间，精确命中1个分区
查某个月 date >= '2024-01-01' AND date < '2024-02-01' 避免用 BETWEEN 和 LAST_DAY
查某个数值区间 val >= 100 AND val < 200 左闭右开，与分区边界对齐
查「大于等于某值」 val >= 1000 优化器会扫描从1000分区开始的所有分区

这里有个容易被忽略的点：分区边界定义和查询条件要一致。如果你的分区是按 LESS THAN (100)、LESS THAN (200) 定义的，那么查询条件用 val >= 100 AND val < 200 就能完美对齐。

但如果分区定义是 LESS THAN (100)、LESS THAN (200)，而查询写的是 val BETWEEN 100 AND 199，结果是一样的——但 BETWEEN 在语义上容易让人误解。我建议统一用 >= 和 <。

个人习惯：我在建分区表时，会把分区边界定义和查询模板一起写在注释里。这样后来接手的人一看就知道怎么写查询才能命中裁剪。

4.4 分区裁剪流程图

下面这张图展示了从SQL解析到分区裁剪的完整流程。我把它画出来，方便你理解优化器是怎么「剪掉」无关分区的。

分区裁剪执行流程 分区裁剪执行流程 SQL 解析 提取 WHERE 条件 分区键是否裸列？ 是 计算分区范围 裁剪无关分区 只扫描目标分区 否 全分区扫描 关键判断点：分区键是否被函数/计算包裹？是 → 全分区扫描；否 → 精准裁剪

从这张图可以看得很清楚：「分区键是否裸列」是整个裁剪流程的分水岭。一旦走了「否」分支，前面建分区花的功夫就白费了。

4.5 实战避坑清单

最后，我把自己踩过的坑和帮别人排查的案例整理成一份清单。你写SQL的时候可以对照着检查：

  • 日期字段用函数：DATE(order_date)、MONTH(order_date) → 改成裸列 + 半开区间
  • 数值字段做运算：amount * 0.9、amount + 100 → 把运算移到常量侧
  • 隐式类型转换：分区键是 INT，条件写 '100' → 确保类型一致
  • OR 条件：WHERE partition_key = 1 OR other_col = 2 → 优化器可能放弃裁剪，改用 UNION ALL
  • 子查询包裹：SELECT * FROM (SELECT * FROM t WHERE ...) WHERE partition_key = 1 → 把分区条件提到最外层

我曾经帮一个团队排查线上慢查询，发现他们的分区表查询走了全分区扫描。最后定位到原因：分区键是 DATE 类型，但查询条件写的是 order_date = '2024-01-15 10:30:00'——隐式把字符串转成 DATETIME，类型不匹配，裁剪失效。改成 order_date = DATE '2024-01-15' 后，问题解决。

嗯，范围分区裁剪其实不复杂。记住三个要点：分区键裸写、半开区间、类型一致。做到这三点，你的分区表查询基本不会走偏。

← 上一章 📖 返回目录 下一章 →