MYSQL海量数据存储与优化

mysql的体系架构

主存的高可用架构可以自己搭建一下

开缓存 不一定就能提高效率

存储引擎

作用：读取内存内容

系统文件：db innodb

文件和日志：事务 借助哪个 日志文件 redo 还是 undo

为什么系统数据库崩溃了，还能恢复数据

Query and Slow 慢查询

第四节MySql运行机制

mysql的通讯机制：

全双工：

单双工

2. 查询缓存：开不开具体看情况，如果有查询到相同的sql语句，就直接返回回去，反之。

• 即使开启缓存，一下sql也不能缓存
• 查询语句使用

3. 解析器：检查当前语句是否合法
4. 查询优化器：根据解析树生成最优的执行计划 ，有许多优化机制：不一一举例了。

• show profiles – 查询一条sql语句的耗时情况
• in的优化：会先进行排序，在采用二分法查找数据

第五节MySql的存储引擎

面试题：innodb和myisam的区别？

1.事务和外键
2.锁机制
3.索引结构
4.并发处理能力
5.存储文件
1
2
3
4
5

默认使用的是innoDB 5.5版本之后 之前使用的是 myisam

位于第三层，负责mysql中的数据的存储和提取，可插拔式的储存引擎

• innoDB：支持事务，具有提交，回滚和崩溃恢复能力，提供行锁，事务安全

• myisAM：不支持事务和外键，访问速度快 ，查询不加锁

javaSE：

jvm GC hashMap 设计模式 多线程（线程池）juc 类/方法/调用/参数的传递/结果的接收

hashmap：1.7/1.8区别？ 红黑树？ 数组长度是2的n次min 整理一下hashmap的面试题（拓展开来）

innoDB：减少 存储引擎 和 磁盘 之间的 io次数 因为他有缓存机制 changebuffer ：当更新一条记录时，如果该记录在bufferpool里面，就直接进行操作。当下次查询时，会先进行磁盘读取，然后再从changebuffer中读取信息合并，最终载入bufferpool中 提高dml操作效率

自适应哈希索引（apdapter hash index）：将经常需要查询的数据（热点数据） 再建立一个哈希索引 时间复杂度就是 o（1）

bufferpool：缓存表里的数据到内存当中，先从内存中取

logbuffer：

redolog：重做日志 用于在崩溃恢复期间更正不完整事务写入的数据，因为在sql操作之前，先进行日志操作。

undolog：撤销日志 在事务开始之气保存被修改的数据的备份

第六节索引类型

索引：类似于一本书的目录，提升查询这本书中的章节的效率

​ 索引会占据单独的书页：每个章节和页码（位置）建立了对应关系，存储到目录所在的书页中。

数据库中的索引：一种提高我们查询数据的效率的数据结构，

​ 本质是一个文件，文件中使用指定的数据结构（b+）对我们的索引列进行存储，单独开辟一块空间。

数据结构：提升查询效率 存储列的信息

100条数据：

id= 55；

mysql优化：索引

innoDB存储引擎：数据+索引在一起的，在同一个文件中

索引可以提升查询速度，会影响where查询以及order by排序。

缺点：

1. 占据专门的磁盘

2. 索引需要维护，不适合频繁更新的列上创建索引

3. 数据量比较小的表，不建议创建索引

涉及到索引迁移的话会把索引删除，提升迁移速度

• 索引存储结构：
• 应用层次划分：

1.1普通索引

这是最基本的索引类型，基于普通的字段建立的索引，没有任何限制。

1.2唯一索引

unique

1.3主键索引

primary key

1.4复合索引

constraint pk_id_name primary key（id，name）；

如果当前已经在一个表上建立了索引

最左匹配原则：

1.5全文索引：不如ES

对某列中的数据建立全文索引：某列中存储了大量的数据，模糊查询的方式去查询某列中是否包含指定的关键字。

第七节索引原理

二分法查找法：

hash结构：

2.4 聚簇索引和辅助索引

​

专有的sql优化的场景

1.查询慢查询地址，定位时间较长的sql

2.使用explain查询，查询 给分析一下整体的耗时

3.索引 上面的内容

innodb查询效率高的？？？？

数据结构 ： b+树

算法：二分法查找 自适应哈希索引 ---- 查询效率比较高