系统生成事务记录并将它们放入 RMDB 表中，即使它们是失败案例。该表将被实时查询，并在一天结束时生成报告。
毫无疑问，这张表会很快变大。这是个问题吗？如果表很大，实时查询是否会运行得很慢？有哪些解决方案？
最佳答案
通常，将生产数据库兼作报告数据库并不是一个好主意。有几个原因。其中之一是，通常情况下，您的报告数据库架构与生产数据库相同是没有意义的。通常，出于报告性能原因，您的报告数据库会比生产数据库更加非规范化。
另一个原因是报告数据库的索引要求通常与生产数据库不同。您的报告数据库通常比生产数据库有更多的索引。出于生产目的，您通常不需要那么多索引，而且您通常不需要它们。在繁重的事务系统中，大量索引会导致性能问题。
此外，通常不需要在生产数据库中保留与报告数据库中一样多的数据。在我们公司，我们在生产数据库中保留足够的数据来满足生产需求。这通常是 12 个月。在我们的报告数据库中，我们的数据可以追溯到更远的地方。此外，为了灾难恢复目的，尽量保持生产数据库尽可能小也很重要。您的数据库越大，恢复所需的时间就越长，您离线的时间也就越长。
关于sql - 大事务表是个问题吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7314144/