MySQL分区表适用于特定场景而非万能提速方案：数据超2000万行且存在时间/业务维度范围查询、需快速删过期数据、高并发写入需分散热点、或慢查询无法单靠索引优化时，合理分区可提升性能。

MySQL 分区表不是“用了就快”的银弹，而是针对特定数据规模和访问模式的优化手段。是否启用分区，关键看你的数据增长节奏、查询习惯和运维能力——盲目分区反而增加复杂度、拖慢性能。

单表数据量持续超过2000万行

当InnoDB表行数突破两千万，尤其是没有合适索引支撑的范围查询（如按时间查日志、订单），B+树深度增加，I/O放大明显。分区可将大表逻辑拆成多个子表（如按月分partition），让查询只扫描目标分区，减少数据页读取。

注意：仅靠行数不够，还要看实际磁盘占用和查询响应。有些宽表1000万行已超10GB，而轻量用户表5000万行可能仍很轻快。

存在明显时间/业务维度的范围查询或归档需求

典型场景包括：日志表按day/month/year分区、订单表按created_at分区、用户行为表按region_id或tenant_id做列表分区。

• 支持快速删除过期数据（DROP PARTITION比DELETE WHERE快得多，不走逐行标记）
• 查询带分区键条件时（如WHERE dt = '2024-06'），优化器能自动Pruning，跳过无关分区
• 冷热数据天然隔离，便于备份策略（只备热分区）或迁移（如把历史分区迁到归档库）

写入压力集中且需降低锁竞争

高并发写入同一张大表时，即使有索引，也可能因二级索引维护、undo段争用、buffer pool刷脏等引发锁等待。合理分区（如按hash或key分区）可分散写入到不同物理段，缓解热点。

但要注意：分区键选择不当会适得其反。例如用自增ID做RANGE分区，所有新写入都挤在最后一个分区，等于没分；而用用户ID哈希则更均匀。

已有慢查询长期无法通过索引优化解决

如果EXPLAIN显示type=ALL或range扫描行数巨大，且WHERE条件中固定包含某个字段（如WHERE app_id = ? AND event_time BETWEEN ? AND ?），该字段就适合做分区键+组合索引前缀。

此时分区不是替代索引，而是配合索引形成“两级过滤”：先定位分区，再在小范围内走索引查找，效果常优于单一大索引。

不复杂但容易忽略