大表分区不是简单按时间或ID切分，核心是让查询能精准落到某个分区、避免全表扫描，同时兼顾数据生命周期管理和维护成本。
按业务访问模式选分区键
分区键必须是高频查询条件里的字段，否则分区失效。比如订单表常按“下单时间”查最近7天数据，就用日期字段分区；用户行为日志常按“用户ID”关联分析，可考虑哈希分区或列表分区。
- 范围分区（RANGE）适合时间序列、金额段等有自然顺序的字段
- 列表分区（LIST）适合地区、状态码、业务线等有限离散值
- 哈希分区（HASH）适合均匀分布的ID类字段，但不支持非等值范围查询
- 组合分区（如RANGE-HASH）可用于高并发+时间过滤场景，先按月分大区，再按用户ID哈希细分
控制单分区数据量与数量平衡
单个分区不宜过大（建议500MB–2GB），否则仍影响查询性能；也不宜过小（如每天一个分区存10条记录），否则分区数爆炸，元数据开销大、DDL变慢。
云点滴客户关系管理CRM OA系统
下载
云点滴客户解决方案是针对中小企业量身制定的具有简单易用、功能强大、永久免费使用、终身升级维护的智能化客户解决方案。依托功能强大、安全稳定的阿里云平 台，性价比高、扩展性好、安全性高、稳定性好。高内聚低耦合的模块化设计，使得每个模块最大限度的满足需求，相关模块的组合能满足用户的一系列要求。简单 易用的云备份使得用户随时随地简单、安全、可靠的备份客户信息。功能强大的报表统计使得用户大数据分析变的简单，
- 日均写入100万行，保留1年数据：按月分区较稳妥（共12个分区）
- 日均写入5000万行，热点集中在最近3天：可按天分区+冷数据归档到历史库
- 使用SHOW PARTITIONS或系统表定期检查各分区行数和大小，及时调整策略
分区裁剪必须可被优化器识别
即使建了分区，如果SQL里没带分区键条件，或用了函数/表达式包裹（如WHERE DATE(create_time) = '2024-01-01'），优化器大概率无法裁剪，等于白分。
- 写查询时保持分区键裸露：WHERE create_time >= '2024-01-01' AND create_time
- 避免在分区键上用TO_DAYS()、YEAR()等函数，除非数据库明确支持该函数下推
- 用EXPLAIN查看执行计划，确认key_len、rows和Extra中出现“Using where; Using partition”
配套管理不能只靠分区本身
分区只是手段，不是银弹。需配合归档、清理、统计信息更新等机制才能长期有效。
- 自动清理过期分区：用DROP PARTITION或TRUNCATE PARTITION，比DELETE更高效
- 新分区预创建：避免插入时动态新建分区导致锁表或延迟（尤其MySQL 5.7+支持）
- 定期ANALYZE TABLE更新统计信息，防止优化器误判分区选择
- 备份时按分区粒度导出，支持快速恢复某段时间数据
不复杂但容易忽略。
