Java应用连接MySQL时，海量数据按时间段查询变快的关键在于正确使用MySQL RANGE分区：必须用TO_DAYS(create_time)分区、分区字段加入主键、LESS THAN对齐自然月起始日、保留p_future分区，且查询条件需直接比较时间字段以触发分区裁剪。
Java 应用连接 MySQL 时，要让海量数据下按时间段查询真正变快，关键不在 Java 侧写多少代码，而在于 MySQL 分区表是否建对、查对、用对。只要分区设计和查询方式匹配，Java 端只需普通 JDBC 或 MyBatis 调用，就能自动享受分区裁剪带来的性能提升。
选对分区方式：按时间 RANGE 分区最实用
历史数据查询几乎都带时间范围条件（如 create_time BETWEEN '2025-06-01' AND '2025-06-30'），RANGE 分区天然适配。推荐用 TO_DAYS(create_time)，而不是 YEAR() 或 UNIX_TIMESTAMP()：
-
TO_DAYS()把日期转成整数，边界清晰、无时区干扰，且能精确到日级分区（比如按月） - 避免
YEAR(create_time) = 2025这类写法——函数包裹分区键，MySQL 无法推导分区范围，EXPLAIN PARTITIONS会显示partitions: NULL，等于白分 - 不建议用
MONTH(create_time)单独分区，会导致跨年数据混在同一个分区，失去时间隔离意义
建表必须满足的硬性条件
MySQL 5.7+ 对分区表有严格约束，缺一不可，否则建表失败或查询失效：
- 分区字段（如
create_time）必须包含在主键或唯一索引中；若原主键是id，就得改成联合主键：PRIMARY KEY (id, create_time) - 分区表达式必须是确定性函数，
TO_DAYS('2025-07-01')正确，TO_DAYS(NOW())或UNIX_TIMESTAMP()不稳定，易出错 - 每个分区的
LESS THAN值要对齐自然月起始日，例如覆盖 2025 年 7 月，应写LESS THAN (TO_DAYS('2025-08-01'))，不是'2025-07-31' - 必须保留一个
p_future VALUES LESS THAN MAXVALUE分区，防止插入未来日期时报错ERROR 1526
Java 查询时怎么写才真正走分区
Java 里用 PreparedStatement 发送 SQL，语法本身没特殊要求，但写法决定能否触发分区裁剪：
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确：
WHERE create_time >= ? AND create_time （传入 <code>'2025-07-01'和'2025-08-01'） - ❌ 无效：
WHERE YEAR(create_time) = 2025 AND MONTH(create_time) = 7（函数包裹，全分区扫描） - ❌ 无效：
WHERE DATE_FORMAT(create_time, '%Y-%m') = '2025-07'（同上，彻底失效） - ⚠️ 注意排序 + 分页：
ORDER BY create_time DESC LIMIT 20会先从所有匹配分区各自取前 20 条，再合并排序，可能比单分区慢；如只需最新数据，可加AND create_time >= '2025-07-01'缩小范围
验证和运维不能跳过
上线前必须验证分区是否生效，日常也要定期维护：
- 用
EXPLAIN PARTITIONS SELECT ...查看partitions列，只出现 1–2 个分区名才算成功；如果显示全部分区或NULL，说明没裁剪 - 每月初用
ALTER TABLE ... REORGANIZE PARTITION p_future INTO (...)新增下月分区，比DROP + ADD更安全，支持在线操作 - 归档旧数据别直接
DROP PARTITION，应先导出备份，再用TRUNCATE PARTITION清空，保留结构可回滚 - 分区总数控制在 30–60 个以内，太多会增加元数据开销，反而拖慢 DDL 和查询优化器决策
