数据库中的热点问题

---

热点是应用中常见的问题之一。在系统并发量比较小的时候，通常感觉不到它的存在，而当并发请求急剧增加的时候，响应时间被大大地拉长，极端情况系统挂起。

热点可能在记录上，可能在数据或索引页面上，也可能在其它对象上，比如缓冲池、程序包，甚至到数据库之下的操作系统层。常见的是前两种。

典型的记录热点场景有：应用维护流水号，或者余额控制，相关信息保存在用户表的记录中，每次交易都作UPDATE操作。UPDATE会在记录上加独占锁，会堵塞其它应用对同一条记录的UPDATE操作，这个独占锁要等整个事务提交或回滚后才会释放。假设这个事务执行时间是10毫秒，那么这个系统能支撑的最大交易吞吐量是100笔/秒，更多的交易请求进来将处于等待状态。

如何能够知道系统存在这种热点问题？ 如果做数据库监测的话，可关注并发应用数、应用等锁次数和平均锁等待时间，

如果等锁次数及等待时间随应用并发增加而增加的话，很有可能存在这种问题。

也有可能你的系统负载一直不高，看不到上述变化，又怎么能知道系统有这种风险？

在DB2中可用命令db2pd –db -tcbstats获取表相关的操作信息，在“TCB Table Stats:”段内容中有表上发生UPDATE的次数，用次数除以表的记录数，可计算出平均每行记录被更新的次数，如果某表上这个指标较高，意味着可能有热点记录问题。当然这个办法不一定很准确，比如表中有很多条记录，其中一条或几条被更新的次数远高于其它，便不能用这种方法识别出来，更准确的方法是捕捉到每一条SQL语句，分析UPDATE操作指向的记录。 预先知道隐含问题，就可以改进系统，避免出现类似“双十一”或“秒杀”活动对系统带来的冲击。

改进方法就是去除热点或分散热点。比如可用数据库的SEQUENCE帮助产生流水号，数据库的SEQUENCE可在内存一次产生多个流水号，个数由CACHE指定，并发高的系统可加大CACHE；分散热点是将一条记录拆成多条记录，根据传入参数更新对应记录。

除记录热点外，还有可能出现数据页面或索引页面热点。比如多条记录保存在同一个数据页面，虽然并发应用更新的是不同记录，但数据库内部在更新数据页面内容时会加LATCH以避免内容错乱，用一般的数据库监控可能不能发现此类问题，使用db2pd -latch有可能看到冲突。解决办法是减少同一个数据页面内保存的记录数，比如(ALTERTABLE myTable PCTFREE 90; REORG TABLE myTable)，重组之后每个页面只用10%的空间保存记录。当然你也可能有其它方法达到此目的。

索引页面的热点主要发生在索引字段内容一直增加或减少的情况，比如时间戳或流水号上的索引，每次INSERT进来的记录，其相关索引内容都落在最后的索引页面中，这在单服务器的数据库中可能没太大问题，但在集群环境中，这个热点问题会被放大。DB2中有一种RANDOM INDEX可规避这个问题，比如：CREATEINDEX myIdx ON myTable (seqno RANDOM)；RANDOMINDEX是基于变换后的内容构建索引，因此它失去了原来的顺序，避免了索引页面热点，但只适合“=”条件查询，BETWEEN及“>”之类查询条件不能从这种索引中得到原来的好处。

如果能在设计开发阶段就考虑到些热点问题，避开它，就更好了。

如果您碰到其它一些热点问题，也可以拿出来跟大家分享一下。

慧都控件网年终促销第一波已开启，全场6折起，豪礼抢不停>>>

截止时间：2016年10月30日

详情请咨询！

客服热线：023-66090381