MYSQL

索引

B+ Tree 原理

• 数据结构

  • B Tree 指的是 Balance Tree，也就是平衡树。平衡树是一颗查找树，并且所有叶子节点位于同一层
  • B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现，它具有 B Tree 的平衡性，并且通过顺序访问指针来提高区间查询的性能。

• 操作

  • 进行查找操作时，首先在根节点进行二分查找，找到一个 key 所在的指针，然后递归地在指针所指向的节点进行查找。直到查找到叶子节点，然后在叶子节点上进行二分查找，找出 key 所对应的 data

• 与红黑树的比较

  • B+ 树有更低的树高
  • B+ 树更适合磁盘数据的读取

MySQL 索引

• B+Tree 索引

  • 大多数 MySQL 存储引擎的默认索引类型

  • 因为 B+ Tree 的有序性，所以除了用于查找，还可以用于排序和分组

  • 分为主索引和辅助索引

    • 主索引的叶子节点 data 域记录着完整的数据记录，这种索引方式被称为聚簇索引。因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引
    • 辅助索引的叶子节点的 data 域记录着主键的值，因此在使用辅助索引进行查找时，需要先查找到主键值，然后再到主索引中进行查找

• 哈希索引

  • 哈希索引能以 O(1) 时间进行查找，但是失去了有序性

    • 无法用于排序与分组
    • 只支持精确查找，无法用于部分查找和范围查找

  • nnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找

• 全文索引

  • MyISAM 存储引擎支持全文索引，用于查找文本中的关键词

• 空间数据索引

  • MyISAM 存储引擎支持空间数据索引（R-Tree），可以用于地理数据存储
  • 必须使用 GIS 相关的函数来维护数据

索引优化

• 独立的列

  • 在进行查询时，索引列不能是表达式的一部分，也不能是函数的参数，否则无法使用索引

• 多列索引

  • 在需要使用多个列作为条件进行查询时，使用多列索引比使用多个单列索引性能更好

  • 索引列的顺序

    • 让选择性最强的索引列放在前面

    • 索引的选择性是指：不重复的索引值和记录总数的比值

      • SELECT COUNT(DISTINCT field)/COUNT(*)

• 前缀索引

  • 对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符
  • 前缀长度的选取需要根据索引选择性来确定

• 覆盖索引

  • 索引包含所有需要查询的字段的值

索引的优点

• 大大减少了服务器需要扫描的数据行数
• 帮助服务器避免进行排序和分组，以及避免创建临时表（B+Tree 索引是有序的，可以用于 ORDER BY 和 GROUP BY 操作。临时表主要是在排序和分组过程中创建，不需要排序和分组，也就不需要创建临时表）
• 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，会将相邻的数据都存储在一起）

索引的使用条件

• 对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效

• 但是对于特大型的表，建立和维护索引的代价将会随之增长

  • 需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术

查询性能优化

使用 Explain 进行分析

• select_type : 查询类型，有简单查询、联合查询、子查询等
• key : 使用的索引
• rows : 扫描的行数

优化数据访问

• 减少请求的数据量

  • 只返回必要的列：最好不要使用 SELECT * 语句。
  • 只返回必要的行：使用 LIMIT 语句来限制返回的数据
  • 缓存重复查询的数据

• 减少服务器端扫描的行数

  • 最有效的方式是使用索引来覆盖查询

重构查询方式

• 切分大查询

  • 一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询

• 分解大连接查询

  • 将一个大连接查询分解成对每一个表进行一次单表查询，然后在应用程序中进行关联

  • 好处有

    • 让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用
    • 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询
    • 减少锁竞争
    • 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可伸缩
    • 询本身效率也可能会有所提升

切分

Sharding 策略

• 哈希取模：hash(key) % N
• 范围：可以是 ID 范围也可以是时间范围
• 映射表：使用单独的一个数据库来存储映射关系

Sharding 存在的问题

• 事务问题

  • 使用分布式事务来解决，比如 XA 接口

• 连接

  • 可以将原来的连接分解成多个单表查询，然后在用户程序中进行连接

• ID 唯一性

  • 使用全局唯一 ID（GUID）
  • 为每个分片指定一个 ID 范围
  • 分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)

复制

主从复制

• 主要涉及三个线程

  • binlog 线程 ：负责将主服务器上的数据更改写入二进制日志（Binary log）中。
  • I/O 线程 ：负责从主服务器上读取二进制日志，并写入从服务器的中继日志（Relay log）。
  • SQL 线程 ：负责读取中继日志，解析出主服务器已经执行的数据更改并在从服务器中重放（Replay）。

读写分离

• 主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。

• 提高性能的原因在于

  • 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
  • 从服务器可以使用 MyISAM，提升查询性能以及节约系统开销；
  • 增加冗余，提高可用性。