我有一个Web应用程序，它有一个带有device_status表的MySql数据库，看起来像这样......
deviceid | ... various status cols ... | created
此表每天插入多次（每台设备每天2000+（估计到年底有100多台设备））
基本上，当设备上发生任何事情时，此表会获得记录。
我的问题是我应该如何处理一张非常快速增长的桌子？
我应该放松一下，希望数据库在几个月内可以正常使用这个表超过1000万行吗？然后在一年有1亿行？这是最简单的，但似乎是一张大表会有糟糕表现的表。
我应该在一段时间（一个月，一周）之后存档旧数据，然后让网络应用查询最近报告的实时表格，并查询实时和归档表格以查找更长时间的报告跨度。
我是否应该有一个每小时和/或每日汇总表来总结设备的各种状态？如果我这样做，触发聚合的最佳方法是什么？克龙？数据库触发器？我可能还需要存档。
处理此类数据必须有更优雅的解决方案。
答案 0 :(得分：1)
我在跟踪网站上广告客户的观看次数时遇到了类似的问题。最初我为每个视图插入一个新行，正如您在此预测的那样，很快就会导致表格变得过大（以至于它确实导致了性能问题，最终导致我的托管公司关闭了网站几个小时，直到我解决了这个问题。）
我使用的解决方案类似于您的＃3解决方案。我不会在新视图出现时插入新记录，而是更新相关时间范围的现有记录。就我而言，我为每个广告记录了每日记录。您的应用使用的时间范围完全取决于您的数据的具体情况和您的需求。
除非您需要专门跟踪过去一小时内的每次事件，否则您可能会过度操作它甚至存储它们并在以后聚合。您可以简单地检查具有匹配规范的条目，而不是打扰cron作业来执行常规聚合。如果找到一个，则更新匹配行的计数字段，而不是插入新行。