想让DB2并发跑得快点，这些方法你可能没全用上

想让DB2并发跑得快点,这些方法你可能没全用上 基于IBM官方文档、DB2信息中心技术文章、资深DBA实践经验总结）

想让你的DB2数据库在处理很多人同时访问、同时干活的时候，不再卡顿，像高速公路一样保持畅通吗？光知道增加硬件可能成本太高，其实有很多不花钱或者少花钱的招数，你可能还没全部尝试过，下面这些方法，都是从实际经验中提炼出来的，咱们一个一个说。

第一招：别让锁成了“拦路虎”——锁相关的调优

DB2用锁来保证大家同时改数据不会乱套,但锁用不好就成了最大的瓶颈，很多人可能只设置了默认参数，没深究。

• 认清锁的本质和尺寸：DB2里的锁是有大小的，比如行锁、表锁，默认是行锁，这挺好，但有时候会发生一种情况：一条SQL语句要更新很多行，结果锁的数量超过了数据库的限制（这个限制由一个叫LOCKLIST的参数控制），DB2为了“自保”，就会把行锁升级成表锁，你想想，一个表被锁住了，其他人就都得等着，并发立刻完蛋，你要做的首先是监视有没有锁升级发生，通过DB2的监控工具（比如db2pd -locks命令或者监控表函数）可以看得到，一旦发现锁升级，解决办法通常是适当增大LOCKLIST和MAXLOCKS这两个参数，给锁更多的内存空间，让它没必要“小事闹大”。
• 试试“当前提交”这个法宝：这是DB2一个挺厉害但可能被你忽略的功能，默认情况下，如果一个事务在读数据，而另一个事务正在修改它还没提交，读的人会等（或者读到最后提交的旧版本，取决于隔离级别），这也会引起等待，从DB2 9.7版本开始，引入了“当前提交”（Currently Committed）的特性，开启它之后，读操作会智能地绕过那些未提交的修改，直接读取最近已经提交的数据版本，大大减少了读和写之间的互相等待，这个功能在很多场景下能显著提升并发读的性能，而且配置起来相对简单（通过注册变量DB2_EVALUNCOMMITTED和DB2_SKIPDELETED等，或直接设置隔离级别为CS WITH CS），你值得去查查你的环境是否已经用上了。

第二招：让数据各就各位——表和索引的摆放艺术

数据在磁盘上怎么放,直接影响同时读取它们的效率。

• 表空间容器要分散开：DB2的数据是放在表空间里的，表空间下面有具体的文件或设备，叫容器，如果把所有容器都放在同一个物理硬盘上，那么很多会话同时要读数据时，就会挤在这个硬盘的磁头前排队，形成I/O瓶颈，正确的做法是把表空间的容器分散到多个不同的、独立的物理硬盘或者RAID组上，DB2会自动把数据均衡地分布到这些容器上，这样当并发访问来时，负载就被分摊到多个磁盘臂上，并行读取，速度自然就上去了，这比你把所有钱花在买一块超级快的SSD上，可能效果更划算、更均衡。
• 索引不仅是加速器，也是并发助手：大家都知道索引能加快查询，但合适的索引也能减少锁的竞争，一个经常被并发更新的表，如果更新条件（WHERE子句）能通过索引快速精准定位到某一行，那么DB2加锁的时间就会非常短，锁住的范围也小（就是那一行），其他会话受影响的程度就低，反之，如果每次更新都来个全表扫描，扫描过程中可能会挂上一堆锁，很容易就引发冲突，审视你的高频并发事务SQL，为它们设计高效的索引，是一举两得的好事。

第三招：调整数据库的“发动机”参数——内存和配置

DB2有一些关键的配置参数,像是发动机的油门和变速箱，调好了动力输出才顺畅。

• 缓冲池是重中之重：缓冲池就是数据库的内存缓存，数据从磁盘读出来先放这里，如果缓冲池太小，数据刚被用过就被挤出去了，下次要用又得去慢吞吞的磁盘读，这叫缓冲池命中率低，并发量一大，这种磁盘I/O的等待会非常明显，用db2mtrk工具或者监控快照可以很容易看到缓冲池的命中率，理想情况应该在95%以上，如果低了，别犹豫，适当增大对应表空间的缓冲池大小（IBMDEFAULTBP是默认的），把热数据尽量留在内存里，是提升并发响应速度最有效的手段之一。
• 日志缓冲区也别忽视：所有数据修改都要先写日志，DB0有个日志缓冲区，事务修改数据时，日志记录先写在这个内存区域，再批量刷到磁盘日志文件里，如果这个缓冲区太小，事务就不得不频繁地等待日志记录被写到磁盘上（这叫日志满等待），增大LOGBUFSZ参数，可以让更多日志操作在内存中完成，减少这种I/O等待，让提交操作更快完成，从而释放锁资源。
• 调整最大并发应用程序数：DB2有个参数叫MAXAPPLS，它限制了能同时连接到数据库的最大应用数，如果这个值设得太低，当并发用户超过限制时，新的连接请求就会被拒绝，根本谈不上性能优化，你需要根据实际业务高峰期的连接数，把这个值设到一个合理的安全范围，关联的参数如MAXAGENTS（最大代理进程数）也要协调设置，确保有足够的工作线程为并发请求服务。

第四招：从源头优化——审视应用程序本身

数据库再优化,如果应用程序写得不好，也是白搭。

• 提交的频率要拿捏好：有些程序喜欢在一个事务里做非常多的事情，长时间不提交，这意味着这个事务持有的锁会一直不释放，像个路霸一样堵着后面所有人，在业务允许的前提下，尽量让事务短小精悍，快进快出，做完必要的修改立刻提交，这能极大地减少锁的持有时间，提升整体并发度。
• 避免长事务和死锁的写法：如果业务逻辑复杂，事务确实不能太短，那就要特别注意访问数据的顺序，多个并发事务如果总是以不同的顺序来更新A表和B表，就很容易形成死锁（互相等待），约定一个固定的顺序（比如都先更新A再更新B）可以避免大部分死锁，尽量使用绑定变量，避免即席查询（ad-hoc），这不仅能减少SQL编译开销，也让数据库的执行计划更稳定，间接有利于并发稳定性。

总结一下

提升DB2的并发性能是一个系统工程,不是单靠某一个“银弹”，你需要从锁机制、物理存储、内存配置和应用设计四个层面综合检查，先从监控入手（DB2监控工具、快照、事件监视器是你的好朋友），找到真正的瓶颈所在（是锁等得多？还是I/O慢？还是CPU高？），然后再有针对性地采取上述措施，很多时候，一些简单的参数调整或者索引添加，就能带来意想不到的效果，别怕动手尝试（当然生产环境要谨慎），持续观察和调整，你的DB2数据库就能在并发压力下表现得更稳健、更快速。