问题
我的 MySQL CPU 高了，看了一下 processlist，实在有太多行了，我要不要准备辞职？
实验
MySQL CPU 飚高的原因有很多种，我们先分析一种最简单常见的。
还是先建个数据库：
还是按照之前实验 11 的技巧，快速造一些数据：
反复执行最后一句 SQL：
下面来执行一条比较坑的 SQL，让 CPU high 起来：
现在我们忘掉之前做了什么，就来处理这个 CPU 高的问题。
先用 top -H 找到 CPU 高的线程，这里可以看到 CPU 高的线程一直是 17967
(如果 CPU 高的线程号一直在变，那可能不是单个 SQL 引起的 CPU 消耗，需要用其他方法来辅助分析，方法我们以后会介绍)
找到这个线程的任务：
可以看到很多有用的信息：
1. 可以看到 processlist 中对应这根线程的信息
2. 可以找到其在 processlist 中的 ID，这样我们就可以下 kill 命令来结束 SQL小贴士：
使用 performance_schema 时，需要大家注意 MySQL 使用了多个线程编号，源自于不同视角：
1. PROCESSLIST_ID：在 processlist 中的编号，是使用者视角的编号，使用者可以直接用 kill 命令。
2. THREAD_ID：是 MySQL 内部使用的线程编号，是 MySQL 内部视角的编号。
3. THREAD_OS_ID：是在操作系统上，对应的线程编号，是操作系统视角的编号。
大家使用时需要区分好，不要 kill 错了 SQL。
我们再来找找其他有用的信息：
可以看到 SQL 执行的开始时间，正在使用了一张临时磁盘表。
如果开启了 performance_schema 的其他监控项，通过 Thread_ID 关联，可以找到更多信息。
当然，眼下这么明显的坑 SQL，我们 kill 掉就是了。
关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！

同事遇到一个奇葩的问题，一个表里某个字段建了索引，但是有的值走索引，有的值不走索引。因为一般情况一个字段要么完全不走索引，要么走索引，怎么会有的值走索引，有的不走索引。
select 条件非常简单，因为涉及到敏感信息就不贴表结构了。例如select * from order where status = 2;  status为状值。分别为-1删除，1正常，2待定。因为sql比较简单，所以排除前缀原则、like 、in 及where条件等号左边有函数不走索引的情况。百思不得其解。
然后为了进一步定位问题，看是不是索引建的多的原因，又去其它表里看了一下，不是这个原因。
那是什么原因呢？因为只有2不索引，所以我又试了一下其它值都走索引，我将2改为3试一下，结果奇迹发生了，2居然走索引了。再试一下status=3。也走索引，我怀疑是边界的问题。然后google一下关于索引是否有边界这样的情况影响索引。也没有结果。
那我想再把所有2改为3，现试一下，是不是跟这些数据有关，奇迹发生了！status=3也没走索引。进一步缩小范围。为什么status=3也不走索引呢？然后我想到了是不是跟索引的稀疏性有关？也就是说因为重复的数据所以优化器判断索引无效所以不走索引呢？
我又把status=3改回去，观察一下重复数据分布，status=2的条数为3条，status=-1有两条，status=1有两条，我再把其中一条status=4,发现都走索引了。为了进一步验证自己的结论，又试了一下将其中一条status=2改为1，结果status=1不走索引了。更进一步验证了自己的判断！
所以这次的问题就是因为当数据表中数据比较稀疏时，而当字段个数比较少时，优化器会认为这个索引效果不明显，所以不走索引。
进一步我和同事又将status的索引去掉，发现expalin 的rows列显示所有行，无论status为任意值。而如果status建索引的话重复的比较多的不走索引。所以结果是建索引性能提升不大。具体根据自己的情况来建索引。

前言

我们之前讲了MySQL索引的底层数据结构，以及索引的失效原理等知识点。那么索引在硬盘上到底是怎么存储的呢？怎么通过索引定位查询出一条真实的数据呢？

MySQL两大引擎MyIsam和InnoDB他们的索引又有哪些不同点呢？

今天我们就来给大家揭晓一下

MyIsam 和 InnoDB常见区别

事务方面

InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一。

外键方面

InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败。

索引层面

InnoDB 是聚集（聚簇）索引，MyISAM 是非聚集（非聚簇）索引。后面会重点讲解这两种索引的区别。

MyISAM支持 FULLTEXT类型的全文索引， InnoDB不支持FULLTEXT类型的全文索引，但是InnoDB可以使用sphinx插件支持全文索引，并且效果更好。

锁粒度方面

InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。

一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。

这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一。

硬盘存储结构

MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。


	
.frm文件存储表的定义。
	
	

	
数据文件的扩 展名为.MYD (MYData)。
	
	

	
索引文件的扩 展名是.MYI (MYIndex)。
	
Innodb存储引擎存储数据库数据，一共有两个文件(没有专门保存数据的文件)：


	
Frm文件：表的定义文件。
	
	

	
Ibd文件：数据和索引存储文件。数据以主键进行聚集存储，把真正的数据保存在叶子节点中。
	
聚簇索引 和 非聚簇索引

聚簇索引（InnoDB）

将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据。

表数据按照索引的顺序来存储的，也就是说索引项的顺序与表中记录的物理顺序一致。

InnoDB中，在聚簇索引之上创建的索引称之为辅助索引，像复合索引、前缀索引、唯一索引等等。


	
聚簇索引默认是主键，
	
	

	
如果表中没有定义主键，InnoDB 会选择一个唯一的非空索引代替。
	
	

	
如果没有这样的索引，InnoDB 会在内部生成一个名为 GEN_CLUST_INDEX 的隐式的聚簇索引。
	
非聚簇索引（MyISAM）

将数据与索引分开存储，表数据存储顺序与索引顺序无关。

MyISAM索引查询数据过程

非聚簇索引存储结构：



源于网络

MyISAM的 B+树 的叶子节点上，记录的是真实数据的存储地址。

比如通过主键id查询，MyISAM查询流程如下：


	
根据id值在B+树上找到相应的叶子节点
	
	

	
取出叶子节点上的数据存储地址
	
	

	
根据数据存储地址，去找到相应的真实数据
	
InnoDB索引查询数据过程

聚簇索引存储结构：



源于网络

InnoDB的 B+树 的叶子节点上，记录的是真实行数据。

比如通过主键id查询，InnoDB查询流程如下：

聚簇索引（主键索引）：


	
根据id值在B+树上找到相应的叶子节点
	
	

	
取出叶子节点上的行数据，返回即可
	
辅助索引（聚簇索引以外的）：


	
在相应索引的B+树上找到相应的叶子节点
	
	

	
取出叶子节点上的数据，该数据是主键id
	
	

	
拿到主键id后，去主键索引的B+树上找到相应的叶子节点
	
	

	
取出叶子节点上的行数据，返回
	
总结

以上就是两个引擎索引查询流程，MyIsam 和 InnoDB各有优缺点。

比如通过主键id查询的时候，InnoDB比MyIsam快一些，因为InnoDB只需要一次B+树查找就能取出数据。MyIsam通过B+树查找到地址后，还需要根据地址去查询真正的数据。

但是InnoDB普通索引查询会比MyIsam慢些，因为InnoDB要进行2次B+树的查找。

还比如说在数据重构的时候，MyIsam记录的是数据地址，那么重构数据的时候地址就要重新生成一遍，这也是有问题的。

InnoDB重构数据的时候就不会这样，因为他记录的是主键id，地址会变化，主键id是不会变的。

还有为什么少用select *，为什么尽量使用覆盖索引，大家能根据他们的索引结构推测出来吗，给大家留道思考题？

每个技术都是存在优缺点的，我们还是那句话，对于技术我们要扬长避短，根据我们的业务场景，发挥出技术的长处。

mysql优化主要优化是在查询方面，对性能比较大的影响就是索引，

索引优化：

1.给经常作为查询或者需要排序的列建立索引；原因是如果需要排序没有索引就会使用全文索引比较消耗性能；

2.尽量用主键索引，因为主键和数据是存在一起的，可以最快定位到数据（聚集索引）；

3.二级索引可以设计为组合覆盖索引避免回表；

4.主键尽量用int类型，减少将来建立二级索引占用空间，提升效率，

5.模糊查询不让%在前面，因为用这个会造成索引失效，如果要用建议用ES；

6.避免在比较字段上使用函数，或者执行数据类型转换；
Sql优化：

1.用explain评估索引使用情况，扫描行数等避免全表扫描；

2.使用慢查询日志定位问题sql；

3.不用select *

4.多使用limit 限制行数

5.合理使用分页（越往后翻页，效率越低）分页插件会智能的添加limit起始 ，如limit 999999990，10 优化 where id>9999999989 limit 10  ，前提是id中间没有空缺，

6.避免null值，常用默认值

7.减少大表连接，最好不要超过3层；
单库数据量太大再考虑分库分表；