MySQL长事务悲观锁_关于'长'事务中MYSQL行锁问题

在进行网站开发的时候，经常会遇到为了解决高并发而进行数据库锁问题，MYSQL数据库锁定方式总共分为 表锁、行锁、页锁

表锁 ： 在进行的时候将整个数据库表进行锁定，虽然时间短，但是期间会影响其他操作的速度；

页锁： 没有进行过研究，但是感觉应该是介于行锁与表锁之间，具体没有进行过测试

行锁： MYSQL中innoDB引擎才可以进行的操作，分为乐观锁与悲观锁，开销大，但是可以支持高并发。

这次业务所涉及的就是行锁。而因为业务要求所以选择了悲观锁，因为乐观锁在执行查询的时候不会有问题，问题会出在提交修改时候进行验证，而所涉及业务每次查询基本会进行修改，所以选择了悲观锁。

而选择行锁的原因是因为在锁定数据的同时不会影响其他在同一表内的类型数据进行阻塞。

悲观锁一定要在事务中处理才可以生效，而本次进行的事务处理需要很多处理，期间发现业务处理时间非常久，一个请求的时间竟然要达到5s-1min，下面是我分析的步骤

一、本以为是因为业务处理的数据库操作太多导致，此处业务进行的是递归处理，将一个记录信息直到无法处理为止，开始的时后每次都要进行大量的修改与插入操作，以为是因为此问题，开始进行优化

① 将所有插入操作统一进行插入。在原来每处插入的位置将要插入到数据库的记录插入到一个数组里面，在进行多个表插入的时候可以根据需求建立二维数组，然后处理完成进行数组返回，在进行统一插入。组织一条insert语句进行插入

② 将所有的修改操作简化。原本步骤涉及到自增自减的操作，而所带框架基本都是每次操作一个字段自增自减，所以决定自己组织语句进行操作，节省执行修改时间与次数，减少数据库压力。

③将所有查询提出递归。除非必要实时查询外，所有的查询操作都提出递归操作，传值方式进行操作。

二、将以上步骤操作完成之后发现时间并没有变短，所以判断应该不是数据库插入与修改所带来的时间损耗。然后百度查询发现行锁的缺点：当锁定数据的查询方式不是索引查询进行锁定的时候是范围锁定。甚至是进行表锁定。

①原本进行的查询是通过条件查询之后加FOR UPDATE进行锁定，解决办法，将查询条件加入索引，缩小行锁的锁定范围，如果查询条件无法进行索引查询，可以先查询出记录的ID。然后进行锁定查询。(此建议不知道靠不靠谱)

三、操作之后发现还是没有变快。之后查询了很久之后觉得一定是事务中的什么操作耽误了时间，导致事务提交时间变长。将数据锁定时间变长了。

①将事务中所有的处理提出事务，无法进行提出的重新设计合并为一次处理。

解决完之后发现速度确实提升了上来。得到的教训就是Redis操作虽然很快，但是也是循环操作的时候也会影响到性能。

本次问题解决完，发现自己对Redis的了解还是不够深。