我有一张桌子女巫工作量很大，以免说T1（每秒约100次更新，约300k行）
在第二个表T2中我想更新行，基于它们在T1中的状态，我知道它可以通过触发器轻松完成，但在我的场景中，触发器对性能产生巨大影响并将T1性能降低到每秒约10次更新...
现在我创建了临时表T3并且我在T1状态中选择了它，之后我使用T3进行了合并T1。
但是SELECT INTO临时表仍然需要大笔费用。
如果没有在T1上大量减少更新操作，我有什么方法可以实现我的方案吗？
答案 0 :(得分：2)
一般情况下，如果您发现自己定期根据T1中的数据更新T2，我会对数据模型有疑问，这听起来像是一个非常类似OLTP的系统。这意味着我缺乏关注的正常化。你可能有一个完全正确的理由，有一个单独的T2表复制T1中的一些数据（即你试图支持带有非规范化对象的DSS类型查询以及带有规范化对象的OLTP类型查询）在这种情况下，理解T2的商业目的是有用的。
如果这是尝试使用组合来自多个规范化表的数据的非规范化对象来支持DSS类型查询的情况，我首先想到的是将T2创建为物化视图，而不是作为表。您的物化视图可以按计划的时间间隔进行逐步刷新（也可以在提交更改时刷新，但由于这种情况同步发生，因此可能会减慢插入会话的速度）。您需要在基表上实现物化视图日志，这会给DML操作增加一些开销，但它会小于触发器的开销，特别是如果每次更新都在更新300行（假设300k是数量）为每秒100次更新更新的行。）
您也可以使用Streams来维持T2。这基本上消除了跟踪DML操作变化的开销，因为Streams只是读取重做数据。如果尚未启用补充日志记录，则必须启用补充日志记录，这可能会略微增加写入重做的数据量，但这不太可能是明显的。配置Streams会有更多的工作，但是 - 您需要编写一个自定义应用处理程序，它将从T1获取更改并更新T2。并且T2总是会滞后于T1至少几秒钟。
答案 1 :(得分：0)
如果您对更改的数据感兴趣并且不希望触发器记录它们，请查看Change Data Capture，Streams或Golden Gate。这些都可以为您提供逻辑变更记录。为此，您可以阅读redolog，并且不要通过触发器触及它们来干扰前台进程。另一种选择可能是对您的表格进行真正的好看，看看您是否可以重新安排它们。只要您可以将表的大部分定义为历史（和静态），您就可以有更多选项。