MySQL无法直接限制特定用户表空间大小，因其无用户级磁盘配额机制；唯一可行方案是启用innodb_file_per_table后配合Linux文件系统quota限制mysql用户整体磁盘用量。
MySQL 无法通过配置直接限制特定用户的表空间大小。这不是功能缺失，而是设计使然：MySQL 没有用户级磁盘配额机制，GRANT 控制权限，不控制空间占用。
为什么 SHOW VARIABLES LIKE 'max_user_connections' 这类参数不管用？
这类参数只管连接数、查询时长、临时表大小等运行时资源，和磁盘空间完全无关。你设了 max_user_connections=10，用户照样能往一张表里 INSERT 一亿行，把磁盘撑爆。
-
MAX_ROWS、AVG_ROW_LENGTH是优化器提示，InnoDB 完全忽略，8.0+ 已弃用 -
DATA DIRECTORY只指定路径，不带配额能力；Linux 不认 MySQL 用户名，只认 OS 用户（如mysql） - 哪怕给用户单独建库（
db_app1），只要他有GRANT ... ON *.*或跨库权限，配额就形同虚设
真正起作用的只有 innodb_file_per_table + 文件系统 quota
这是目前唯一能落地的“硬限制”路径，但约束对象是 OS 用户，不是 MySQL 用户。
- 先确认已启用：
SHOW VARIABLES LIKE 'innodb_file_per_table';— 必须为ON - 确保该用户操作的表都在独立
.ibd文件里（老表需ALTER TABLE t ENGINE=InnoDB;重建） - 把 MySQL 数据目录（如
/var/lib/mysql）所在分区挂载时加usrquota（ext4）或prjquota（xfs）选项 - 用
setquota -u mysql 10G 10G 0 0 /dev/sdb1给mysql用户设 10GB 硬上限（注意：不是数据库名） - 触发超限时，MySQL 报错：
ERROR 1114 (HY000): The table 't' is full，而非静默失败
容易被忽略的隐性空间来源会绕过所有“表级”限制
就算你把每张 .ibd 都盯死了，这些地方仍会持续吃空间，且无法归属到具体 MySQL 用户：
-
innodb_undo_tablespaces（undo_001 等文件）：所有事务共享，长事务尤其耗空间 -
binlog：只要log_bin=ON，所有写操作都记，跟谁执行的无关 -
tmpdir下的磁盘临时表：GROUP BY、ORDER BY、大结果集UNION都可能生成，归进程所有者（mysql用户） - 系统表空间
ibdata1：即使开了innodb_file_per_table，它仍存数据字典、回滚段，持续增长
想靠 MySQL 配置实现“某个账号只能用 5GB”，这条路走不通。能做的只有两件事：一是用 OS 层 quota 锁死整个 MySQL 进程的磁盘用量，二是靠监控 + 自动清理兜底——毕竟空间增长是渐进过程，报错前总有窗口可干预。
