MySQL优化
MySQL优化分为以下几个大类：
数据库调优在一般情况下都是SQL调优，那么，应该如何进行SQL调优呢？
id select_type description 1 SIMPLE 不包含任何子查询或union等查询 2 PRIMARY 包含子查询最外层查询就显示为 PRIMARY 3 SUBQUERY 在select或 where字句中包含的查询 4 DERIVED from字句中包含的查询 5 UNION 出现在union后的查询语句中 6 UNION RESULT 从UNION中获取结果集
type:(非常重要，可以看到有没有走索引) 访问类型
all 扫描全表数据
index 遍历索引
range 索引范围查找
index_subquery 在子查询中使用 ref
unique_subquery 在子查询中使用 eq_ref
ref_or_null 对Null进行索引的优化的 ref
fulltext 使用全文索引
ref 使用非唯一索引查找数据
eq_ref 在join查询中使用PRIMARY KEYorUNIQUE NOT NULL索引关联。
possible_keys:可能使用的索引，注意不一定会使用。查询涉及到的字段上若存在索引，则该索引将被列出来。 当该列为 NULL时就要考虑当前的SQL是否需要优化了。
key:显示MySQL在查询中实际使用的索引，若没有使用索引，显示为NULL。查询中若使用了覆盖索引，则该索引仅出现在key列表中
key_length:索引长度
ref:表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
rows:返回估算的结果集数目，并不是一个准确的值。
extra:执行情况的描述和说明,extra的信息非常丰富，常见的有：
Using index 使用覆盖索引
Using where 使用了用where子句来过滤结果集
Using filesort 使用文件排序，使用非索引列进行排序时出现，非常消耗性能，尽量优化。
Using temporary 使用了临时表 sql优化的目标可以参考阿里开发手册
注: EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。
- BETWEEN AND 替换 IN
- EXISTS 替换 IN
-
LEFT JOIN 替换 IN
-
较频繁作为查询条件的字段才去创建索引
- 更新频繁字段不适合创建索引
- 不能有效区分数据的列不适合做索引列(如性别)
- 定义有外键的数据列一定要建立索引
- 尽量扩展索引不要新建索引
修改事务的隔离级别,具体查看上文MySQL事务
- 设计规范化表，消除数据冗余
数据库三范式
第一范式：属性(字段)的原子性约束，要求属性具有原子性，不可再分割
第二范式：记录的唯一性约束，要求记录有唯一标识，每条记录需要有一个属性来做为实体的唯一标识
第三范式：属性(字段)冗余性的约束，即任何字段不能由其他字段派生出来，在通俗点就是：主键没有直接关系的数据列必须消除(消除的办法就是再创建一个表来存放他们，当然外键除外)
满足范式的表，称为规范化表
如果数据库设计达到了完全的标准化，则把所有的表通过关键字连接在一起时，不会出现任何数据的复本(repetition)。
标准化的优点是明显的，它避免了数据冗余，自然就节省了空间，也对数据的一致性(consistency)提供了根本的保障，杜绝了数据不一致的现象，同时也提高了效率。 - 适当的冗余，增加计算列
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点
满足范式的表一定是规范化的表，但不一定是最佳的设计。很多情况下会为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
合理的冗余可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。(例如合计、总量这种由其他字段计算出来的列) - 字段设计优化
字段是数据库最基本的单位，其设计对性能的影响是很大的。需要注意如下：
A、数据类型尽量用数字型，数字型的比较比字符型的快很多。
B、数据类型尽量小，这里的尽量小是指在满足可以预见的未来需求的前提下的。
C、尽量不要允许NULL，除非必要，可以用NOT NULL+DEFAULT代替。
D、少用TEXT和IMAGE，二进制字段的读写是比较慢的，而且，读取的方法也不多，大部分情况下最好不用。
E、自增字段要慎用，不利于数据迁移
MySQL的主从复制以及存在的问题
MySQL主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。
由于主从同步是一个异步复制过程，那么是会出现在数据库事务中，进行了数据的主库插入后，立刻查询丛库，结果在丛库中找不到数据的可能性的，那么在这种情况下，以博主个人见解，有两种方案，一种是针对代码上的方案，在数据库的事务中，写入主库就直接从主库中查，以解决业务层面的主从延迟问题，另外一种是使用强一致性的MySQL架构PXC集群。（PXC集群就不在本文过多赘述了）
Original: https://www.cnblogs.com/winter0730/p/15361735.html
Author: cos晓风残月
Title: 数据库原理三—MySQL数据库优化
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/576260/
转载文章受原作者版权保护。转载请注明原作者出处！