如何确定 MySQL 表中行子集的大小答案

【问题标题】：How to determine the size of a subset of rows in a MySQL table如何确定 MySQL 表中行子集的大小
【发布时间】：2014-01-25 01:45:05
【问题描述】：

如何计算 MySQL 表中行子集使用的字节（MB、GB）大小。用例是确定用户在数据库中的足迹。所以想法是选择表中属于用户的所有行，然后计算这些行的大小，包括它们的索引（索引？）

我发现了类似的东西，但这只是给了我整个桌子的大小：

SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MB" 
FROM information_schema.TABLES GROUP BY table_schema ;

我真的很感激这个问题的答案。

【问题讨论】：

请注意，任何除以自身的东西都是1。这是问题吗？
@Strawberry 计算将从左到右工作，所以这是(sum( data_length + index_length ) / 1024)/1024

标签： mysql database select memory hard-drive

【解决方案1】：

我认为最简单的方法是进行估算。我假设您可以计算该用户“拥有”的表中的行数，并从中获得该用户“拥有”的行的百分比。将该百分比应用于表格的总大小，您就有了估算值。

如果您尝试更准确的任何事情，如果不付出很多努力，您就不可能实现它，并且可能涉及对其他事情进行估计，所以我会说只是进行估计。如果我被要求这样做，我会说不可能准确，但可以做出合理的估计，这是否足够好......

【讨论】：

谢谢。指数呢？假设索引线性增长是否节省？
不是真的；这取决于添加键的模式。如果键总是在增加（例如每次增加 1 的 int ），那么您可能可以假设。如果不是（例如随机 Guid），那么可能不会因为添加任何键会导致页面拆分。你到底想在这里实现什么？ D空间需求的前瞻性规划，还是其他？
正是如此。我们试图估计即将推出的空间需求。我们每个表有多个索引。其中一些基于自动增量 id，另一些基于复合索引。
好的。我要收回我所说的关于索引的内容。在这些情况下，假设指数和数据都可以线性增长 - 只要您接受它是一个估计值，它就会给您一个很好的估计值。这里的问题是使用模式：生产中表的添加组合是否与开发/测试中的表相同。以 Facebook 为例：如果在测试中平均用户有 x 个朋友，但在 prod 中他们有 2 倍或 0.5 倍，那么您的估计将是错误的。你需要对这类事情进行良好的估计。
是的，当然。我们采用模型用户进行估计，意识到这始终可能只是一个平均值。感谢您提供的所有宝贵意见。