存储引擎
innodb：支持事务、行级锁、在线热备份。采用MVCC来支持高并发，四个标准隔离级别：读已提交，读未提交，可重复读，串行化，默认是RR可重复读，主索引是聚簇索引
索引
B树=Balance Tree
B+树是Btree的一种变形，叶子节点多了顺序访问的指针。数据存储在叶子节点，对于内部节点（索引节点）的一个key，左子树小于它，右子树大于等于它–如图
树的常见特性
AVL树：平衡二叉树，通过平衡因子差值进行旋转达到平衡，左右子树树高相差不超过1，旋转耗2. 时，所以适合插入/删除较少的场景
红黑树：通过节点的颜色进行约束达到近似平衡，没有AVL树这么严格，旋转次数相对较少，适合插入/删除较多的场景
B/B+树：多路查找树，磁盘IO低，适用于数据库
B+树和红黑树比较：B+树一个节点可以存储多个元素，树相对更矮，所以IO次数较少
B+树与B树比较：1、B+树磁盘IO更少 2、B+树更稳定（节点存数据） 3、遍历效率更高，范围查找更快（叶子节点排序指针）
MySql索引
索引是存储引擎实现，不同引擎有不同索引
B+树：
Mysql默认索引类型，查询块，稳定，数据有序：范围和遍历更快，排序和分组
理解这句话：B+树分聚簇索引（主键索引）和辅助索引（普通索引）一个表只能有一个聚簇索引，因为数据只存一份在叶子节点。辅助索引data域中不存数据，存主键的值，查找到后还需要回表查询主键。
解释：
回表：普通索引不存数据，查找到主键值后，还需要从新查一次表
聚簇索引：
（1）如果表定义了PK，则PK就是聚集索引
（2）如果表没有定义PK，则第一个not NULL unique列是聚集索引
（3）否则，InnoDB会创建一个隐藏的row-id作为聚集索引
哈希索引：
时间复杂度O(1)，失去有序性，无法排序分组，只能精确查找—如果某个键被用的非常频繁，innodb会在索引上创建哈希索引。
还有全文索引，空间数据索引。
索引优化
- 独立的列：索引列不能是表达式的一部分或作为函数参数。
- 多列索引：多列索引比使用多个单列索引性能更好。
- 索引列顺序：选择性强的放前面，如id。选择性不强的放后面，如：性别
- 索引列的顺序： BLOB、TEXT 和 VARCHAR 类型的列使用，%放后面
- 覆盖索引：索引包含所有需要查询的字段的值。如innodb可以减少回表查询
索引优点
-
大大减少了服务器需要扫描的数据行数。
-
帮助服务器避免进行排序和分组，以及避免创建临时表（B+Tree 索引是有序的，可以用于 ORDER BY 和 GROUP BY 操作。临时表主要是在排序和分组过程中创建，不需要排序和分组，也就不需要创建临时表）。
-
将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，会将相邻的数据都存储在一起）。
索引创建要看情况，对于很小的表不需要创建，因为索引可能要回表。
查询性能优化
explain分析
| 字段 | 解释 |
|---|---|
| select_type | 常用的有 SIMPLE 简单查询，UNION 联合查询，SUBQUERY 子查询等。 |
| table | 要查询的表 |
| possible_keys | 可选择的索引 |
| key | 实际使用的索引 |
| rows | 扫描的行数 |
| type | 索引查询类型，经常用到的索引查询类型：system > const > eq_ref > ref > range > index > all 性能从左往右越来越差 |
system:表只有一行，这是一个 const type 的特殊情况
const：使用主键或者唯一索引进行查询的时候只有一行匹配
eq_ref :唯一性索引扫描，对于每个索引，表中只有一条记录与之匹配，常见于主键或唯一索引扫描
ref：使用非唯一索引
range：使用主键、单个字段的辅助索引、多个字段的辅助索引的最后一个字段进行范围查询
index：和all的区别是扫描的是索引树
all：扫描全表
优化查询方式
切分大的查询：范围过大的增删改，防止占满事务，锁定过多数据
分解大连接的查询：让缓存更高效。让缓存更高效。
事务
ACID：原子性，一致性，隔离性，持久性
并发情况需要同事满足原子性和隔离性，才能满足一致性
隔离级别
锁
锁类型：
共享锁（S Lock）:允许事务读一行数据
排他锁（X Lock）:允许事务删除或者更新一行数据
锁算法：
- Record Lock（行锁）：锁定一个记录上的索引，而不是记录本身。
- Gap Lock（间隙锁）：锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE; 其它事务就不能在 t.c 中插入 15。
- Next-Key Lock(1+2)：锁定一个范围，并且锁定记录本身。对于行的查询，都是采用该方法，主要目的是解决幻读的问题。
锁问题：
脏读：当前事务读取到其他事务未提交的数据
不可重复读：
幻读：同一个事务两题查询出来的数据数量不一样。是一种特殊的不可重复读
更新丢失：
分库分表数据切分
水平切分：
水平切分（Sharding），将同一个表中的记录拆分到多个结构相同的表中。
当一个表的数据不断增多时，Sharding 是必然的选择，它可以将数据分布到集群的不同节点上，从而缓存单个数据库的压力。
策略：
- 哈希取模：hash(key)%N
- 范围：可以是 ID 范围也可以是时间范围
- 映射表：使用单独的一个数据库来存储映射关系
问题：
事务问题：分布式事务解决
连接：分成多个单表查询，通过程序连接
唯一性：使用全局唯一 ID （GUID）。为每个分片指定一个 ID 范围。分布式 ID 生成器（如 Twitter 的 Snowflake 算法）
垂直切分：
垂直切分是将一张表按列分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直气氛将经常被使用的列喝不经常被使用的列切分到不同的表中。
复制
主从复制
主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。
- binlog 线程 ：负责将主服务器上的数据更改写入二进制日志（Binary log）中。
- I/O 线程 ：负责从主服务器上读取- 二进制日志，并写入从服务器的中继日志（Relay log）。
- SQL 线程 ：负责读取中继日志，解析出主服务器已经执行的数据更改并在从服务器中重放（Replay）。
读写分离
主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。
读写分离能提高性能的原因在于：
- 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
- 从服务器可以使用 MyISAM，提升查询性能以及节约系统开销；
- 增加冗余，提高可用性。
读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
设计理论
数据库设计范式：解决数据冗余，数据有效性检查，提高存储效率考虑。但其实工作中为了效率经常不遵循。
第一范式：1NF， 不以集合作为属性值，每个属性都具有原子性不可分割。
第二范式：2NF，每个非主属性完全函数依赖于键码。可以通过分解来满足。
第三范式：3NF，非主属性不传递函数依赖于键码。
数据库缓存（QueryCahce-----QC）
相同SQLID的两条语句，第二次查询会直接从缓存中获取结果，不需要解析SQL，效率极高。
开启数据库缓存----Mysql中添加在配置文件中添加：
# 修改MySQL配置文件/etc/my.cnf，添加如下配置，重启MySQL server即可。
[mysqld]
query_cache_size = 32M
query_cache_type = 1
#禁用QueryCache的配置
query_cache_size = 0
query_cache_type = 0
Update更新数据会锁定QC，再更新QC，如果执行相同的语句无法命中缓存，会重新添加QC
锁定QC->检查QC->添加QC->更新QC非常消耗资源降低数据库的并发处理能力。
因此QC不适合用在数据变化快的业务中，这种情况需要删除QC
8723
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
