我在我的应用程序中使用 Sybase 15，并且存在与嵌套连接相关的性能问题。我有存储过程，它从 2 个表中选择 2 列，并比较这 2 个表之间超过 10 列的相等性。但是当我运行这个存储时。 proc.，结果需要 40 分钟。我在我的 proc 顶部添加了“set merge-join off”语句，然后结果需要 22 秒。但我需要另一种解决方案。我之前使用的是 sybase 12.5，没有任何类似的问题，我的 proc 需要 3 分钟才能得到结果。
我用 sp_configure 在 15 和 12.5 之间比较了服务器配置，并且 sybase15 服务器配置（I/O 和内存配置设置）比 sybase12.5 服务器大。
信息：sybase15所在的pc的系统资源非常好。
【问题讨论】：
标签： performance join nested sap-ase
和其他人一样，我是同情而不是真正的答案！我们看到一个问题，ASE 15 查询计划器大大低估了表扫描的成本，同样高估了使用聚集索引的成本。这导致合并连接成为建议的计划。禁用合并连接或设置 allrows_oltp optgoal sometimes 会产生更好的查询计划。估计的成本还有很长的路要走，但通过从表中取消一个选项，查询规划器可能会找到一个好的解决方案 - 尽管通过错误的分析。
ASE 15 文档说它有一套更简洁的算法，而 ASE 12 规划器有很多特殊情况。也许一个特例说“如果你在连接中有聚集索引列，它会比表扫描更快”不会是一个坏主意...... :(
【讨论】：
我刚刚花了 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 工程师的任何建议。
所以为了节省一些时间，我的建议是走这条路。
【讨论】：
Select a.col1,b.col1 from table2 b,table1 a where ....，我的查询需要 9 秒，但是当我再次写 insert table3 (col1,col2) select a.col1,b.col1 from table2 b,table1 a where .... 时，查询需要 40 多分钟。我认为我必须研究新的插入语句。
Sybase 有效地重写了版本 15 的查询引擎，这意味着在 12.x 上运行超快的查询在新版本上可能运行得更慢，反之亦然。对此进行调试的唯一方法是将 12.x 查询计划与 15 查询计划进行比较，看看有何不同之处。
【讨论】：
所有关心这个问题的人都应该阅读这个文档：
http://www.sybase.com/files/White_Papers/ASE15-Optimizer-Best-Practices-v1-051209-wp.pdf
它有一个关于从 Sybase 12 迁移到 Sybase 15 的坦率警告。
引用：
...不要将 ASE 15 视为“只是 另一个版本”。尽可能多地 想说你可以简单地 升级并将您的应用程序指向 升级的服务器，深度和 变化幅度最大的国家之一 数据库的基本领域，查询 执行，需要更加专注 测试方案。这篇论文的意思 为您提供明确的事实 以及减少这种情况的最佳实践 尽可能地努力 可能。
接着讨论新的 ASE 15 查询优化器、相对于 OLTP 查询和 DSS（决策支持系统）查询。
不过，好消息：2009 年 3 月，Sybase 15.0.3 引入了兼容模式。请参阅以下文档：
http://www.sybase.com/detail?id=1063556
使用此模式，您无需分析查询来确定它们是否适合 OLTP 或 DSS 配置文件。
【讨论】：