我目前在zumero同步数据库上经历了很长的同步时间(超过一分钟),并且在进行一些分析之后,罪魁祸首似乎是一个特殊的查询,需要20多秒(适当地匿名):
WITH relevant_rvs AS
(
SELECT rv.z_rv AS rv FROM zumero."mydb_089eb7ec0e2e4772ba0dde90170ee368_mysynceddb$z$rv$271340031" rv
WHERE (rv.txid<=913960)
AND NOT EXISTS (SELECT 1 FROM zumero."mydb_089eb7ec0e2e4772ba0dde90170ee368_mysynceddb$z$dd$271340031" dd WHERE dd.rv=rv.z_rv AND (dd.txid<=913960))
)
INSERT INTO #final_included_271340031_e021cfbe1c97213dd5adbacd667c08439fb8c6 (z_rv)
SELECT z$this.z_rv
FROM zumero."mydb_089eb7ec0e2e4772ba0dde90170ee368_mysynceddb$z$271340031" z$this
WHERE (z$this.z_rv IN (SELECT rv FROM relevant_rvs))
AND MyID = (MyID = XXX AND MyOtherField=XXX)
UNION SELECT z$this.z_rv
FROM zumero."mydb_089eb7ec0e2e4772ba0dde90170ee368_mysynceddb$z$old$271340031" z$this
WHERE (z$this.z_rv IN (SELECT rv FROM relevant_rvs))
AND (MyID = XXX AND MyOtherField=XXX)
我已经采用了查询的后一部分SELECT并将其单独运行,这再现了同样糟糕的性能。有趣的是,执行计划建议应用一个索引,但是我不愿意改变zumero生成表的模式,是为这些表添加索引可以安全地尝试并且它可能有用吗?
源表中有100,000条记录,过滤器导致每个客户端同步100-1000条记录,因此不是简单的数据量,而是我不希望在查询性能方面造成重大问题的级别。
有没有人有优化Zumero同步性能服务器端的经验?源表上的任何索引是否传播到这些表?在这种情况下,它们似乎不存在。
答案 0 :(得分:4)
在z$old
表上创建自定义索引应该是安全的。我希望它有助于提高您的查询性能! (看到评论让我们知道它是否有效会很高兴。)
我认为这样的索引可能导致的唯一问题是它可能会阻止主机表上的某些架构更改。例如,如果您尝试从主机表中删除[MyOtherField]
列,则Zumero触发器也会尝试从z$old
表中删除相同的列,并且事务将失败并显示错误(这可能有点令人惊讶,因为索引不在表上直接作用。)
需要考虑的另一件事:它可能也有助于为这个新索引提供一个名称,如果它出现在错误消息中,它将被识别/有用。然后(一如既往)随时联系support@zumero.com,如果出现任何其他问题或问题,请随时联系。