批量锁（适用各种关系型数据库）

自己原文公众号： https://mp.weixin.qq.com/s/3zyXC0oJtMV2hEZ6v_e2pg    一次处理Oracle问题。看到AWR已经这样了。说明后台属于惨不忍睹。 其实每个数据库都应该有这么一个类似AWR的才好判断。迄今为止PG上国内瀚高做了一个类似的，连界面样式都雷同AWR，是比较好的。希望有一天MySQL官方也出一个AWR。      原因我这里不贴数据了，结论是锁导致的。分析下来是批量锁造成的。首先说明一下数据库不怕并发，一般来说主流数据库并发处理一行保守估计每秒100次是没有问题的。仅仅这个数据库而言在发生问题的时段另外一个表每秒执行了2万次的更新。所以不是数据库问题，而是表和SQL的问题。     既然同一个数据库每秒能执行这么多，怎么会锁？这就说说场景了，一般来说就像我们12306，有人买上海到北京的，有人买北京到广州等等，都能分散。也有一等、二等座等等。每次我们每人只买一个。但是也有人报一节车厢。所以就分为单买和团购两种。单买并发多，每个也快。团购这种少，团购一次性上百张，会多花一点时间。但是不太可能有并发团购的场景。就像我们查一条数据很快，查几年的报表就会慢一点。但是没人会批量并发出报表吧？      而事实就是发生了，我见过报表有并发出的场景。（不合理吧？但是就是有）所以并发批量团购（并发批量改也一样是可能的）     这个很好重现，上数据。这个表有100万数据，查询一下50毫秒。（因为就2列，但是即使列多在亿级别这都不叫事），其实无论MySQL和PG单表也是可以的。 执行一个批量改的存储过程，模拟批量团购。 5秒完成10万行记录的更新。 所以一秒2万行的更新是轻松的，也是做得到的。 接下来并发团购模拟一下（尽管这种不合理） 可以看出一个是5秒（没变化），另外一个是8秒，多了3秒。这个多的就是在等第一个批量执行完成。      也就是说如果多几个乃至几十个批量更新，越在后面的执行时间越长，因为她要等在她之前的所有批量执行完毕。这都是锁等待。就我复现的场景而言，如果并发的间隔控制在5秒以上还能满足的这个不合理的场景。