工作中数据库优化和explain字段知识的总结
为什么要优化？
系统的吞吐量瓶颈往往出现在数据库的访问速度上
数据库中的数据越来越多，处理时间会相应变慢
优化原则：减少资源占用，增加系统的反应速度
0.Redis缓存
针对这种信息不经常变动且数据量较大的情况，把它加入缓存，提高系统的访问效率
减少数据库连接是一种优化手段，有些查询可以不用访问数据库，可以通过缓存服务器redis，elasticsearch增加缓存，减少数据库的连接。
1.主从复制，读写分离
程序使用数据库较多时而更新少，查询多的情况下考虑使用，减少数据库压力，提高性能。
通过MySQL主从复制，curd走master服务器，查询走slaver从服务器，这样就减少了只有一台MySQL服务器的压力。
2.数据库参数配置优化
例如最大连接数默认为100，即使SQL语句优化再好，硬件设备配置再高，请求超过100都要再等待，这就是配置不合理导致。
https://cloud.tencent.com/developer/article/1582406
3.优化数据库表结构的设计
选用合理的字段的数据类型（数据库最终要写到磁盘上，字段的长度也会影响磁盘的I/O操作）。比如：人的年龄用无符号unsigned tinyint即可，没必要用integer数据类型的长度；用户的手机号11位长度，没必要255个长度。
SQL优化，使用索引
3.1索引
3.1.1.哪种情况使用索引
频繁作为查询条件的字段
查询中排序的字段，访问速度加快
查询中统计或者分组的字段
定义有外键的数据列一定要建立索引
3.1.2.哪种情况不需要建立索引
频繁更新的字段
where条件里用不到的字段
表记录太少
数据重复的字段
4.MySQL性能优化神器-Explain
4.1简介
MySQL提供了一个Explain命令，它对select语句进行分析，并输出select执行的详细信息，以供开发人员针对性优化。
4.2explain主要的格式介绍
4.2.1 id
select 识别符，查询序列号，为sql语句执行的顺序。
4.2.2 select_type
| select_type | meaning |
|---|---|
| simple | 简单的SELECT语句（不包括UNION操作或子查询操作） |
| primary | 表示此查询是最外层的查询 |
| union | UNION操作中，查询中处于内层的SELECT |
| subquery | 子查询中的第一个select |
| dependent union | UNION操作中，查询中处于内层的SELECT（内层的SELECT语句与外层的SELECT语句有依赖关系） |
| subquery | 子查询中的第一个select |
| union result | UNION操作的结果，id值通常为NULL |
4.2.3 type
最好到最差
| type value | meaning |
|---|---|
| const | 通过索引一次就找到了，单表中最多有一个匹配行，primary key 或者 unique index的检索 |
| eq_ref | 唯一性索引，多表连接中被驱动表的连接列上有primary key或者unique index的检索 |
| ref | 与eq_ref类似，但不是使用primary key或者unique index，而是普通索引。也可以是单表上non-unique索引检索 |
| range | 单表索引中的范围查询,使用索引查询出单个表中的一些行数据。ref列会变为null。 |
| index | 比all好点 |
| all | 全表扫描 |
4.2.4 key
possible_key 索引列出，不一定实际使用
key 实际使用的索引
key_len 索引字段最大可能长度
4.2.5 rows
根据表统计及索引选用情况，大致估算出找到所需的记录所需读取的行数
4.2.6 extra
包含不适合在其他列中显示但十分重要的额外信息
using filesort 不是按照表内的索引顺序进行访问
using temporary 增加了数据库的负担，使用了临时表来存储中间结果集，适用于group by，distinct，或order by列为不同表的列。
using index 好的，使用了覆盖索引