不是。mysql无单表行数硬性限制，“两千万”是经验阈值，源于b+树层级增长导致io放大、缓冲池命中率下降及锁竞争加剧；超量后alter table、全表扫描、深度分页、唯一索引冲突检测等操作最先劣化。
单表两千万行是MySQL的硬性限制吗？
不是。MySQL本身没有强制限制单表行数，INFORMATION_SCHEMA.TABLES 里 TABLE_ROWS 字段在大表下甚至只是估算值。所谓“两千万”其实是经验阈值，背后核心是B+树索引的层级增长与磁盘IO放大效应——当数据量增大到一定规模，一次查询可能从“1次IO”退化为“3次甚至4次IO”，响应延迟和锁竞争会明显恶化。
B+树深度怎么算？为什么2000万行常对应3层？
InnoDB默认页大小是16KB，主键索引（聚簇索引）的非叶子节点存的是主键值+页指针。假设主键是BIGINT（8字节），指针占6字节，一个16KB页能存约1170个键值对（16384 / (8+6) ≈ 1170）。按完全满载估算：
- 1层（根）：1页 → 最多指向1170个子页
- 2层：1170页 → 最多指向1170×1170 ≈ 136万条记录
- 3层：136万页 → 最多指向136万×1170 ≈ 15.9亿条记录
但现实中页填充率约60%–70%，且二级索引还需回表，所以实际到2000万行时，B+树大概率已稳定在3层。再往上，虽然仍可能是3层，但页分裂变频繁、缓冲池命中率下降、SELECT ... FOR UPDATE 等操作锁住的页范围更大，问题就开始暴露。
超过两千万行后，哪些操作最先出问题？
不是所有SQL都立刻变慢，但以下场景会快速劣化：
-
ALTER TABLE加字段或改类型：InnoDB 5.6+虽支持在线DDL，但2000万行以上仍易触发copy table，耗时陡增、锁表时间不可控 - 全表扫描类统计：
COUNT(*)、GROUP BY没走索引时，扫描行数翻倍，Buffer Pool压力剧增 - 范围查询配合
LIMIT偏移分页：SELECT * FROM t ORDER BY id LIMIT 1000000, 20需先定位到第100万行，B+树遍历路径变长，CPU和IO双吃紧 - 唯一索引冲突检测：插入时校验重复值需走B+树查找，层数增加后每次冲突判断多1次IO，高并发写入吞吐骤降
真超了怎么办？别急着分库分表
先确认瓶颈是否真来自B+树深度。用SHOW INDEX FROM table_name 查看Cardinality是否合理；用EXPLAIN FORMAT=JSON 看key_length和rows估算是否失真；更直接的是查INFORMATION_SCHEMA.INNODB_BUFFER_PAGE（需权限）观察热点页分布。
多数情况下，优先做这几件事：
- 删掉长期不用的二级索引——每个索引都是独立B+树，越多写放大越严重
- 把大文本字段（
TEXT/MEDIUMTEXT）拆到附表，减少主表页内有效记录密度 - 用
PARTITION BY RANGE (created_at)按时间分区，让WHERE created_at > '2024-01-01'能自动剪枝，避免扫全量B+树 - 确认
innodb_buffer_pool_size是否设为物理内存的70%–80%，否则大量逻辑读转物理读，层数影响被放大
B+树深度只是表象，真正卡脖子的往往是缓存效率、锁粒度和维护成本。两千万这个数字，本质是提醒你：该审视数据生命周期和访问模式了，而不是一到这个数就立刻切分。
