Ad-hoc 查询以及动态SQL的罪恶[译]
前言
在硬件资源非常有限的SQLServer服务器上进行开发，有一大优势，就是错误是可视化的，即你很快就会因为你的错误而受到惩罚。譬如，应用中过多使用ad-hoc动态查询的产生的问题会很快暴露出来。开发者可能会向你抱怨，数据库运行的越来越慢。你也将会发现服务器CPU的使用率非常高，甚至接近100%，但是在性能较差的时段，却没有阻塞的发生。
在极端的情况下，你甚至可能接受到如下的错误：
Error: 701, Severity: 17, State: 1
There is insufficient system memory to run this query.
或者
Msg 8645, Level 17, State 1, Procedure , Line 1
A time out occurred while waiting for memory resources to execute the query. Re-run the query.
分析
你会发现运行过多的ad-hoc查询所有造成的不良影响。CPU利用率高是因为查询优化器需要编译大量的ad-hoc查询。内存压力是因为一些内存用来缓存ad-hoc查询生成的执行计划。换句话说，开发者使用了Ad-hoc查询，而不是使用存储过程或者参数化的查询。这是非常愚蠢的。
一个编译好的执行计划大约占用70KB的空间，而一个存储过程的执行计划，根据其复杂度，大约占用2到3倍的空间。区别是每个存储过程只有一个执行计划。使用Ad-hoc查询，你将冒着每个查询都有一个单独的执行计划的风险。
执行计划缓存起来是为了被重用的，SQLServer需要占用内存来存储执行计划，这部分内存按照申请方式称为StolenPages。其他占用StolenPages的对象包括了Connections、Locks 和 Transaction Context等一些内存Consumer以及线程和第三方代码消耗的内存。这是一个简单的日常任务分配内存的方式，但是当数据库接受到非常多的Ad-hoc查询时，将会产生麻烦。除非SQLServer可以确定查询可以自动的参数化或者说新的查询和已缓存的查询一致，否则SQLServer就会重新生成一个执行计划。可能不长时间，你就会看到数据缓存产生瓶颈
那么如何确定系统是否存在这种问题
1. 检查编译查询计划的数量。SQLServer性能监视器将会显示 SQL Compilations/sec 有比较高的数值。理论上，SQL Recompilations/sec 和 Batch Requests/sec 的比率应该会非常低
2. DBCC MemoryStatus 也会显示出stolen pages的数量会上升
确定问题后，如何解决
1. 使用存储过程来执行
2. 使用参数化查询
实例演示 略 具体见原网址
如有不对的地方，欢迎拍砖，谢谢！O(∩_∩)O
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
