「MySQL高级篇」MySQL锁机制 && 事务( 五 )


  • Innodb_row_lock_waits: 系统启动后到现在总共等待的次数
  • 当等待的次数很高,而且每次等待的时长也不小的时候,我们就需要分析系统中为什么会有如此多的等待,然后根据分析结果着手制定优化计划 。
    总结InnoDB存储引擎由于实现了行级锁定,虽然在锁定机制的实现方面带来了性能损耗可能比表锁会更高一些,但是在整体并发处理能力方面要远远高于MyISAM的表锁的 。当系统并发量较高的时候,InnoDB的整体性能和MyISAM相比就会有比较明显的优势 。
    但是,InnoDB的行级锁同样也有其脆弱的一面,当我们使用不当的时候,可能会让InnoDB的整体性能表现不仅不能比MyISAM高,甚至可能会更差 。
    优化建议
    • 尽可能让所有数据检索都能通过索引来完成,避免无索引行锁升级为表锁 。
    • 合理设计索引,尽量缩小锁的范围 。
    • 尽可能减少索引条件,及索引范围,避免间隙锁 。
    • 尽量控制事务大小,减少锁定资源量和时间长度 。
    • 尽可使用低级别事务隔离(但是需要业务层面满足需求)
    表级锁扩展全局锁
    「MySQL高级篇」MySQL锁机制 && 事务

    文章插图
    特点
    「MySQL高级篇」MySQL锁机制 && 事务

    文章插图
    备份的一致性问题来看下边这个场景,比如我们创建的购买操作,涉及到了用户余额表+订单表,流程顺序如下:
    1. 当前正在备份用户余额表,备份了小明同学的余额是100
    2. 此时小明刚好下了订单,理应扣减50元
      1. 但由于用户余额表已经备份完毕,余额表不会受到影响
    3. 小明下好单了,如今来备份订单表了,能够备份到小明刚下的单
    到这里是否发现问题了,就是备份后的结果是:小明的余额没扣钱,但却有相关的订单数据,出现了数据不一致的情况