MySQL学习笔记：高级篇

1. 存储引擎

1.1 InnoDB表引擎

• 默认事务型引擎，最重要最广泛的存储引擎，性能非常优秀。数据存储在共享表空间，可以通过配置分开。对主键查询的性能高于其他类型的存储引擎。内部做了很多优化，从磁盘读取数据时自动在内存构建hash索引，插入数据时自动构建插入缓冲区
• 通过一些机制和工具支持真正的热备份，支持崩溃后的安全恢复，支持行级锁，支持外键

1.2 MyISAM表引擎

• mysql5.5版本之前的默认存储引擎 ，拥有全文索引、压缩、空间函数。不支持事务和行级锁，支持表锁，不支持奔溃后的安全恢复。表存储在两个文件，.MYD（数据文件）和.MYI（索引文件），.frm（结构文件，所有存储引擎都有）。设计简单，某些场景下性能很好

1.3 其他的表引擎

• Archive、Blackhole、CVS、Memory

参考资料
mysql 存储引擎 · Issue #28 · chengfengjie/chengfengjie.github.io

2. 索引

2.1 索引对性能的影响

• 大大减少服务器需要扫描的数据量，帮助服务器避免排序和临时表、将随机I/O变顺序I/O，大大提高查询速度，降低写的速度、占用磁盘

2.2 索引的使用场景

• 小表：大部分情况下全表扫描效率更高。
• 中到大型表：索引非常有效。
• 特大型的表：建立和使用索引的代价随之增长，可以使用分区技术来解决

2.3 索引的类型

• 注意
  
  • 一个表只能有一个主键索引，可以有多个唯一索引。
  • 主键索引一定是唯一索引，唯一索引不是主键索引。
  • 主键可以与外键构成参照完整性约束，防止数据不一致

类别	说明
普通索引	最基本的索引，没有任何约束限制
唯一索引	与普通索引类似，但是具有唯一性约束
主键索引	特殊的唯一索引，不允许有空值
组合索引	将多个列组合在一起创建索引，可以覆盖多个列
外键索引	只有InnoDB类型的表才可以使用外键索引，保证数据的一致性、完整性和实现级联操作
全文索引	MySQL自带的全文索引只能用于MyISAM，并且只能对英文进行全文索引

2.4 MySQL索引的创建原则

• 最适合索引的列是在where子句中的列，或连接子句中的列而不是出现在select关键字后的列
• 索引列的基数越大。索引的效果越好
• 对字符串进行索引，应该制定一个前缀长度，可以节省大量的索引空间
• 根据情况创建复合索引，复合索引可以提高查询效率
• 避免创建过多索引，索引会额外占用磁盘空间，降低写操作效率
• 主键尽可能选择短的数据类型，可以有效减少索引的磁盘占用提高查询效率

2.5 MySQL索引的注意事项

• 复合索引遵循前缀原则
• like查询。%不能在前，可以使用全文索引
• column is null可以使用索引
• 如果MySQL估计使用索引比全表扫描更慢，会放弃使用索引
• 如果or前的条件中的列有索引，后面的没有，索引都不会被用到
• 列类型是字符串，查询时一定要给值加引号，否则索引失效

3. 查询优化

3.1 查找分析SQL查询慢的原因

• 记录慢查询日志：
  
  • 分析查询日志，不要直接打开查询日志进行分析，这样比较浪费时间和精力，可以使用pt-query-digest工具进行分析
• 使用show profile：
  
  • set profiling=1;开启，服务器上执行的所有语句会检测消耗的时间，存到临时表中（show profiles；show profiles for query 临时表ID）
• 使用show status：
  
  • show status 会返回一些计数器，show global status 查看服务器级别的所有计数；
  • 有时根据这些计数，可以猜测出哪些操作代价较高或者消耗时间多
• 使用show processlist：
  
  • 观察是否有大量线程处于不正常的状态
• 使用explain：
  
  • 分析单条SQL语句

3.2 优化查询过程中的数据访问

• 原因

  • 访问数据太多导致查询性能下降
  • 确定应用程序是否在检索大量超过需要的数据，可能是太多行或列
  • 确认MySQL服务器是否在分析大量不必要的数据行

• 避免使用如下SQL语句

  • 查询不需要额记录，使用limit解决
  • 多表关联返回全部列，指定A.id,B.age
  • 总是取出全部列，SELECT * 会让优化器无法完成索引覆盖扫描的优化

• 注意：重复查询相同数据，可以缓存数据，下次直接读取缓存！

• 是否在扫描额外的记录？

  • 使用explain来进行，如果发现查询需要扫描大量数据但只返回少数的行，可以通过如下技巧去优化：使用索引覆盖扫描，把所有用的列都放到索引中，这样存储引擎不需要回表获取对应行就可以返回结果
  • 改变数据库和表的结构，修改数据表范式（冗余）。
  • 重写SQL语句，让优化器可以以更优的方式执行查询

3.3 优化长难的查询语句

• 一个复杂查询还是多个简单查询

  • MYSQL内部每秒能扫描内存中上百万行数据，相比之下，响应数据给客户端就要慢得多
  • 使用尽可能少的查询是好的，但是有时将一个大的查询分解为多个小的查询时很有必要的

• 切分查询

  • 将一个大的查询分为多个小的相同的查询
  • 一次性删除1000万的数据要比一次删除一万，暂停一会的方案更加耗损服务器开销

• 分解关联查询

  • 可以将一条关联语句分解成多条SQL来执行
  • 让缓存的效率更高
  • 执行单个查询可以减少锁的竞争
  • 在应用层做关联可以更容易对数据库进行拆分

3.4 优化特定类型的查询语句

• 优化count()查询

  • count( * )中*会忽略所有的列，直接统计所有列数，因此不要使用count(列名)
  • MyISAM中，没有任何where条件的count( * )非常快
  • 当有where条件，MyISAM的count统计不一定比其他表引擎快

• 优化方案

  • 可以使用explain查询近似值，用近似值替代count(*)
  • 增加汇总表
  • 使用缓存

• 优化关联查询

  • 确定on或者using子语句的列上有索引
  • 确保group by和order by中只有一个表中的列，这样MySQL才有可能使用索引

• 优化子查询

  • 尽可能使用关联查询来替代，尽量少使用子查询

• 优化group by 和distinct

  • 这两种查询均可使用索引来优化，是最有效的优化方法
  • 关联查询中，使用标识列进行分组的效率会更高
  • 如果不需要order by,进行group by时使用order by null，MySQL不会再进行文件排序
  • with rollup超级聚合，可以挪到应用程序处理

• 优化limit分页

  • limit偏移量大的时候，查询效率低
  • 可以记录上一次查询的最大ID，下次查询时直接根据该ID来查询

• 优化UNION查询

  • UNION ALL的效率高于UNION

4. MySQL高可扩展和高可用

4.1 分区表的原理

• 工作原理：

  • 对用户而言，分区表是一个独立的逻辑表，但是底层MySQL将其分成了多个物理子表，这对用户来说是透明的，每一个分区表都会使用一个独立的表文件。
  • 创建表时使用partition by子句定义每个分区存放的数据，执行查询时，优化器会根据分区定义过滤那些没有我们需要数据的分区，这样查询只需要所需数据在的分区即可
  • 分区的主要目的是将数据按照一个较粗的粒度分在不同的表中，这样可以将相关的数据存放在一起，而且如果想一次性删除整个分区的数据也很方便

• 适用场景

  • 1、表非常大，无法全部存在内存或者只在表最后有热点数据，其他都是历史数据
  • 2、分区表的数据更易维护，可以对独立的分区进行独立的操作
  • 3、分区表的数据可以再不同的机器上，从而高效适用资源
  • 4、可以使用分区表来避免某些特殊的瓶颈
  • 5、可以备份和恢复独立的分区

• 限制

  • 1、一个表最多只能有1024个分区
  • 2、5.1版本中，分区表表达式必须是整数，5.5可以使用列分区
  • 3、分区字段中如果有主键和唯一索引列，那么主键列和唯一列都必须包含进来
  • 4、分区表中无法使用外键约束
  • 5、需要对现有表的结构进行修改
  • 6、所有分区都必须使用相同的存储引擎
  • 7、分区函数中可以使用的函数和表达式会有一些限制
  • 8、某些存储引擎不支持分区
  • 9、对于MyISAM的分区表，不能使用load index into cache
  • 10、对于MyISAM表，使用分区表时需要打开更多的文件描述

4.2 分库分表的原理

• 工作原理

  • 通过一些 hash 算法或者工具实现将一张数据表垂直或者水平进行物理切分。

• 适用场景

  • 单表记录条数达到百万或者千万级别时
  • 解决表锁的问题

• 分表方式

  • 水平分割
  • 垂直分表

• 分库分表缺点

  • 有些分表的策略基于应用层的逻辑算法，一旦逻辑算法改变，整个分表逻辑都会改变，扩展性较差
  • 对于应用层来说，逻辑算法无疑会增加开发成本

4.2.1 水平分表

• 定义：表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度

• 使用场景

  • 表中的数据本身就有独立性，例如表中分别记录各个地区的数据或者不同时期的数据，特别是有些数据常用，有些不常用，比如切分历史数据和活跃数据
  • 需要把数据存放到多个介质上

• 缺点

  • 给应用增加复杂度，通常查询时需要多个表名，查询所有数据都需要 union 操作
  • 在许多数据库应用中，这种复杂性会超过带来的优点，查询时会增加读一个索引层的磁盘次数

4.2.2 垂直分表

• 定义：把主键和一些列放在一张表，然后把主键和另外的列放在另一张表中

• 使用场景

  • 表中某些列常用，而另外一些列不常用
  • 可以使数据行变小，一个数据页能存储更多数据，查询时减少 I/O 次数

• 缺点

  • 管理冗余列，查询所有数据都需要JOIN操作

4.3 MySQL的复制原理及负载均衡

• MySQL 主从复制工作原理
  
  • 在主库上把数据更改记录到二进制文件（即所有的写操作都记录到binlog）
  • 从库将主库的日志复制到自己的中继日志
  • 从库读取中继日志中的事件，将其重放到从库数据中，即执行了日志中的 SQL 语句

• 解决了哪些问题？

  • 数据分布：随意停止或开始复制，并在不同地理位置分布数据备份
  • 负载均衡：降低单个服务器的压力
  • 高可用和故障切换：帮助应用程序避免单点失败
  • 升级测试：可以使用更高版本的 MySQL 作为从库

• 思考题

  • 设定网站的用户数量在千万级，但是活跃用户的数量只有1%，如何通过优化数据库提高活跃用户的访问速度？
  • 答：我们可以根据用户的活跃程度，把活跃的用户提取出来放到另外一张表里面，每次活跃的用户登陆的时候就直接到活跃用户表中进行查询，这样就提高了数据库的查询速度。

4.4 MySQL安全性

4.4.1 SQL查询的安全方案

• 1、使用预处理语句防SQL注入
• 2、写入数据库的数据要进行特殊字符的转义
• 3、查询错误信息不要返回给用户，将错误记录到日志

4.4.2 MySQL的其他安全设置

• 1、定期做数据备份
• 2、不给查询用户root权限，合理分配权限
• 3、关闭远程访问数据库权限
• 4、修改root口令，不用默认口令，使用较复杂的口令
• 5、删除多余的用户
• 6、改变root用户的名称
• 7、限制一般用户浏览其他库
• 8、限制用户对数据文件的访问权限

引用资料

• PHPWeb开发相关知识学习记录 - CSDN博客
• MySQL 分区分表 | 邹志鹏’s blog
• 学习 MySQL（一） · Issue #5 · luisedware/Archives