1. 死锁问题背景

做MySQL代码的深入分析也有些年头了，再加上自己10年左右的数据库内核研发经验，自认为对于MySQL/InnoDB的加锁实现了如指掌，正因如此，前段时间，还专门写了一篇洋洋洒洒的文章，专门分析MySQL的加锁实现细节：《MySQL加锁处理分析》。

但是，昨天”润洁”同学在《 …

   mysql的字符集设置有多个层级，在mysql中存储中文，如果不能正确设置字符集，很容易出现数据乱码。今天就有一个用户反馈他数据库中的数据下午1点多开始出现了乱码。在这里，我分享下具体问题的排查过程，以及解决的办法。

   (1)  排除客户端设置导致的显示乱码

   如果用户设置的mysql character_set_client跟客户端显示的字符集不一致，很容易导致中文数据乱码。

   设置session字符集为utf8：set names utf8，设置客户端显示字符集为utf8，然后从表中select出有乱码的数据。

  …

   前段时间，一大早上，就收到报警，警告php-fpm进程的数量超过阈值。最终发现是一条sql没用到索引，导致执行数据库查询慢了，最终导致php-fpm进程数增加。最终通过analyze table feed_comment_info_id_0000 命令更新了Cardinality ，才能再次用到索引。

   排查过程如下：

   sql语句：

select id from feed_comment_info_id_0000 where obj_id=101 and type=1;

   索引信息：

show index from feed_comment_info_id_0000
+---------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | …

mysql数据库在做查询时候，有时候是英文字母大小写敏感的，有时候又不是的，主要是由mysql的字符校验规则的设置决定的，通常默认是不支持的大小写字母敏感的。

1. 什么是字符集和校验规则？

字符集是一套符号和编码。校对规则是在字符集内用于比较字符的一套规则。任何一个给定的字符集至少有一个校对规则，它可能有几个校对规则。要想列出一个字符集的校对规则，使用SHOW COLLATION语句。

校对规则一般有这些特征：

• 两个不同的字符集不能有相同的校对规则。

• 每个字符集有一个默认校对规则。例如，utf8默认校对规则是utf8_general_ci。

• …

今天遇一个同学聊存储过程返回值经常得到意外的值为null, 因为白天有事，晚上给做一个实验放在这里供有相应问题的同学查看一下。
存储过程：

session 1执行：

   问题

   用户工单疑问：相同的语句，只是最后的limit行数不同。奇怪的是，limit 10 的性能比limit 100的语句还慢约10倍。

   隐藏用户表信息，语句及结果如下

   SELECT f1 , SUM(`f2`) `CNT` FROM T WHERE f1 IS NOT NULL AND f3 = ’2014-05-12′ GROUP BY f1 ORDER BY `CNT` DESC LIMIT 10;

   执行时间3 min 3.65 sec

   SELECT f1 , SUM(`f2`) `CNT` FROM T WHERE f1 IS NOT NULL AND f3 = ’2014-05-12′ GROUP BY f1 ORDER BY `CNT` DESC LIMIT 100;

   执行时间1.24Sec.

   性能差距非常大！

   分析

   MySQL Tips：追查语句执行时最常用的方法，是通过explain来看语句的执行计划。

  …

   背景

   MySQL全量逻辑备份恢复最基础的方法，就是mysqldump生成文本，再通过source 命令直接导入。一般用于实例迁移或者版本升级。

   这里说明最近碰到的一个失败例子。

   描述

   这个例子可以简要复现如下，在源库上执行如下操作:

   use mydb;

   create table t1 (id int);

   create view v1 as select * from t1;

   drop table t1;

   之后执行 mysqldump mydb，发现mysqldump中途退出。简化后出错原因很明显，就是视图v1对应的表t1已经不存在，这个视图本身非法。

  …

   收到一个mysql服务器负载告警，上去一看，load average都飙到280多了，用top一看，CPU跑到了336%，不过IO和内存的负载并不高，根据经验，应该又是一起索引引起的惨案了。

   看下processlist以及slow query情况，发现有一个SQL经常出现，执行计划中的扫描记录数看着还可以，单次执行耗时为0.07s，还不算太大。乍一看，可能不是它引发的，但出现频率实在太高，而且执行计划看起来也不够完美：

   mysql> explain SELECT count(1) FROM a , b WHERE a.id = b.video_id and b.state = 1 AND b.column_id = ’81′\G

   *************************** 1. row ***************************

   id: 1

   select_type: SIMPLE

   table: b

   type: index_merge

  …