Mysql
2021-09-04 11:52:53 0 举报AI智能生成
Mysql
作者其他创作
大纲/内容
锁
共享锁
独占锁
索引
分类
聚簇索引
叶子节点存放数据
覆盖索引
并非索引，而是在索引中就可以拿到数据，不需要回表到主键聚簇索引，就是覆盖索引
联合索引
多个字段联合作为二级索引B+树的索引值，也是二分法找到对应的主键ID，然后回表查询主键的聚簇索引
全覆盖索引
单列索引
匹配原则
全值匹配
完全匹配索引值肯定是可以走索引的
最左列匹配
只用联合索引的最左边的字段，也是可以走索引的
最左前缀匹配
像like ‘123%’，如果条件是索引最左列，索引也生效
范围查找
对索引最左列进行范围查找也是可以走索引的
等值匹配+范围匹配原则
最左列全值匹配之后，紧接着的第一个索引列的范围查找也走索引，但是第二个范围查找是不走索引的
排序原则
联合索引字段多个使用order by 要么都是ASC 要么都是DESC，否则索引失效
设计原则
按照where、order by 、group by最常用的字段进行设计
选择基数比较大字段（这样才能发挥出二分法的优势）
字段比较长的字段，可以使用前缀索引，只取字段前面少数作为索引，但是对于order by语句就不能用上索引了
索引不要建立太多，否则维护多个索引树的性能会非常差
一般情况下不建议使用UUID，否则导致聚簇索引频繁地页分裂
失效场景
索引字段计算
没按照最左匹配
in/not in语句
执行计划Type
Const
主键或者唯一索引访问，速度为常量级
ref
普通索引，或者主键和唯一索引使用了null的判断
ALL
全表扫描，速度很慢
range
基于索引的范围来查询的
index
查询的字段就在二级索引内，不需要回表去查聚簇索引，但是速度仍然比全表扫描快
主从架构
中间件
mycat
sharding-sphere
同步方式
半同步复制方式
保证从库收到信息之后再提交主库的事务
两种方式
GTID
异步方式
主库发送binlog给从库就自己提交事务，并不关心从库是不是收到信息了。有数据丢失风险
故障问题
延迟问题
从库并行复制
强制对主库读取数据
故障转移
MHA技术
Mysql
术语
行溢出
每个字段类型只能容纳65532个字符，一旦超过，就需要以链表的形式指向其他的数据页来共同存储这一份数据
RAID
名为磁盘冗余阵列，为了管理多个磁盘的一种硬件管理技术
事务隔离级别
读未提交
避免脏写
读已提交
避免脏写脏读
可重复读
避免脏写、脏读、不可重复读
可串行化
串行执行不会有问题
多事务并发问题
脏写
触发事件
事务A、B先后更新同一数据，A在靠undo log回滚事务的时候覆盖了B的值
解决方案
锁机制
脏读
先后查询事务A修改过和回滚过的数据，得到的数据不一样
undo log+ReadView(多次查询都生成不同的)
不可重复读
事务执行期间多次查询同一数据，由于多次被其他事务修改，导致多次查询结果不一样
undo log+ReadView
幻读
同一查询条件搜索出来的结果数据不一样，比如数量不一样
调优
外框
禁用半连接
优化SQL结构
Mysql可能在分析过程当中自动更改执行索引，在聚簇索引查不到的情况下进行全表扫描，进而导致速度很慢，这时候需要强制指定索引列
减少回表次数
先查询条件内的ID，再通过主键去聚簇索引获取数据
索引下推
分库分表
单表数据量控制在1千万内
分页查询，采用多加字段属性在索引映射表内，或者ES实现搜索
索引顺序扫描
索引列顺序与order by顺序一致
所有列的顺序一致
如果关联多表，那么只有当 ORDER BY 子句引用的字段全部为第一张表时，才能使用索引做排序，限制依然是需要满足索引的最左前缀要求
减少重复索引
内存
日志
redo log
为何使用redo log而不是缓存页直接更新？1、缓存页16KB，而且随机写磁盘的性能非常慢2、redo log一行占用小3、顺序写redo log，速度快
格式大致：表空间号+数据页号+偏移量+修改几个字节的值+具体的值
redo log并非一行一行日志直接更新刷入磁盘，类似于数据页存放数据redo log需要一个redo log block(512kb)来保存
undo log
无非是记录一份数据能恢复之前的数据，可看undo log流程图
0 条评论
回复 删除
下一页
