一次MySQL数据库性能排查。不要一想到数据库的问题就都是各种加索引

最近接管一个做B2B的新团队，网站奇慢无比，20多秒的SELECT到处都是。原来的“架构师”认为用MyISAM读性能很好，就广泛采用了 MyISAM 存储引擎。

BUT

MyISAM表锁

MyISAM只支持表锁，

表锁有共享读锁和独占写锁两种模式。读锁与读锁是兼容的，读锁与写锁是互斥的，写锁与写锁是互斥的。也就是说，MyISAM表的一个连接的读操作是不会阻塞其它连接的读操作的，但是会阻塞其它连接的写操作，而一个连接的写操作会阻塞其它连接的读操作和写操作。

因此MyISAM的读操作和写操作，以及写操作之间是串行的！MyISAM在执行读写操作的时候会自动给表加相应的锁（也就是说不用显示的使用lock table命令）， MyISAM总是一次获得SQL语句所需要的全部锁，这也是MyISAM不会出现死锁的原因。

1：一个看似是 select 的SQL，却把

2、3 处的 select update 都阻塞了

解决方法是，换用InnoDB引擎，因为它可以做到行级锁。

=================================

这个团队还加了不合适的索引、各种varchar text 导致的不定长行、foreach select没有做批量select、所有属性都放到一张大表没有做主从表分离 ... 等等其它的问题，后面再写。 

数据库优化真不是加索引这么简单。

有时为了分析SQL的执行过程，只用explain 也不解决不了问题的时候，就得深入到代码层，去调试mysql 的代码了。像上图，再普通不过的两表 left join，相应的索引也加了，但还是要 19s，这个时候 explain 的信息就不足够了。

redhat 系的系统可以用 debuginfo-install安装 mysql 的debug包，这样就可以调试mysql 了，都不需要从源码编译mysql。

vim中使用gdb，主要是可以在vim中方便去按照栈跳转浏览代码，命令行中用gdb的 list 命令看到代码范围太小了。

=============== 2018.04.10 补充 ====================

开发做了主从表拆分，把主表调整为定长，预期应该有效果的。

但运行一天后发现8核的数据库的CPU占用飙到 100%。

看了一下长时间执行的SQL对应的mysql 栈，发现是大表的join，在不断的 seek 寻址计算引起。

为什么会这样呢？

这要从为什么要折表说起。

1）调整前：一张大表（几百万的数据量），不定长。

2）调整后：一张定长的主表（字段经常查询），和一张不定长的从表（字段很少查询）

但开发，调整后，某个业务功能还是把 主表和从表join起来，这么一join，mysql就会生成一张 临时表，这张临时表和【调整前】的表是一样的，

这么看来：

1）开发做多余的功了，调整前后都是一样的大表，调整后反而由于join的操作多做功了

2）join 的从表是不定长的，要不断 seek 寻址再知道每一个数据行的起始地址，消耗了大量的CPU

回顾一下为什么要折表呢？

这个业务是展示某一页总共20行的数据，是希望把原来查一张大表（几百万的数据量）的一步逻辑分成下面两步，每一小步都很快完成，整体功能也就很快返回了。

1）希望查询 定长的主表（速度很快），知道要展示那20行数据

2）再向从表查询这20行数据（只找出20行，即使表不是定长的，速度也很快）

=============== 2018.04.26 补充 ====================

经过这么2018.4.10拆分优化后，过了一段时间，搜索引擎终于认为我们的站点打开速度达到2s以下，加大了对我们站点的收录。