写DB2程序的时候，有哪些实用又容易忽略的操作技巧呢？

写DB2程序的时候，有些小技巧就像工具箱里的隐藏工具，平时可能想不起来用，但一旦用上，能省不少力气，还能让程序更结实，这些技巧往往不是教科书里的核心知识点,而是老程序员们在日常摸爬滚打中攒下来的经验。

第一，多用“WITH UR”来图个清静。 这是个特别简单却极其有效的技巧，我们在写SELECT语句时，DB2为了保证数据的一致性（也就是不让别人在你读数据的时候修改数据），默认会加一些锁，这在复杂交易里是必要的，但如果你只是单纯地想查询一下数据，比如生成一个报表或者做个数据检查，根本不在乎在你读的这一瞬间数据有没有被别人改掉，那这些锁就成了负担，它会降低速度，严重时还可能和别人正在进行的操作“撞车”，导致等待甚至死锁，这时候，在SQL语句的末尾加上 WITH UR(Uncommitted Read)，就等于告诉DB2：“我就要读一下，不管别人改没改，哪怕读到的是还没最终确认的数据也行，你快点儿给我结果就好。” 这样一来，DB2就不会去加那些麻烦的锁，查询速度会快很多，也避免了不必要的锁冲突，这个技巧在报表程序、数据抽取程序里尤其好用，但很多新手会忽略这个选项，一直忍受着默认设置带来的性能损耗。（来源：DB2 SQL性能优化相关实践指南）

第二，养成检查SQL返回码的“强迫症”。 很多人在程序里嵌入SQL语句，执行完就以为万事大吉了，但其实，几乎每一条SQL语句执行后，DB2都会返回一个状态码，叫做SQLCODE，如果SQLCODE是0，代表成功；是正数，代表成功但带有警告（比如没找到数据）；是负数，那就代表出错了，一个非常常见的疏忽是，只检查了错误（负数），却忽略了警告（正数），最典型的例子是，当你用SELECT ... INTO语句期望取一条数据时，如果一条都没找到，SQLCODE会是+100，这不算错误，程序会继续往下跑，但如果你后面的逻辑默认已经取到数据了，那就会用到一些空值或旧值，导致结果完全不对，严谨的做法是，在每一条可执行的SQL语句之后，立刻检查SQLCODE，不仅要处理错误情况，也要对关键的警告情况（100“未找到”）进行妥善处理，这个习惯看似繁琐，却是写出健壮、稳定程序的基础，能避免很多莫名其妙的bug。（来源：DB2应用程序开发基础教程）

第三，游标用完后一定要记得“关门”。 当我们需要在程序里一条一条处理数据时，就会用到游标（Cursor），流程一般是：声明游标、打开游标、循环读取数据、关闭游标，很多人会记得打开和读取，但有时会忘记显式地关闭游标，以为程序结束就自动关了，这是个坏习惯，因为游标会占用数据库资源，如果不及时关闭，尤其是在循环或频繁调用的程序里，可能会很快耗尽数据库的连接资源或锁资源，导致程序崩溃或性能急剧下降，正确的做法是，把关闭游标的操作放在异常处理的最后环节，确保无论程序是正常跑完还是中途出错，游标都能被安全地关闭，这就好比离开房间要关灯，不能总指望物业给你拉闸。（来源：数据库编程最佳实践）

第四，试试“MERGE”语句，一招顶好几招。 我们经常遇到一种业务场景：判断一条数据在表里存不存在，如果存在就更新它，如果不存在就插入一条新的，传统的做法是先执行一条SELECT看看，然后根据结果决定是执行UPDATE还是INSERT，这需要写不少代码，而且和数据库要通讯两次，DB2提供了一个强大的MERGE语句（有时也叫UPSERT），能把这个逻辑一次性完成，你只需要告诉DB2匹配的条件，以及匹配上怎么更新，匹配不上怎么插入，一条语句就搞定了，这样做不仅代码简洁，而且因为减少了与数据库的交互次数，性能也更高，这个功能虽然强大，但因为它出现得相对晚一些，很多习惯老方法的程序员还是会不自觉地用那种“先查后改”的繁琐方式。（来源：DB2高级SQL功能应用）

第五，重视“字段列表”，告别“SELECT *”的坏习惯。* 为了图省事，很多人写查询直接写SELECT ，意思是把表里所有字段都拿出来，在程序开发阶段，这看起来很方便，因为表结构怎么变，我的程序好像都不用改，但这其实是个陷阱，性能差，你明明只需要三四个字段，却把几十个字段的数据都搬过来，网络传输和程序处理的负担都加重了，也是更容易被忽略的，是程序的不稳定性，一旦表结构发生变化，比如增加了一个你程序处理不了的大字段（如CLOB），或者字段顺序变了，你的程序可能就会莫名其妙地出错，最好的习惯是永远显式地写出你需要的那几个字段名**，这样，程序意图清晰，性能最优，而且表结构做不影响你所需字段的变更时，你的程序也无需修改，反而更稳定。（来源：企业级数据库编程规范）

第六， EXPLAIN PLAN功能是你的“免费诊断医生”。 你写的SQL语句逻辑上完全正确，但跑起来就是慢得要死，这时候，别急着怪罪数据库，可以先请出EXPLAIN PLAN工具来看看，这个工具能帮你看到DB2会如何执行你的SQL语句，比如它准备用哪个索引、要不要排序、表之间怎么连接等，虽然看它的输出结果需要学习一下，但即使只是看个大概，你也能发现一些明显的问题，比如数据库被迫进行全表扫描（像在图书馆里从第一本书开始找一句话，而不是查目录）而不是使用索引，通过分析执行计划，你可以有针对性地去创建索引或修改SQL语句，往往能起到立竿见影的优化效果，这个强大的工具就摆在那里，但很多开发者只有在遇到严重性能问题时才会想起它，其实在开发阶段对核心SQL做一下检查，能提前避免很多性能坑。（来源：DB2性能调优实战经验总结）

这些技巧都不是什么高深莫测的理论，而是体现在细节处的良好习惯，多用“WITH UR”求速度，勤查SQLCODE保稳定，游标用完即关省资源，巧用MERGE语句简化逻辑，指定字段列表提升效率和韧性，善用EXPLAIN PLAN预判性能，把这些融入到日常开发中，就能写出更高效、更可靠的DB2程序。