问题
审核触发器通过在每次更新时插入旧行和新行来破坏批量更新查询的性能。
在此触发器中，由于某种原因，插入旧行比插入新行需要更多的时间。
表格
审计表有一个集群索引，3个非集群索引，它有一些像3500万条记录。
Cluster Index
GROUPID , USERID, IDENDITYCOLUMN
FACT
旧行可以插入聚集索引
中的任何位置新行将插入聚集索引的底部
研究
我测试的是，在这个操作中，Cache可以大大提高性能，但我并没有弄清楚究竟需要缓存什么。
的假设
我假设聚集索引是insert操作中最相关的索引。
我假设通过对clusted索引的正确页面进行查询，可以大大提高审计性能
ACTION
我创建了一个查询来加载与我要在操作表上插入的行相关的所有审计行。 通过这样做，性能提高了2倍多，但还不够好。
为什么还不够？
我做了另一个测试，性能更高，但我没想出我需要缓存的是什么。
如何测试？
T01 - 后退和后期测试
我从操作表中抓取了1000行并来回更新它们以查看我是否从审计表中获得了惊人的缓存性能。
A) I have updated GROUPID of 1000 rows to value X (it took a while)
B) I have updated GROUPID of the same 1000 rows to value Y (it took a while)
C) I have updated GROUPID of the same 1000 rows to value X (astonishing cache performance)
D) I have updated GROUPID of the same 1000 rows to value Y (astonishing cache performance)
T02 - 在更新操作表时检查在审计表上缓存的对象
然后我清理了审计缓存，索引缓存和数据缓存，并再次执行了T01 - A）。
我发现，群集索引页面和加载的Datapages，以及大约相同的数量，以及剩余的页面数量都被加载到其他索引中。
T03 - 在运行我的人工缓存加载查询
时，检查在审核表上缓存的对象然后我清理了审计缓存并运行了我的查询。 与测试T02相比，它仅加载了大约一半的页面。
我应用于人工缓存加载查询的逻辑是什么？
我假设我查询了审计表中的所有行，其中GROUPID和USERID存在于1000行中以进行更新（在操作表中），我会加载以缓存审计触发器所需的所有聚集索引和数据页面
Cluster Index
GROUPID , USERID, IDENDITYCOLUMN
然而事实并非如此，因为与测试T02相比，我加载了一半的页面。
问题 如何才能在第一时间获得测试T01-C）或D）的性能？ 我只能在预缓存中考虑数据/索引页面，但我无法找出究竟缺少的内容。
如果你们有其他改进审计表触发器的建议，它也很有价值。
DATABASE
SYBASE 15.7
注意：这是一个属于特定产品解决方案的表，这意味着我无法按照自己的意愿对其进行更改。我有一些限制。