mysql获取删除的条数_确定要删除的MySQL行数以达到目标数据库大...

我有一个包含3个表(A,B,C)的数据库,需要将其保持在一定阈值以下.

A与B和C具有一对多关系…

具体来说,A,B和C具有称为“ g_id”的col,该col用于建立相互之间的关系.有点像图结构,其中A,B和C分别是图,节点和边.

我的目标是：每天,脚本都会获取该数据库的大小,并从这三个表中删除行,直到数据库的总大小缩减到目标大小为止.

我尝试了以下操作：

>使用以下命令获取数据库的大小

SELECT

TABLE_NAME,

round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) as SIZE_MB

FROM

information_schema.TABLES

WHERE

TABLE_NAME in ('A', 'B', 'C') AND

TABLE_SCHEMA = DATABASE()

ORDER BY

SIZE_MB DESC

>尝试估计(A,B,C)的每个逻辑分组相对于其g_id的大小…

SELECT

g_id,

SUM(length(col1)) + SUM(constant) as total

FROM (

(SELECT A.g_id, A.col1, 22 as constant FROM A) UNION ALL

(SELECT B.g_id, B.col1, 22 as constant FROM B) UNION ALL

(SELECT C.g_id, C.col1, 22 as constant FROM C) UNION ALL

) ABC

GROUP BY g_id

ORDER BY g_id;

其中22常数只是每行存储一些固定的bigint,时间戳等的成本的粗略估计…而col1是具有可变长度的文本字段.

>将第2部分加载到内存中后,循环遍历选定的行,并以编程方式将g_ids添加到列表中,直到选择了足够的行以进行删除为止,以使数据库恢复到所需的大小.

>最后,对表A,B,C执行DELETE WHERE g_id IN({g_ids})…

问题是从第1部分返回的大小似乎招致了一些“开销”成本.例如,当我运行第1部分时,数据库的大小约为3 GB,但是当我将第2部分中的所有行加起来时,它的大小仅为2 GB.随着表格的增长,似乎没有可预见的增长差异.

由information_schema.TABLES报告的大小不一致和估计的SUM查询使我删除的行超出了实际需要.

一些问题：

>我是否甚至以正确的方式解决此问题？

>我的计算方法是否可行？

>如何确定间接费用？