MySQL性能管理及架构设计（二）：数据库结构优化、高可用架构设计、数据库索引优化

1、数据库结构优化（很是重要）

1.1 数据库结构优化目的

一、减小数据冗余：（数据冗余是指在数据库中存在相同的数据，或者某些数据能够由其余数据计算获得），注意，尽可能减小不表明彻底避免数据冗余；

二、尽可能避免数据维护中出现更新，插入和删除异常：

总结：要避免异常，须要对数据库结构进行范式化设计。

三、节约数据存储空间。

四、提升查询效率。

1.2 数据库结构设计步骤

一、需求分析：全面了解产品设计的存储需求、数据处理需求、数据安全性与完整性；

二、逻辑设计（重要）：设计数据的逻辑存储结构。数据实体之间的逻辑关系，解决数据冗余和数据维护异常。数据范式能够帮助咱们设计；

三、物理设计：表结构设计，存储引擎与列的数据类型；

四、维护优化：索引优化、存储结构优化。

1.3 数据库范式设计与反范式化

ref="https://segmentfault.com/a/1190000013695030">传送门：数据库逻辑设计之三大范式通俗理解，一看就懂，书上说的太晦涩

1.4 物理设计

f="https://segmentfault.com/a/1190000010012140">相关传送门：MySQL中字段类型与合理的选择字段类型；int(11)最大长度是多少？，varchar最大长度是多少

2、高可用架构设计

2.1 读写分离

MaxScale：实现MySQL读写分离与负载均衡的中间件利器

3、数据库索引优化（很是重要）

3.1 两种主要数据结构：B-tree和Hash

3.1.1 B-tree结构

B-tree索引的限制：

3.1.2 Hash结构

Hash索引的限制：

• Hash索引必须进行二次查找
• Hash索引没法用于排序
• Hash索引不支持部分索引查找也不支持范围查找
• Hash索引中Hash码的计算可能存在Hash冲突，不适合重复值很高的列，如性别，身份证比较合适。

3.1.3 MySQL常见索引和各类索引区别

PRIMARY KEY（主键索引）  ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) 
UNIQUE(惟一索引)     ALTER TABLE `table_name` ADD UNIQUE (`column`)
INDEX(普通索引)     ALTER TABLE `table_name` ADD INDEX index_name ( `column` ) 
FULLTEXT(全文索引)      ALTER TABLE `table_name` ADD FULLTEXT ( `column` )
组合索引   ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

1. 普通索引：最基本的索引，没有任何限制
2. 惟一索引：与"普通索引"相似，不一样的就是：索引列的值必须惟一，但容许有空值。
3. 主键索引：它 是一种特殊的惟一索引，不容许有空值。
4. 全文索引：仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时好空间。
5. 组合索引：为了更多的提升mysql效率可创建组合索引，遵循”最左前缀“原则。

3.2 使用索引好处和索引缺陷

3.2.1 为何要使用索引

一、索引大大减小了存储引擎须要扫描的数据量；

二、索引能够帮助咱们进行排序以免使用临时表；

三、索引能够把随机I/O变为顺序I/O。

3.2.2 索引不是越多越好

一、索引会增长写操做的成本；

二、太多的索引会增长查询优化器的选择时间。

索引就比如一本书的目录，它会让你更快的找到内容，显然目录（索引）并非越多越好，假如这本书1000页，而有500页是目录，它固然效率低，目录是要占纸张的,而索引是要占磁盘空间的。

3.3 索引优化策略

3.3.1 索引列上不能使用表达式和函数

3.3.2 前缀索引和索引列的选择性

Innodb索引列最大宽度为 667个字节( utf-8 差很少 255个字符), MyIsam索引类宽度最大为 1000个字节，因而出现前缀索引，索引的选择性。

对于列的值较长，好比BLOB、TEXT、VARCHAR，就必须创建前缀索引，即将值的前一部分做为索引。这样既能够节约空间，又能够提升查询效率。但没法使用前缀索引作 ORDER BY 和 GROUP BY，也没法使用前缀索引作覆盖扫描。

语法： ALTER TABLE table_name ADD KEY(column_name(prefix_length))

如何选择索引列的顺序：

一、常常会被使用到的列优先（选择性差的列不适合，如性别，查询优化器可能会认为全表扫描性能更好）；

二、选择性高的列优先；

三、宽度小的列优先（一页中存储的索引越多，下降I/O，查找越快）；

3.3.3 组合/联合索引策略

若是索引了多列，要遵照最左前缀法则。指的是查询从索引的最左前列开始而且不跳过索引中的列。
"http://www.uml.org.cn/sjjm/201107145.asp#nav-4-2">深刻理解请移步：最左前缀原理与相关优化

3.3.4 覆盖索引策略

跟组合索引有点相似，若是索引包含全部知足查询须要的数据的索引则成为覆盖索引(Covering Index)，也就是平时所说的不须要回表操做。即索引的叶子节点上面包含了他们索引的数据(hash索引不能够)。

判断标准：使用explain，能够经过输出的extra列来判断，对于一个索引覆盖查询，显示为using index,MySQL查询优化器在执行查询前会决定是否有索引覆盖查询。

优势:

一、能够优化缓存,减小磁盘IO操做；
   二、能够减小随机IO,变随机IO操做变为顺序IO操做；
   三、能够避免对InnoDB主键索引的二次查询；
   四、能够避免MyISAM表进行系统调用；

没法使用覆盖索引的状况：

一、存储引擎不支持覆盖索引；
   二、查询中使用了太多的列（如SELECT * ）；
   三、使用了双%号的like查询（底层API所限制）；

mysql高效索引之覆盖索引

3.3.5 SQL索引优化总结口诀（套路重点）

全值匹配我最爱，最左前缀要遵照；
带头大哥不能死，中间兄弟不能断；
索引列上不计算，范围以后全失效；
LIKE百分写最右，覆盖索引不写 *；
不等空值还有or，索引失效要少用；
字符单引不可丢，SQL高级也不难 ；

MySQL高级-索引优化

3.4 使用索引来优化查询

3.4.1 利用索引排序

一、group by 实质是先排序后分组，遵守索引的最佳左前缀。；

二、索引中全部列的方向(升序、降序)和Order By子句彻底一致；

三、当没法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置；

四、若是最左列使用了范围，则排序会失效；

五、where 高于having，能写在where限定的条件就不要去having去限定了

3.5 索引的维护和优化

3.5.1 删除重复索引

注：主键约束至关于(惟一约束 + 非空约束)

一张表中最多有一个主键约束,若是设置多个主键,就会出现以下提示：Multiple primary key defined!!!

3.5.2 删除冗余索引

检查工具：pt-duplicate-key-checker

ef="http://www.uml.org.cn/sjjm/201107145.asp#nav-4-2">扩展阅读： MySQL索引背后的数据结构及算法原理

explain 查询计划Using where：表示优化器须要经过索引回表查询数据；
Using index：表示直接访问索引就足够获取到所须要的数据，不须要经过索引回表，如覆盖索引；

ref="https://zhuanlan.zhihu.com/p/74826503">下一篇：MySQL性能管理及架构设计（三）：SQL查询优化、分库分表 - 完结篇

原做者：：唐成勇
原文连接： 人类身份验证 - SegmentFault
原出处：思否