网盘资料链接地址：链接：https://pan.baidu.com/s/1KpqfII6odIZDwcCz8OkeMg 提取码：3452

一、mysql逻辑架构

1.1、架构图

总结：和其它数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

二、七种join理论(重点)

三、 常用命令

四、mysql的安装位置

五、索引

5.1 索引的本质

排好序的快速查找数据结构(存储于硬盘)

5.2 索引的类型

缺少一个主键索引：主键索引就是唯一索引，但是不包含null值

5.3 索引的原理

5.3.1 查找过程

如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。
查找过程：

5.3.2 btree总结

总结：真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

5.4 哪些情况适合用来建索引

5.5 哪些情况不适合用来建索引

5.6 explain 优化 (查看性能)

5.6.1 id（*）

排序总结：

5.6.2 select_type

数据类型：比如简单查询，复杂查询，衍生查询， 子查询等

5.6.3 type（*）

5.6.4 possible_keys 和key（*）

possible_keys ：代表可能出现的索引（会将可能出现的索引都显示出来）
key：当前语句实际用到的索引

5.6.5 ref

显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。

5.6.6 rows

rows列显示MySQL认为它执行查询时必须检查的行数。越少越好！

5.6.7 extra

5.7 索引分析（单表，双表，三表）

如果双表，则left join 右边的查询字段加索引可以提高查询速度
如果三表，则left join 2个右边的查询字段加索引可以提高查询速度
总结：小表驱动大表，大表的查询条件加索引

5.8 索引失效（避免索引失效的注意点!）

1. 全值匹配我最爱
2. 最佳左前缀法则（如果索引了多例，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。）--------------------------------------这个最重要（带头大哥不能死，中间兄弟不能断！）
3. 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描（where后面加的索引条件的字段上不要加计算、函数等）
4. 存储引擎不能使用索引中范围条件右边的列(范围右边全失效，例如age > 18 and name = ‘jarry’, 这里的and 后面就失效了，因为前面是范围)。
5. 尽量使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减少select
6. mysql在使用不等于（！=或者<>）的时候无法使用索引会导致全表扫描
7. is null,is not null 也无法使用索引
8. like以通配符开头（‘$abc…’）mysql索引失效会变成全表扫描操作(a、百分号like加右边；b、如果两边都要加%，则使用覆盖索引，也就说从索引中获取数据)
9. 字符串不加单引号索引失效
10. 少用or,用它连接时会索引失效*
总结：
【优化总结口诀】
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
Like百分写最右，覆盖索引不写星；
不等空值还有or，索引失效要少用；
VAR引号不可丢，SQL高级也不难！

覆盖索引

查询出来的列要被索引所覆盖，意思是从索引中获取需要的数据

5.9对于索引的一般性建议

六、查询截取分析

6.1 查询优化

6.1.1 小表驱动大表

1. left join 这种的，保持左边的表的数据比右边的表的数据小
2. exist 和 in的区别：
   in：右边的括号里面的表比外表的表小
   exist：右边括号里面的表只会返回true或者false，左边（外面）的表比括号里面的表小

6.1.2 order by 优化

6.1.3 group by 优化

同 6.1.2的图，只是比它多了一个

where高于having,能写在where限定的条件就不要去having限定了。

6.2 慢日志查询

总结：慢日志查询是dba或者运维经理的活；慢日志查询需要手动开启，上线之后通过慢日志查询到哪些sql查询速度慢，可以准确定位到sql，然后解决优化。

6.3 批处理sql脚本（未完成–讲解有点烦，之后研究）

6.4 show profiles

1、如果explain、慢日志都不能找到问题，那么使用更加精细的show profiles 。显示效果如下图：
2、但是在show profiles之前需要先开启，使用命令如下：

七、锁

7.1 表锁

7.1.1 读锁

开启2个窗口进行加锁和解锁的测试：
窗口1：

窗口2：

7.1.2 写锁

写锁为我独尊，加写锁的时候，读和写操作一方执行的时候，另一方需要等待，直到获取锁。

7.1.3 总结

重要：

7.2 行锁(innobd默认是表锁，测试的时候开启手动提交进行测试)

对表的行进行加锁

7.3 索引失效，行锁变表锁

开启手动提交，更新字段值时，将字符串类型写成数字类型，虽然mysql底层会做处理，但是会将行锁变成表锁

7.4间隙锁的危害

一个事务更新一个范围里面的数据，另一个事务更新范围里面的数据需要等待。

7.5 面试题：如何锁定一行

1、begin
2、查找需要锁定的那条数据，然后后面加上for update。（其他事务执行的时候，都会进行等待，直到commit执行完成）
3、做完事情之后，commit提交

7.6 系统上的行锁争夺情况

命令：show status like ‘innodb_row_lock%’;

7.7 优化建议

八、主从复制（特别繁琐）