记一次MySQl Deadlock处理

线上数据库用户反映数据提交很慢，前端遮罩屏蔽处理一个在转，因而看了应用的log日志文件，出现几百kb的文件错误，仔细看应用在调用一个存储过程的抛出了

Deadlock found when trying to get lock

这个排除了应用的问题，因而着手到数据层面找缘由。

1.检查数据db引擎的状态status

经过登陆mysql服务器使用使用以下命令将db status重定向输出到指定的文件分析

mysql -e "show engine innodb status\G" -u[name] -p[password] [database] > /usr/local/status.txt

查看status.txt文件中的发现果真是存储过程的问题，文件sql语句让我很吃惊,什么鬼怎么后面会本身使用NAME_CONST而后还把编码转成utf8mb4。

ts.user_id =  NAME_CONST('userId',_utf8mb4'5ba51b22' COLLATE 'utf8mb4_general_ci')

而后我把语句拷贝加上explain查看执行计划，发现走了全表扫描，没有走user_id索引,若是NAME_CONST中的内容去掉，直接赋值id值，发现执行计划预估值只有20几行。应该是很快的。

这是开始检查user_id字段子表中的编码，发现是utf8并非utf8mb4,经过show variables查看数据库编码也是utf8。

//toggle
mysql> use xxx;
//character_set
mysql>show variables like 'character_set_database';

为何会出现强制改编码呢。其实也没遇到过这样的问题。也没有经验，这个时候不知道咋办了，只好打开google输入mysql procedure utf8mb4一篇快速浏览没有发现线索，点了第二编也是快速阅览，大概是来自stackoverflow,一个show procedure status忽然吸引到我，虽然提问者问题和个人问题并不同。我很好奇

这个命令到底展示啥。而后看到内容大体以下：

个人character_set_client和collation_connection的编码都是utf8而Database collation的编码是utf8mb4

//来自mysql官网
mysql> SHOW PROCEDURE STATUS\G
*************************** 1. row ***************************
                  Db: test
                Name: sp1
                Type: PROCEDURE
             Definer: testuser@localhost
            Modified: 2004-08-03 15:29:37
             Created: 2004-08-03 15:29:37
       Security_type: DEFINER
             Comment:
character_set_client: latin1
collation_connection: latin1_swedish_ci
  Database Collation: latin1_swedish_ci

我忽然想起了以前为了兼容表情把数据编码改为了utf8mb4，可是后来又把数据库改回了utf8,这时个人脑海里忽然以为存储过程的Database Collation的编码依赖于建立时数据库的编码和当前的编码无关，因而快速的从新建立一个存储过程覆盖原来的存储过程，再用show procedure status like 'xxx' \G查看，发现编码已经修改。

结论：在改变数据库编码后须要使用show xxx status命令检查以前建立的表、存储过程、触发器、函数的编码是否与当前一致，不然作相应的编码修改。对dead lock通常都是因为数据变动数据时没有走索引致使innodb引擎出现锁整个表记录而出现了资源争用