一、问题
·64TB是单张表的上限，不是实例的总容量上限。
·当某张表的物理体积接近或达到64TB时，该表无法继续写入，可能导致实例出现异常。
二、问题触发场景
满足以下条件时，可能触发该问题，需要重点关注：
·业务表长期单调增长，且没有做分区表或分库分表。
·存在单张超大表，数据 + 索引持续累积。
·单表数据量已达到 TB 级并仍在快速上涨。
三、涉及引擎版本
| 引擎版本 | 是否涉及 |
| MySQL 5.7 | 是 |
| MySQL 8.0 | 是 |
四、解决方案分析
·升级内核无法突破单表最大64TB的限制。
·应对方式是提前规划 + 在线腾挪 / 拆分，在表接近上限之前主动处理。
五、1. 查看占用最高的表
建议你定期执行以下 SQL，查出占用量 Top10 的表，并重点关注头部大表。
MySQL 5.7 参考如下 SQLMySQL 8.0 参考如下 SQLset session sql_mode='';select t.table_schema, t.table_name, (data_length + index_length)/1024/1024/1024 as size_Gfrom information_schema.tables tjoin information_schema.INNODB_SYS_TABLES syst on concat(t.table_schema,'/',t.table_name) = substring_index(syst.NAME,'#',1)where syst.SPACE = 0group by t.table_schema, t.table_nameorder by size_G desclimit 10;set session sql_mode='';select t.table_schema, t.table_name, (data_length + index_length)/1024/1024/1024 as size_Gfrom information_schema.tables tjoin information_schema.INNODB_TABLES syst on concat(t.table_schema,'/',t.table_name) = substring_index(syst.NAME,'#',1)where syst.SPACE = 0group by t.table_schema, t.table_nameorder by size_G desclimit 10;
六、2. 在线腾挪
对查询结果中头部的大表，你可执行在线表重建，对表做整理 / 搬迁，以降低数据量接近单表上限可能带来的风险：
ALTER TABLE $db.$tb ENGINE = INNODB, ALGORITHM=INPLACE, LOCK=NONE;
·$db：在实际执行命令中，请将此参数替换为你的数据库名。
·$tb：在实际执行命令中，请将此参数替换为你所选数据库下的表名。
七、建议
1. 定期巡检：根据上文中查看占用最高的表的 SQL，定期查看 Top10 大表占用情况。
2. 及时腾挪：对头部大表执行在线腾挪重建。
3. 合理控制表数据量增长：超大表配合分区 / 拆分 / 归档，从源头控制单表体积。