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中匹配字符串的宿主变量了。
也就是说，将终端得到的数据变成形如"%*******%%%%%%%%%%"这样的匹配字符串，用于数据库的查询。这样，就可以成功的实现查询数据库中该项包含"******"字符串的所有项。
相关文档：
如何让你的SQL运行得更快
---- 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、 ......
作中数据库经常出错死锁，并且还要要求解决当前的死锁，问题多多；
参照CSDN，中国风(Roy)一篇死锁文章并改进了下；
/***********************************************************************************************************************
整理人：黑木崖上的蜗牛(lenolotus) 日期:2009.04.28
************ ......
今天做SQL 优化，查找执行计划时，执行计划，发现此执行计划与以往的计划有所区别；找录互联网，终于找一篇有关研究比较深入的文章；
原执行计划使用的是索引扫描，突然一下会使用索引覆盖技术，效率大增；
SELECT * 的真相：索引覆盖(index coverage)
SELECT *的效率很糟糕吗？当然，所有人都知道这一点，但是为什么 ......
先说说这些误区。所谓“误区”，有一些是新手很容易犯的错误或者很容易忽略的问题，另外一些，则是像“耗子吃了盐会变成蝙蝠”一样，让我们从小就认为是正确的事情。如下：
1、 表上不管用得着用不着，都加个聚集索引。
我们知道，表以两种方式组织物理存储：有聚集索引的“聚集� ......
