cobol写sql命令
SQL中WHERE子句中可以利用LIKE来匹配相似的数据项，当时我得到的结论是可以使用"%"来匹配字符串，在SPUFI中使用，的确可以得到字符串匹配的效果。如：
SELECT * from TEST
WHERE TESTID LIKE "CZX%";
上面这句在SPUFI中提交执行后，就可以将TEST表中所有TESTID中所有以"CZX"字符串开头的项都找到。
然而，在COBOL中执行嵌入的SQL语句的时候，"%"就只能匹配一个或空的字符了，如：
EXEC SQL
SELECT * from TEST
WHERE TESTID LIKE "CZX%"
END-EXEC.
就只能查询出以"CZX"开头的且最后长度不超过4的项。
一开始的时候我并没有注意到这个问题，因此，在匹配字符串的时候，老是查询不到预期的数据。当我最终发现这个问题的时候，也没找到该用什么符号来匹配字符串，最后，想了一个利用"%"来完成字符串匹配的方法：
1、声明一个字符串匹配的变量，长度为数据库中要匹配项长度+2，如：TESTID-FILTER全部存放"%"；
2、将从终端获得的筛选字符串,如TESTID-INPUT去掉空格后，插入到1中定义的变量的第二位；
3、得到字符串TESTID-FILTER就是用在LIKE中匹配字符串的宿主变量了。
也就是说，将终端得到的数据变成形如"%*******%%%%%%%%%%"这样的匹配字符串，用于数据库的查询。这样，就可以成功的实现查询数据库中该项包含"******"字符串的所有项。
相关文档：
作中数据库经常出错死锁，并且还要要求解决当前的死锁，问题多多；
参照CSDN，中国风(Roy)一篇死锁文章并改进了下；
/***********************************************************************************************************************
整理人：黑木崖上的蜗牛(lenolotus) 日期:2009.04.28
************ ......
今天做SQL 优化，查找执行计划时，执行计划，发现此执行计划与以往的计划有所区别；找录互联网，终于找一篇有关研究比较深入的文章；
原执行计划使用的是索引扫描，突然一下会使用索引覆盖技术，效率大增；
SELECT * 的真相：索引覆盖(index coverage)
SELECT *的效率很糟糕吗？当然，所有人都知道这一点，但是为什么 ......
我们先看 NestedLoop 和 MergeJoin 的算法（以下为引用，见 RicCC 的《 通往性能优化的天堂 - 地狱 JOIN 方法说明 》 ):
==================================
NestedLoop:
foreach rowA in tableA where tableA.col2=?
{
search rowsB from tableB where tableB.c ......
上回我们说到评估一条语句执行效率主要看逻辑 IO （啥是逻辑 IO ，啥是物理 IO 见联机文档），这次我们继续。
我们先说说，返回多行结果时，为什么 SQLServer 有时会选择 index seek ，有时会选择 index scan 。
以 nonclustered index 为例说明。
像所有的索引 B 树一样，非聚集索引树也包括完全由索引数据组成的根� ......
◆1.DBCC CacheStats ：显示存在于当前 buffer Cache 中的对象的信息，例如 ：hitrates 编译的对象和执行计划
DBCC CACHESTATS
从这个命令可以得到一些关键的统计信息：
Hit Ratio：显示特定对象可以在Sql Server的缓存中被命中的百分比，这个数值越大，越好
Object Count：显 ......
