MySQL 5.7中RANGE TO_DAY与RANGE COLUMN日期分区的差异解析

我来帮你拆解这两种日期分区方式的核心差异，结合你给出的测试脚本，咱们一步步捋清楚：

1. 语法与函数依赖差异 #

• RANGE TO_DAYS()：依赖TO_DAYS()函数将日期/时间类型转换为整数天数，分区边界必须用整数表示。比如对应的建表脚本会是这样：

CREATE TABLE log_tbl_2 (
  id bigint(20) NOT NULL AUTO_INCREMENT,
  stime datetime NOT NULL,
  PRIMARY KEY (id, stime)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
PARTITION BY RANGE (TO_DAYS(stime)) (
  PARTITION p20180401 VALUES LESS THAN (TO_DAYS('2018-04-02')),
  PARTITION p20180402 VALUES LESS THAN (TO_DAYS('2018-04-03'))
);

你必须用TO_DAYS()把日期转成整数，分区值也只能是整数形式。

• RANGE COLUMNS()：直接使用日期/时间类型作为分区列，不需要转换函数，分区边界直接写日期字符串，就像你提供的示例脚本那样，语法更直观，不用额外做类型转换。

2. 支持的数据类型与精度差异 #

• RANGE TO_DAYS()：仅能处理DATE、DATETIME类型，且TO_DAYS()会忽略时间部分（比如DATETIME里的时分秒），只能按天分区；如果用TIMESTAMP类型，还会涉及时区转换问题，容易踩坑。
• RANGE COLUMNS()：在MySQL 5.7中支持DATE、DATETIME、TIMESTAMP，甚至能处理带微秒的DATETIME(6)类型，还可以精确到小时、分钟级别的分区。比如你可以创建按小时拆分的分区：

PARTITION BY RANGE COLUMNS(stime) (
  PARTITION p20180401_00 VALUES LESS THAN ('2018-04-01 01:00:00'),
  PARTITION p20180401_01 VALUES LESS THAN ('2018-04-01 02:00:00')
);

3. 分区维护的便捷性 #

• RANGE COLUMNS()：添加新分区时直接写日期字符串即可，比如：

ALTER TABLE log_tbl_1 ADD PARTITION (PARTITION p20180403 VALUES LESS THAN ('2018-04-04'));

不需要计算TO_DAYS()的整数结果，不容易出错，维护成本更低。

• RANGE TO_DAYS()：添加分区时需要先计算目标日期对应的TO_DAYS()值，比如：

ALTER TABLE log_tbl_2 ADD PARTITION (PARTITION p20180403 VALUES LESS THAN (737154));

这里的737154是TO_DAYS('2018-04-04')的返回值，手动计算很麻烦，还容易算错。

4. 查询性能与分区修剪 #

两者都能触发分区修剪（Partition Pruning），但RANGE COLUMNS()更直接：

• 当你写WHERE stime BETWEEN '2018-04-01' AND '2018-04-02'时，MySQL可以直接匹配分区边界，不需要额外函数转换。
• 而RANGE TO_DAYS()的查询如果要高效触发修剪，最好写成WHERE TO_DAYS(stime) BETWEEN TO_DAYS('2018-04-01') AND TO_DAYS('2018-04-02')，虽然5.7的优化器能兼容直接写日期的情况，但还是不如RANGE COLUMNS()直观。

5. 主键/唯一键要求（两者一致） #

在MySQL 5.7中，两种分区方式都要求分区列必须包含在主键或唯一键中，就像你脚本里的PRIMARY KEY (id, stime)，必须把stime（分区列）包含进去，这点是没有区别的。

总结 #

如果你的场景只需要按天分区，两种方式都能用，但**RANGE COLUMNS()**语法更直观、维护更简单，还支持更细粒度的时间分区，在MySQL 5.7里已经基本覆盖了RANGE TO_DAYS()的使用场景；RANGE TO_DAYS()更多是旧版本的兼容方案，现在已经不是首选了。

内容的提问来源于stack exchange，提问作者Hariharan Suresh