请问有没有办法将SQL固定到内存缓冲区呢？

xzh2000

其实没有必要这样的,如果这个SQL经常被执行的话,
是不会被aged out的,如果频率很少,那被aged out是很正常的.

lwxxrq

多谢指点！
情况是这样的，来公司不久，已有的一个系统开发得很烂，所有sql都没有使用绑定变量，导致数据库执行sql时硬解析率很高，是系统性能差的一个重要因素（我这么认为）
现在领导下令必须优化，偶决心要让程序员们改程序了（使用绑定变量），偶在想，在程序员们修改程序期间及以后，为了突出某些常用模块的执行效率，也许将少部分sql钉在共享池是个好办法，毕竟程序员的修改很可能会出现修改不完整的情况，需要一个较长的过程。有时，只要一个糟糕的模块一运行下去，大量未使用绑定变量的sql就会立即将一些常用的、复杂的sql“挤”出去，对吧？希望在修改的一开始，就能让领导看到我们工作的“效果”

wlidflower

最初由 lwxxrq 发布
[B]多谢指点！
情况是这样的，来公司不久，已有的一个系统开发得很烂，所有sql都没有使用绑定变量，导致数据库执行sql时硬解析率很高，是系统性能差的一个重要因素（我这么认为）
现在领导下令必须优化，偶决心要让程序员们改程序了（使用绑定变量），偶在想，在程序员们修改程序期间及以后，为了突出某些常用模块的执行效率，也许将少部分sql钉在共享池是个好办法，毕竟程序员的修改很可能会出现修改不完整的情况，需要一个较长的过程。有时，只要一个糟糕的模块一运行下去，大量未使用绑定变量的sql就会立即将一些常用的、复杂的sql“挤”出去，对吧？希望在修改的一开始，就能让领导看到我们工作的“效果” [/B]

是个可以试试的方法
记得把效果告诉大家啊

xzh2000

最初由 lwxxrq 发布
[B]多谢指点！
情况是这样的，来公司不久，已有的一个系统开发得很烂，所有sql都没有使用绑定变量，导致数据库执行sql时硬解析率很高，是系统性能差的一个重要因素（我这么认为）
现在领导下令必须优化，偶决心要让程序员们改程序了（使用绑定变量），偶在想，在程序员们修改程序期间及以后，为了突出某些常用模块的执行效率，也许将少部分sql钉在共享池是个好办法，毕竟程序员的修改很可能会出现修改不完整的情况，需要一个较长的过程。有时，只要一个糟糕的模块一运行下去，大量未使用绑定变量的sql就会立即将一些常用的、复杂的sql“挤”出去，对吧？希望在修改的一开始，就能让领导看到我们工作的“效果” [/B]

其实绑定变量并不会对系统有很明显的提高,
SQL的parse只占SQL整个生命期的很小一部分,
如果你想试试,可以将cursor_sharing=force或similar来体验,
你可能会发现CPU的使用会有所下降,如果系统整体感觉
较慢的话,是不会改变的,所以进行系统调优/SQL优化是
主要的.