持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第28天，点击查看活动详情

获取当前系统各个事务的加锁信息

show engine innodb status;
select * from information_schema.INNODB_LOCKS;

死锁分析步骤

如果发生死锁了，我们应该如何分析呢？

可以从这四个步骤入手：

show engine innodb status，查看最近一次死锁日志。
分析死锁日志，找到关键词TRANSACTION
分析死锁日志，查看正在执行的SQL
看它持有什么锁，等待什么锁。

sql优化思路

索引失效场景

1、最左前缀原则

符合索引(a,b,c)的索引组合有a、a b和a b c三种组合；如果索引是复合索引，要遵守最左前缀原则。指的是查询要从索引的最左前列开始并且不跳过索引中的列。

eg:复合索引（username + password + age）查询条件最左侧username缺少，违反了最左前缀原则，导致索引失效，全表扫描。
2、计算、函数、类型转换(自动或手动)导致索引失效，全表扫描。
3、范围【< ,> between and】条件右边的列索引失效。eg：id>20导致右边索引失效。
4、不等于(!= 或者<>)导致索引失效。
5、is null可以使用索引，is not null无法使用索引。
6、like以通配符%开头，索引会失效变成全表扫描，覆盖索引。
7、OR 前后只要存在非索引的列，都会导致索引失效。
8、字符串条件查询不加单引号索引会失效。
9、如果mysql使用全表扫描要比使用索引快,则不会使用到索引。
10、delete in子查询，是不会走索引，mysql默认没做优化；select in走索引，mysql默认做了优化改成join;

解决方案：1、优化join 2、取别名
11、order by 优化：排序用到了缓冲区 sort_buffe filesort。

解决方案：order by 字段和条件加上联合索引(索引本身有序)；

如果索引顺序和排序不一致：修改索引排序 KEY idx_age_name (age,name desc) USING BTREE
12、group by 优化：分组用到了temporary和filesort。

解决方案：group by 字段加索引保证一开始有序；尽量只使用内存临时表； order by null 不用排序。
13、深度分页优化

如：limit 100000,10 limit语句会先扫描offset+n行，然后再丢弃掉前offset行，返回后n行数据；扫描更多的行数意味着更多的回表查询。

limit 深分页问题的本质原因就是：偏移量（offset）越大，mysql就会扫描越多的行，然后再抛弃掉。这样就导致查询性能的下降。

优化思路：把条件转移到主键索引树：子查询或者inner join || between and 处理。

eg：select id,name,balance FROM account where id >= (select a.id from account a where a.update_time >= '2020-09-19' limit 100000, 1) LIMIT 10;（可以加下时间条件到外面的主查询）

mysql慢查询处理sql优化

获取当前系统各个事务的加锁信息

死锁分析步骤

sql优化思路

索引失效场景