无法使用动态sql回忆任何问题...然后再次...不记得我上一次考虑它的情况（我的RDB中有99％是ASE，而近年来的绝大多数ASE是 是启用了语句高速缓存/文字自动参数的ASE 15/16）。

------------

假设复制到ASE 15.x/16.x中，对我来说，一个大问题是...哪一个更快和/或更有效... SRS/dynamic-sql与ASE/statement-cache/文字自动参数。 [我一直倾向于让ASE使用语句缓存； 使用最新/最新版本的ASE和SRS进行一些测试以查看性能是否存在明显差异可能不会受到伤害。]

很显然（？），如果ASE没有启用语句缓存（和文字自动参数），则从ASE角度来看，在SRS中启用动态sql应该可以提高性能（即，消除调用#2 +的编译开销）， 问题会在SRS中看到哪种性能下降（如果有的话）（额外的内存使用-也许；额外的CPU-??）。

如果RDS是ASE以外的其他东西，并且不存在等效的语句缓存，但是支持等效的预准备语句，那么（显然，再次）启用SRS动态sql听起来很容易。

>

------------

我希望服务器范围的优先级最低，其次是DSI/连接级别设置，然后是repdef级别设置（即，DSI/连接设置优先于服务器； repdef优先于DSI/连接和服务器 ）。 [很容易测试eh。]

------------

dynamic_sql_cache_size 将取决于通过DSI（" Duh，Mark！"？）发出的不同命令的数量，因此可能必须根据与动态关联的各种SRS计数器进行调整。 sql： DSINoDsql * ， DSIEDsql * 和 DSIENoDsql * 计数器。

是的， MRU 肯定比 fixed 好。

感谢您的回答。

仅供参考，我正在从ASE 15.5迁移到16的环境中。我们有一些用于数据库复制定义/预订的主数据库，其中数据库复制了许多大的varbinary字段。 我们最近注意到，较大的varbinary值已包含在复制事务的" where"子句中。 即，在没有特定于表的repdef的情况下，repserver（15.7）不会自动为表找出正确的主键。

事实证明，您需要ASE服务器的ASE 16主数据库才能自动找出数据库repdef中表的主键。 更糟糕的是，在复制服务器上，语句高速缓存自动文字参数功能没有参数化varbinary文字，从而导致要缓存的大型SQL语句（包括where子句中的巨大varbinary文字）

我们还遇到以下问题：常规DSI订阅复制连接（针对具有2个字段的聚集索引的表运行简单的update语句）有时决定不使用索引进行更新（这是针对大表的）。 这些表扫描更新实质上导致复制挂起（每2-3周）。 当我们关闭语句缓存时，问题停止了。 因此，语句缓存暂时关闭。

因此，我将等到在主数据库上使用ASE 16之前，然后在订阅副本上重试语句缓存。 如果我们在语句缓存方面仍然遇到问题，也许我们将尝试使用repserver动态sql选项。