我试图在MySQL中存储大量数据（价值30年的每日价格），并希望按日，按月，按年查询。
我知道我可以在索引日期字段上使用聚合函数，这也将由MySQL本身缓存，但我不确定它是否可能很昂贵。我也考虑过单独存储月度和年度数据，但我很确定这是违反规范化规则的，并且难以维护。
如果价格昂贵，我计划添加memcached。我只想获得一些反馈，我确信这已经一次又一次地完成。针对这个特殊问题的最佳做法是什么？
更新
为了提供更多细节，数据将显示在图表中，可以通过每日，每周，每月，每年范围轻松调整。它目前仍处于开发阶段，我没有足够的数据来确定优化要求。如果是这样的话，你认为我应该推迟优化，直到我看到问题为止？ （可能是过早的优化？）或者是否有基线模式来准备这种问题？感谢。
答案 0 :(得分：0)
评论时间有点长。
数据库结构应该由访问数据的要求驱动。您的问题没有解释实际的访问模式是什么。
如果您有月度和年度摘要的性能要求，以及过于详细的30年日常记录，则可以在数据库中维护摘要。复杂性是在存储过程或触发器中添加逻辑以维护汇总表。
这是满足性能需求的通用结构。
您可以通过一些聪明的数据结构来满足您的需求。您的问题没有提供有关您真正需要的信息。也许表分区可以解决性能问题。也许每年和每月都有单独的可索引列可以解决问题。也许有一个月或一年表示高低值的标志可以解决问题（尽管你需要触发器来维护这些）。