djaogo orm 旧表加字段报错django.db.utils.OperationalError: (1114, “The table ‘reportdata‘ is full“)解决方案

目录

报错之源

一、解决方案一

二、解决方案二

---

报错之源

python manage.py migrate

时报错如下

django.db.utils.OperationalError: (1114, "The table 'reportdata' is full")

提示这个的意思：表内容占用硬盘大小超了，需要扩容表内存(这里是表在硬盘中的占容量大小)上限大小

系统默认是16M

可以通过下面Sql语句查询相关表的大小

select table_name, truncate(sum(data_length)/1024/1024,2) as data_size_MB,
truncate(sum(index_length)/1024/1024,2) as index_size_MB
from information_schema.tables where table_schema = '库名'
group by table_name
order by data_size_MB desc

看下图，笔者的业务都15715M了， 相当于15个G，刚开发这个工具都不知道在梦游啥，导致发生这样的恐怖的事情，一个表15个G。

不过事儿来了，就得解决，不能怕事。这里笔者尝试了下面两种方案，基本上可以解决问题

一、解决方案一

    在mysql服务中找到my.cnf      windows系统是my.ini

    本文的服务器是linux，

    my.cnf在etc目录下

        vim /etc/my.cnf

    在[mysqld]下修改或添加下面两个字段的大小，默认是16M

        tmp_table_size = 17,408M

        max_heap_table_size = 17,408M

    比如本文这里要超这15g，笔者给了17g

    

保存

2、重启mysql

    systemctl restart mysql

然后再去运行

python manage.py migrate

肯定成功了

二、解决方案二

此方案是笔者在第一方案都不能成功的情况下，无奈想出来了

拆表

    orm创建一个新表，新表中写业务字段，用一个int字段与接收主表id，但不能外键主表id，使用代码来开发外键逻辑。 

        为啥不能外键呢？

        想一想也就知道，它会继续去关键那个大小超标的表，必定还是会报错。我就是遇到了这个问题，所以提前跟大家说明，不能外键主表id，也不能在sql脚本中跟主表有任何关联，自己在取数据代码中写逻辑处理

   

    拆出来一个表，

后续代码去处理业务逻辑

这里不细表述内容，能看到这里的都是大佬了，提供一个思路都知道怎么弄了。

其实还有终级解决方案，但时间仓促，后续有空解决的话，将继续补全这簏内容

警示：

        在开发工具之前，设计数据库一定要考虑长远，不可偷懒，免得后面得不停的擦屁股