MySQL不支持用ALTER TABLE设置表的最大存储空间；MAX_ROWS仅是优化器提示，MyISAM部分参考、InnoDB完全忽略，无法限制磁盘使用，8.0+已弃用。
MySQL 不支持用 ALTER TABLE 设置表的「最大存储空间」
直接说结论：MAX_ROWS 不是磁盘空间限制，它只是给优化器提供一个行数上限提示，对实际占用的磁盘大小完全无效。你执行 ALTER TABLE t1 MAX_ROWS = 1000; 后，照样能插入百万行、占满整个磁盘。
MAX_ROWS 的真实作用和常见误用场景
这个参数只在 MyISAM 表中起一点辅助作用：影响索引节点大小估算和 AUTO_INCREMENT 初始值选择；InnoDB 完全忽略它。很多 DBA 看到文档里有这个参数，就以为能防爆库，结果线上表写满磁盘才发现没用。
- 仅 MyISAM 引擎读取并参考该值，InnoDB 下设了也白设
- 不触发任何写入拦截或警告，INSERT / LOAD DATA 照常执行
- 即使设成 1，
SELECT COUNT(*)仍可能返回远大于 1 的结果 - 备份、复制、统计信息收集等都不受该值约束
真正能限制表空间增长的可行方案
MySQL 原生没有 per-table 磁盘配额机制，必须绕道实现：
- 用文件系统级配额（如 XFS 的
project quota），把每个表对应的.ibd文件归到独立 project 中限制 - 拆库：把大表单独放到独立 MySQL 实例，用
--datadir指向受限挂载点 - 应用层兜底：在写入前查
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE table_name = 't1';，超阈值则拒绝写入 - 定时巡检 + 告警：用
pt-disk-buffer或自定义脚本监控information_schema.INNODB_SYS_TABLESPACES
为什么别碰 AVG_ROW_LENGTH 和 MAX_ROWS 组合
有人试图靠 AVG_ROW_LENGTH * MAX_ROWS 估算上限，这在 InnoDB 下尤其危险——因为：
- InnoDB 行格式（
COMPACT/DYNAMIC）导致实际存储远大于平均估算 - BLOB/TEXT 字段外存、页分裂、undo log、change buffer 都不计入该计算
- 执行
OPTIMIZE TABLE后空间可能暴涨，原估算彻底失效 - MySQL 8.0+ 已标记
MAX_ROWS为 deprecated，未来版本可能移除
真要控量，盯住 data_free 和 table_rows 的实时偏差，比任何静态参数都靠谱。但记住：所有这些都不是硬隔离，只是软提示或事后补救。
