我们的情况是必须在2个数据库之间进行选择。 我们目前使用的是Firebird，但有时因为它堆积了太多的交易记录或其他东西而滞后，应该使用备份恢复来使事情变得更好。
在我的具体案例中： 数据库主要有填充数字字段的表。 查询主要有内部联接。 几乎与我插入和选择的速率相同。 （但未来我正在寻找更严厉的选择） 有3个主表有几百亿个记录（每秒都在增长）。
但我想看看哪个是最好的整体进入正常负载，如上面的那些，以及重载 - 比如选择和处理所选字段，整体表现为事件触发和存储过程执行，我认为这是足够好的应用知道在他们之间做出选择（欢迎提出更多意见），并可能帮助其他人民做出决定。
我在问
P.S。：我将暂时留下这个问题而不检查解决方案。也许会有人在正常的，每天的查询基础上实际上对数据库进行处理，问题和结果对我来说会更有用，其他人也会对这种情况感到不满。
答案 0 :(得分：8)
您描述的问题通常是由错误的事务管理或长时间运行的事务引起的。通常，您不需要备份和还原来解决此问题。备份应该足够了（因为Firebird在备份期间会进行额外的清理和垃圾收集）。
Firebird（和Interbase）都使用多版本并发控制，这意味着更改将记录在新的记录版本中。只有在没有打开对该事务感兴趣的事务时，才会清除旧记录版本。由回滚事务创建的记录版本仅在扫描期间清除。
错误的事务管理（具有长时间运行的事务，或使用提交保留而不是提交），意外断开连接等可能意味着事务仍处于打开状态，这意味着它们需要由数据库清理（所谓的扫一扫火鸟）。这可能会降低数据库的速度，因为它需要读取同一记录的多个版本。
如上所述，在进行备份时执行扫描。因此，只需进行备份就足以消除大部分问题。
有关更多详细信息，请查看gfix housekeeping
答案 1 :(得分：7)
显而易见的，我担心相当乏味的答案是，您将不得不使用自己的工作负载对这两者进行基准测试。您的应用程序工作负载可能与其他所有基准或应用程序不同。
答案 2 :(得分：3)
您可以将测试数据库和测试用例发送给Firebird开发人员，以便他们可以提高速度
我开始认为数据库需要分区