在项目中，有时候时间紧，我们往往比较关注功能，对于性能关注度没有那么高，书写的SQL能够支持功能即可，但是在线上运行过程中，会出现各种问题，sql太慢，这时候我们的第一反应是是不是没走索引，于是找到DBA说加个索引，但是其实有了索引查询未必快，具体问题需要具体分析，对于查询，我们可以自己通过explain来分析一下，这样和DBA沟通起来会非常方便。
这里顺便总结一下mysql的监控情况，linux的系统级别监控就不提了，因为mysql是IO密集型应用，所以重点关注iowait，对于mysql本身，qps（每秒内查询的次数）TPS（每秒内提交的事务，可以理解为insert+update+update），thread running（当前处于活动状态的数据库连接数），最重点的就是RT，貌似mysql没发直接查看响应时间，这个DBA写工具解决，这个指标可以视为在紧急情况下首要关注的，其次还有innodb层的监控，这个作为开发就比较业余了。
这里抄袭一下索引设计的几个原则：
A、设置索引项，应该是出现在where后面的列，或者连接字句中出现的列；
B、使用唯一索引，索引的基数越大，索引查询的效果越好，举例：查询条件中含有索引字段和非索引字段的时候，会优先走索引筛选出数据，然后在数据中回表过滤没有走索引的字段，但是Mysql任务，如果索引筛选出的数据量大于20%，会认为此时走索引效果不如全表扫描，继而放弃索引，走全表扫描来查询；
C、使用短索引，例如一个属性200多位，其实索引只要创建前几位效果会好；
D、最左原则，组合索引中，灵活运用最左前缀；
E、不要过度使用索引，索引会占用空间，影响写入的速度；
（1）慢SQL如何获取？
应用程序能够感知到SQL慢，因为慢了，提供服务就慢，系统吞吐自然就上不去。这时候可以在mysql上面查看慢SQL的日志，这个文件看起来不是很方便，DBA通过工具把这些日志加工成比较容易分析，能够很直观的看出慢SQL是啥，以及SQL执行花费的时间和执行的时间点。获取了这些慢SQL，就有了分析的依据。
（2）如何分析SQL为啥慢了？
mysql提供了一个工具来分析SQL执行查询的时候的情况，使用很简单：explain select语句
输出的结果是表格，各个字段的解释如下：
| select_type |
simple：简单表，即不使用表连接或者子查询； primary：主查询 union：union中的第二个或者后面的查询语句 subquery：子查询中的第一个select |
| table |
输出结果集的表 |
| type |
表连接的类型 system：表中仅有一行，即常量表 const：单表中最多有一个匹配行，主键或者唯一索引 eq_ref：对于前面的每一行，在此表中只查询一条记录，简单说就是多表查询中使用主键或者唯一索引 ref：和eq_ref类似，区别在于使用的是普通的索引 ref_or_null：和ref类似，区别在于查询总有NULL的查询 index_merge：索引合并优化 unique_subquery：in后面是一个查询主键的子查询 index_subquery:in后面的是一个查询普通索引的子查询 range：单表中的范围查询 index：前面的每一行，都通过查询索引获取数据 all:全表扫描，性能最差 |
| possible_keys |
查询时可能用到的索引 |
| key |
查询时实际用到的索引 |
| key_len |
索引字段的长度 |
| ref |
|
| rows |
扫描行的数量 |
| extra |
执行情况的说明和描述 |