问Sybase 15性能问题

EN

我刚刚在工作中花了14个小时调试周末Sybase 15迁移产生的关键性能问题。

查询优化器(对我们来说)做出了一些非常奇怪的决定。

举个例子，

select a, b, c from table1, table2, table3 where ...

对比

create table #temp (col1 int, col2 int, ... etc)

insert #temp
select a, b, c from table1, table2, table3 where ...

我们在很好的时间内进行了第一次运行，尽管进行了大量的返工，但在第二次运行时无法做出正确的决定。我们甚至将查询分解为临时表，但仍然得到了不寻常的结果。

最后，我们求助于SET FORCEPLAN ON进行一些查询--这是在我们的DBA和Sybase在线运行了10个小时之后。解决方案也来自应用程序开发人员，而不是Sybase工程师的任何建议。

所以为了节省你自己的时间，我建议你走这条路。

和其他人一样，我有同情而不是真正的答案！我们看到了一个问题，ASE 15查询规划器严重低估了表扫描的成本，并同样高估了使用聚集索引的成本。这会使合并联接成为建议的计划。禁用合并连接或设置allrows_oltp选项有时会产生更好的查询计划。估计的成本仍然很低，但是通过从表中删除一个选项，查询规划器可能会找到一个很好的解决方案-尽管是通过错误的分析。

ASE 15的文档说它有一套更干净的算法，而ASE 12的计划者有一堆特殊的情况。也许说“如果在连接中有聚集索引列，它将比表扫描更快”这样的特殊情况可能不是一个坏主意……:(

Sybase有效地重写了版本15的查询引擎，这意味着在12.x上运行超快的查询在新版本上可能运行得慢得多，反之亦然。调试它的唯一方法是将12.x查询计划与15查询计划进行比较，看看有什么不同之处。