子分区需存储引擎支持，建议用InnoDB；应合理选择RANGE/LIST+HASH/KEY组合策略；注意命名一致性、维护成本及数据分布均衡，适用于大数据量且访问模式明确的场景。
mysql子分区（Subpartitioning）是在已经进行了分区的表基础上，对每个分区进一步划分的技术。它可以帮助更精细地管理数据、提升查询性能和维护效率，但使用时需要注意一些关键点。
确保存储引擎支持子分区
只有 InnoDB 和 MyISAM 存储引擎支持分区和子分区功能。从 MySQL 8.0 开始，MyISAM 已不再推荐用于分区表，官方建议使用 InnoDB。创建子分区前，请确认所用存储引擎支持，并且版本兼容。
合理选择子分区策略
子分区通常采用 KEY 或 HASH 方式，不能像一级分区那样使用 RANGE 或 LIST。常见组合如下：
- RANGE + KEY 子分区
- LIST + HASH 子分区
例如：
CREATE table sales ( id int, year INT, region VARCHAR(10) ) PARTITION BY RANGE (year) SUBPARTITION BY HASH (id % 10) SUBPARTITIONS 4 ( PARTITION p2020 VALUES less THAN (2021), PARTITION p2021 VALUES LESS THAN (2022), PARTITION p2022 VALUES LESS THAN (2023) );
注意：子分区数量应在合理范围内，过多会增加元数据开销，影响管理效率。
显式命名子分区需谨慎
可以为子分区指定名称，但必须为每个子分区都命名，否则会报错。例如：
PARTITION p2020 ( SUBPARTITION s2020_a, SUBPARTITION s2020_b )
一旦开始命名，就必须延续到所有分区的所有子分区，否则语法错误。如果不确定是否需要命名，建议让系统自动生成名称以减少出错风险。
维护和性能影响
子分区虽然能提升某些场景下的查询效率（如结合条件命中特定子分区），但也带来额外复杂性：
- ALTER 操作更耗时，尤其是重建或重组分区
- EXPLAIN 执行计划可能难以准确反映实际访问的子分区
- 备份与恢复时需注意分区结构一致性
建议在高并发写入或频繁 DDL 操作的场景中评估子分区带来的收益是否大于维护成本。
监控子分区数据分布
定期检查各子分区的数据量是否均衡。可通过以下语句查看：
select TABLE_NAME, PARTITION_NAME, SUBPARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA = ‘your_db’ AND TABLE_NAME = ‘sales’;
若发现某些子分区数据严重倾斜，可能说明分区键设计不合理，需重新评估分区策略。
基本上就这些。子分区是强大但复杂的特性，适合数据量大、访问模式明确的场景，使用前务必充分测试。不复杂但容易忽略细节。