比来线上 MySQL 接连产生了几起数据异常，都是在凌晨爆发，因为营业场景属于典范的数据仓库型应用，日间压力较小无法复现。甚职苄些异常还比较诡异，最后 root cause 分析颇费周折。那实际营业傍边咱们若何能快速的定位线上 MySQL 问题，修复异常呢？下文我会根据两个实际 case，分享下相干的经验与办法。

MySQL

1、Case1：部分数据更新掉败

某天渠道同窗反馈某报表极个别渠道数据为 0，大年夜部分渠道数据正常。这个数据是由一个统计法度榜样天天凌晨例行更新的，按理来说，要么全部正常，要么全部掉败，那会是什么原因导致极个别数据异常呢？

起首我们能想到的天然是根据统计义务日记来看了，然则看了统计法度榜样打印的日记没有发明诸如 SQL update 掉败的异常描述，那当时的数据库毕竟产生了什么呢？在查看 MySQL-server 日记之前，习惯性的看了下数据库状况：

SHOW ENGINE INNODB STATUS\G

恰好看到了凌晨这个 update 产生了逝世锁：

------------------------LATEST DETECTED DEADLOCK------------------------2017-07-17 04:09:01 0x7f6de03c8700*** (1) TRANSACTION:TRANSACTION 215208479, ACTIVE 0 sec fetching rowsmysql tables in use 3, locked 3LOCK WAIT 5 lock struct(s), heap size 1136, 3 row lock(s)MySQL thread id 27844824, OS thread handle 140092183037696, query id 412503674 10.126.95.84 zeye Searching rows for updateupdate t_channel_final_datas set nr_register=133,nr_add_goods=29,nr_order_normal=11,nr_pay_normal=8,nr_order_special=0,nr_pay_special=0,n_add_user_num=16 where count_date='2017-07-16' and channel_id='16' and channel_type='10' and terminal='26'*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 464 page no 5459 n bits 392 index index_countdate_type_terminal of table `db_zz_flow`.`t_channel_final_datas` trx id 215208479 lock_mode X locks rec but not gap waitingRecord lock, heap no 304 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 10; hex 323031372d30372d3136; asc 2017-07-16;; 1: len 1; hex 30; asc 0;; 2: len 4; hex 80000010; asc     ;; 3: len 4; hex 8009055e; asc    ^;;*** (2) TRANSACTION:TRANSACTION 215208474, ACTIVE 0 sec fetching rowsmysql tables in use 3, locked 36 lock struct(s), heap size 1136, 7 row lock(s)MySQL thread id 27844825, OS thread handle 140109890225920, query id 412503669 10.135.6.41 zeye Searching rows for updateupdate t_channel_final_datas set nr_register=24,nr_add_goods=32,nr_order_normal=0,nr_pay_normal=0,nr_order_special=0,nr_pay_special=0,n_add_user_num=11 where count_date='2017-07-16' and channel_id='114' and channel_type='10' and terminal='116'*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 464 page no 5459 n bits 392 index index_countdate_type_terminal of table `db_zz_flow`.`t_channel_final_datas` trx id 215208474 lock_mode X locks rec but not gapRecord lock, heap no 304 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 10; hex 323031372d30372d3136; asc 2017-07-16;; 1: len 1; hex 30; asc 0;; 2: len 4; hex 80000010; asc     ;; 3: len 4; hex 8009055e; asc    ^;;...*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 464 page no 4743 n bits 264 index PRIMARY of table `db_zz_flow`.`t_channel_final_datas` trx id 215208474 lock_mode X locks rec but not gap waitingRecord lock, heap no 168 PHYSICAL RECORD: n_fields 32; compact format; info bits 0 0: len 4; hex 80090569; asc    i;; 1: len 6; hex 00000cd3b9d0; asc       ;;...*** WE ROLL BACK TRANSACTION (1)

/usr/sbin/mysqld, Version: 5.7.12-log (MySQL Community Server (GPL)). started with:Tcp port: 3306 Unix socket: /opt/data/mysql/mysql.sockTime Id Command Argument2017-07-20T21:45:01.880828Z28556028 Quit2017-07-20T21:45:02.708621Z28401469 Query SELECT 12017-07-20T21:45:02.736734Z28556029 Connect ooxx@127.0.0.1>

3、MySQL 日记分析脚本

篇幅所限，高低文我这里省略了很多，大年夜这段日记里可以看到，TRANSACTION 1 和 TRANSACTION 2 分别持有必定命量的行锁，然后又等待对方的锁，最后 MySQL 检测到 deadlock ，然后选择回滚了 TRANSACTION 1：Innodb今朝处理逝世锁的办法是将持有起码行级排他锁的事务进行回滚。

那这里就有 3 个问题了：

（1）innodb 行锁不是只锁一行？

因为这张表是 innodb 引擎的，InnoDB 支撑行锁和表锁。而InnoDB行锁是经由过程给索引上的索引项加锁来实现的，这一点MySQL与Oracle不合，后者是经由过程在数据块中对响应数据行加锁来实现的。InnoDB这种行锁实现特自得味着：只有经由过程索引前提检索数据，InnoDB才应用行级锁，不然，InnoDB将应用表锁，会把所有扫描过的行都锁定！在实际应用中，要特别留意InnoDB行锁的┞封一特点，不然的话，可能导致大年夜量的锁冲突，大年夜而影响并发机能。因为MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以固然是拜访不合行的记录，然则如不雅是应用雷同的索引键，是会出现锁冲突的。当我们用范围前提而不是相等前提检索数据，并请求共享或排他锁时，InnoDB会给相符前提的已稀有据记录的索引项加锁；别的间隙锁也会锁多行，InnoDB除了经由过程范围前提加锁时应用间隙锁外，如不雅应用相等前提请求给一个不存在的记录加锁，InnoDB也会应用间隙锁！

1/4 1 2 3 4 下一页尾页

　　推荐阅读

　　厉害了！崇礼环卫率先迈入数字化时代

环卫工人清洗垃圾桶清扫保洁二组，收到请答复?”“保洁二组收到。”“娱乐中间有大年夜片的烟头，垃圾桶外有裸露的垃圾，通知该组保洁人员尽快处理。”7月21日上>>>详细阅读

本文标题：MySQL死锁与日志相关经验分享

地址：http://www.17bianji.com/lsqh/36448.html

1/2 1