MySQL 本身不支持用户级磁盘配额
MySQL 没有内置机制为单个用户设置磁盘使用上限（比如限制 user_a 只能用 5GB）。它不跟踪、也不强制执行「某个账号创建的表占了多少空间」。所谓「用户磁盘配额」，是常见误解——GRANT 权限控制的是操作权限，不是存储资源配额。
真正能起作用的，只有操作系统层或存储引擎层的间接约束：
- Linux 下可通过
quota或systemd --scope限制 MySQL 进程所属用户的整体磁盘用量（但无法区分是哪个 MySQL 用户干的） - InnoDB 表空间若启用了
innodb_file_per_table=ON，每个表对应一个.ibd文件，可配合文件系统硬链接+配额策略做粗粒度隔离（运维成本高，且不防 DDL） - MySQL 8.0+ 的
CREATE RESOURCE GROUP仅限 CPU 和 I/O 调度，和磁盘空间无关
用 schema 级别配额模拟“用户空间限制”
如果业务上一个 MySQL 用户只操作一个 database（如 user_app1 → db_app1），可把限制落到 database 所在的表空间或目录上：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确保该库所有表都建在独立表空间：建库时指定
DEFAULT TABLESPACE ts_app1，并提前创建好该TABLESPACE指向专用路径（如/var/lib/mysql/ts_app1/） - 用 Linux
quota或lvm逻辑卷配额，限制该路径所在挂载点的总用量（例如/var/lib/mysql/ts_app1所在分区设为 10GB） - 注意：此法对
mysql系统库、information_schema等无效；且一旦用户被授权跨库操作，配额即失效
监控 + 告警替代硬限制更现实
生产中更可行的做法是定期检查空间占用，并触发告警或自动清理：
- 查某用户关联的所有库大小：
SELECT table_schema, ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS mb FROM information_schema.tables WHERE table_schema IN ('db_app1', 'db_app2') GROUP BY table_schema; - 结合
PROCESSLIST和USER()判断当前连接归属（但无法追溯历史 DML 产生的空间增长） - 用
pt-diskusage（Percona Toolkit）按目录统计，配合 cron 每小时扫描/var/lib/mysql/db_app1/目录大小 - 当超过阈值（如 8GB），发通知或调用脚本
DROP TEMPORARY TABLE/ 清理binlog/ 归档旧表
容易被忽略的隐性空间消耗点
即使你盯紧了 .ibd 文件，这些地方照样吃空间，且难归因到具体用户：
-
innodb_undo_tablespaces产生的undo_001等文件：长事务、大事务回滚日志，由所有用户共享，无法按用户隔离 -
binlog：只要log_bin=ON，所有写操作都会记，哪怕只是user_a执行了一条UPDATE -
tmpdir下的临时表文件：GROUP BY、ORDER BY、UNION等操作生成的磁盘临时表，归属当前会话用户，但文件名无用户标识 -
general_log或slow_query_log开启后，日志文件增长也计入磁盘，且内容里虽有User@Host，但日志本身不按用户分文件
所以真要控空间，得从源头收口：限制大事务、禁用非必要日志、定期 rotate binlog、避免让应用用户直连执行重负载查询。
