您没有确切说明这些表有多大、它们是什么类型的表、它们是如何填充的以及它们是如何使用的。所以,我只是想给出一些随机的想法:)
当您报告大量数据时,您基本上受限于磁盘系统的速度,即磁盘将数据传输到 MySQL 的速度。此速率通常以兆字节/秒为单位。因此,如果您可以获得 100mb/s,那么如果您想要亚秒级响应时间(暂时完全忽略 DB 缓存),则无法在大于 100mb 的表上执行 select sum() 或 count(*)。请注意,100mb 相当于 2000 万条记录,行大小为 50 字节。
这在一定程度上起作用,然后一切都消失了。通常当数据库的大小变得大于可用内存并且并发用户数增加时。
您将需要研究创建聚合表的可能性,以便减少需要扫描的兆字节数。最好用一个例子来解释。假设您当前的度量表如下所示:
measures(
user_id
,timestamp
,action
)
对于执行的每一个操作(登录、注销、点击这个、放屁、点击那个),您都会存储用户的 ID 和它发生时的时间戳。
如果您想绘制从年初开始的每日登录次数,您必须对所有 100,000,000 百万行执行计数 (*) 并按 day(timestamp) 分组。
相反,您可以提供一个预先计算好的表格,例如:
daily_actions(
day
,action
,occured
,primary key(day, action)
)
该表通常会加载以下内容:
select day(timestamp)
,action
,count(*)
from measures
group
by day(timestamp)
,action
如果您有 100 个可能的操作,则只需要 36,500 行来存储一整年的活动。运行统计数据、图表、报告和其他数据的用户不会比典型的 OLTP 事务更重。当然,您也可以按小时(或改为)存储它,并在一年内达到 876,000 行。您还可以使用上表报告每周、每月、三次或每年的数据。
如果您可以将用户操作分组为操作类别,例如“有趣”、“不那么有趣”、可能有害”和“完全错误”,您可以将存储空间从 100 个可能的操作进一步减少到 4 个。
显然,您的数据比这更复杂,但您几乎总能想出合适的 nr 个聚合表,这些表几乎可以回答高聚合级别的几乎任何问题。一旦您“深入研究”了聚合表,您就可以使用所有这些过滤器,然后您可能会发现使用特定的 date 和特定的 action 来选择最低的详细表是很有可能的。