你要的全在下面:数据库已经有4代了产品很多。
DBA课程更新内容大纲:
序章 DBA职业体系与数据库产品趋势
What is DBA?
DBA成长体系与职业方向(0-30W-50W-100W-???)
数据库发展历史,产品迭代趋势与职业学习方向
第一部分 OLTP数据库-MySQL(约1天)
MySQL基础入门
MySQL数据库简介
什么是数据库?什么是OLTP?
为什么学习MySQL?MySQL产品迭代
一二线大厂MySQL主流版本功能使用与特性介绍(5.1,5.6,5.7,8.0)**独家**
MySQL部署与管理体系
5.7,8.0版本企业规范部署,启动
MySQL管理体系讲解
MySQL产品架构分析与基础管理
MySQL基础架构解析(一条SQL是如何执行的)
MySQL启动过程
MySQL连接的生命与使命
MySQL表结构实现原理
MySQL开发应用(约1.5天)
MySQL SQL基础应用
声明式式语言与SQL语言
SQL语言应用场景与sqlmode
MySQL开发工具选择与使用
MySQL字符串类型与字符集
MySQL语句类型介绍(DDL,DCL,DML,DQL)
SQL之查询基础
SQL之聚合与排序
SQL之数据更新
SQL之复杂查询
SQL之集合运算
MySQL SQL高级处理与开发
函数开发与应用
存储过程,触发器,事件
表分区管理及企业级应用场景
Online DDL解析与开源生态OPS
窗口函数讲解及应用场景
MySQL JSON开发及应用
一二线大厂MySQL企业级开发规范详解**独家**
MySQL核心技术
MySQL InnoDB索引实现原理及执行计划分析(约0.5天)
索引介绍
1. 索引的由来
2. 表和索引结构
3. 表聚簇与索引行
4. 表行与索引组织表
MySQL索引介绍
InnoDB索引B+ tree的索引设计
聚簇索引与二级索引
InnDB索引插入过程
数据类型对索引应用的使用影响
执行计划介绍及结果剖析
索引优化基础实战演练
企业级索引优化实战案例(亿万级QPS的索引优化与索引上线)**独家**
MySQL InnoDB存储引擎技术内幕与深入讲解(约1天)
Mysql存储引擎介绍与功能特性
InnoDB引擎源代码目录结构与存储引擎文件组织
InnoDB存储引擎核心架构介绍及解析
InnoDB数据存储结构
InnoDB事务详解及ACID特性解析
InnoDB 日志管理机制Undo与Redo
InnoDB事务与隔离级别
InnoDB MVCC及锁机制
MySQL日志管理与实战(0.5)
General log详解
Error log详解
企业级Binary log with Data pipeline **独家**
企业级Slowlog场景应用**独家**
MySQL备份恢复与迁移(0.5)
备份工具介绍与使用场景解析
一二线大厂过万数据节点备份策略**独家**
一二线大厂Mysqldump核心原理与企业级实战演练**独家**
一二线大厂Xtrabackup核心原理与企业级实战演练**独家**
Enterprise Backup企业级生态工具介绍与应用
MySQL主从复制深入(约1天)
主从复制简介与简单搭建
主从复制工作原理解析
主从数据一致性方案讲解(半同步,全同步)
MySQL主从复制实战
1. 延时复制
2. 过滤复制
3. 多源复制
MySQL GTID复制
企业级主从复制故障分析与处理方案
亿级QPS MySQL节点故障转移实战案例**独家**
MySQL高可用架构(1天)
一二线大厂过万集群规模高可用架构MHA+BLB企业级实战**独家**
Mycat,DBLE企业级实战
MySQL企业级优化与实战(约1天)
打造高性能MySQL
企业级MySQL参数优化实战**独家**
企业级T0级别故障案例解析**独家**
阿里云数据库产品(RDS与PolarDB)(选修二选一) (1天)
企业级RDS介绍,使用与故障案例(百度云RDS 运维DBA分享或交流)**独家**
企业级PolarDB业务场景解析(阿里团队PolarDB P7交付架构师分享或交流)**独家**
第二部分 NoSQL
Redis核心技术(2天)
Redis产品介绍与应用场景简析
Redis安装,部署,使用
Redis数据类型详解与应用
Redis集群架构讲解与实战(哨兵,cluster)
千亿级Redis集群参数优化实战**独家**
千亿级企业级Redis核心案例讲解与业务场景解析**独家**
MongoDB核心技术(2天)
MongoDB产品介绍与应用场景简析
MongoDB安装,部署及架构解析
MongoDB数据类型与运维管理
MongoDB集群架构讲解与实战
企业级MongoDB参数优化实战**独家**
BAT千万元级别故障案例分享**独家**
ES核心技术(2天)
ES产品介绍与应用场景简析
ES安装,部署及架构解析
ES日常运维管理
第三部分 NewSQL(4天)
NewSQL-TiDB(仅学此一个+MySQL至少20K起步) TUG核心成员-PingCAP官方认证讲师 **独家**
TiDB产品介绍与分布式数据库技术应用讲解
TiDB集群部署与日常管理
TiDB集群监控详解与指标应用
TiDB核心架构深入讲解与Raft协议深入浅出**独家*
企业级TiDB-DM理解与应用**独家*
1. 58同城亿级流量Mysql热迁移TiDB**独家**
2. DM集群多源同步复制场景最佳实践(官方认证,业界唯二)**独家**
TiDB企业级业务开发最佳实践**独家**
TiFllash核心架构讲解与实战**独家**
TiDB打造HTAP实时数仓平台架构设计**独家**
Cloud TiDB(K8S上云实战)**独家**
TiDB4.0热升级5.0集群(简介:我司与Pingcap官方{开发30人,交付专家7人,项目经理4人}封闭测试与在线升级全案例解析6.23日项目完结,官方认证业界目前第一的业务场景与投入)
NewSQL-TDengine(1天 选修)
TDengine产品介绍
TDengine单机版与集群部署与管理
TDengine架构体系详解
TDengine企业级参数优化与实战
TDengine业务开发规范与业务场景实战
第四部分 企业级大规模数据库集群运维开发实战(35W+年薪提升)**独家**
数据运维产品架构设计思路(0.5天)
什么是数据运维平台
企业级数据运维平台架构解析
数据运维平台企业级原型设计实战(0.5天)
数据库运维自动化工具开发(Shell,Python)(2天5选2,下期轮换)
MySQL亿万级流量运维平台开发
Redis亿万级流量运维平台开发
ES亿万级流量运维平台开发
MongoDB亿万级流量运维平台开发
TiDB亿万级流量运维平台开发
之前在网上看到过很多关于mysql联合索引最左前缀匹配的文章,自以为就了解了其原理,最近面试时和面试官交流,发现遗漏了些东西,这里自己整理一下这方面的内容。
最左前缀匹配原则
在mysql建立联合索引时会遵循最左前缀匹配的原则,即最左优先,在检索数据时从联合索引的最左边开始匹配,示例:
对列col1、列col2和列col3建一个联合索引
KEY test_col1_col2_col3 on test(col1,col2,col3)
联合索引 test_col1_col2_col3 实际建立了 (col1)、(col1,col2)、(col,col2,col3) 三个索引。
SELECT * FROM test WHERE col1=“1” AND clo2=“2” AND clo4=“4”
上面这个查询语句执行时会依照最左前缀匹配原则,检索时会使用索引(col1,col2)进行数据匹配。
注意
索引的字段可以是任意顺序的,如:
SELECT * FROM test WHERE col1=“1” AND clo2=“2”
SELECT * FROM test WHERE col2=“2” AND clo1=“1”
这两个查询语句都会用到索引(col1,col2),mysql创建联合索引的规则是首先会对联合合索引的最左边的,也就是第一个字段col1的数据进行排序,在第一个字段的排序基础上,然后再对后面第二个字段col2进行排序。其实就相当于实现了类似 order by col1 col2这样一种排序规则。
有人会疑惑第二个查询语句不符合最左前缀匹配:首先可以肯定是两个查询语句都保函索引(col1,col2)中的col1、col2两个字段,只是顺序不一样,查询条件一样,最后所查询的结果肯定是一样的。既然结果是一样的,到底以何种顺序的查询方式最好呢?此时我们可以借助mysql查询优化器explain,explain会纠正sql语句该以什么样的顺序执行效率最高,最后才生成真正的执行计划。
减少开销 。建一个联合索引(col1,col2,col3),实际相当于建了(col1),(col1,col2),(col1,col2,col3)三个索引。每多一个索引,都会增加写 *** 作的开销和磁盘空间的开销。对于大量数据的表,使用联合索引会大大的减少开销!
覆盖索引 。对联合索引(col1,col2,col3),如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么MySQL可以直接通过遍历索引取得数据,而无需回表,这减少了很多的随机io *** 作。减少io *** 作,特别的随机io其实是dba主要的优化策略。所以,在真正的实际应用中,覆盖索引是主要的提升性能的优化手段之一。
效率高 。索引列越多,通过索引筛选出的数据越少。有1000W条数据的表,有如下sql:select from table where col1=1 and col2=2 and col3=3,假设假设每个条件可以筛选出10%的数据,如果只有单值索引,那么通过该索引能筛选出1000W10%=100w条数据,然后再回表从100w条数据中找到符合col2=2 and col3= 3的数据,然后再排序,再分页;如果是联合索引,通过索引筛选出1000w10% 10% *10%=1w,效率提升可想而知!
引申
对于联合索引(col1,col2,col3),查询语句 SELECT * FROM test WHERE col2=2是否能够触发索引?
大多数人都会说NO,实际上却是YES。
原因:
EXPLAIN SELECT * FROM test WHERE col2=2
EXPLAIN SELECT * FROM test WHERE col1=1
观察上述两个explain结果中的type字段。查询中分别是:
index: 这种类型表示mysql会对整个该索引进行扫描。要想用到这种类型的索引,对这个索引并无特别要求,只要是索引,或者某个联合索引的一部分,mysql都可能会采用index类型的方式扫描。但是呢,缺点是效率不高,mysql会从索引中的第一个数据一个个的查找到最后一个数据,直到找到符合判断条件的某个索引。所以,上述语句会触发索引。
ref: 这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引,而不是会对索引中每一个数据都进行一一的扫描判断,也就是所谓你平常理解的使用索引查询会更快的取出数据。而要想实现这种查找,索引却是有要求的,要实现这种能快速查找的算法,索引就要满足特定的数据结构。简单说,也就是索引字段的数据必须是有序的,才能实现这种类型的查找,才能利用到索引。
以上所述是我给大家介绍的Mysql联合索引最左匹配原则,希望对大家有所帮助,如果大家有任何疑问请给我留言,我会及时回复大家的。
《 两个月拿到N个offer,看看我是如何做到的 》
《 面试总结:2019年最全面试题资料学习大全—(含答案) 》
《 淘宝面试回来,想对程序员们谈谈 》
《 看过太多大厂面试题,其实考的无非是这 3 点能力 》
在 Mysql 5.6 之前版本中 , 如果要修改一个表的ddl信息 ,需要锁表 。
具体步骤如下:
下面是Mysql官方文档对于DDL *** 作的总结:
http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html
http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html
可以使用 Alter 语句支持 DDL 特性 ,比如可以用 LOCK = NONE 无锁变更。
percona是一个开源产品 , 是管理Mysql的工具。
PT-OSC(Percona Toolkit Online Schema Change)
https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html
Percona Toolkit 包含很多 mysql 管理的功能 ,现在要说的是 online-schema-change上
PT-OSC 原理是建表 ,使用触发器同步数据 ,然后原子性rename。
这样可以支持在线无锁,不停机Online-DDL 。
具体步骤如下:
Percona 有一些限制和缺陷 ,根据它的原理 ,原表不能存在触发器 ,这玩意是唯一。另外原表必须存在PK或者UK。另外就是触发器的问题了,触发器带来性能开销,并且无法停止,那我就不能控制我同步的开关和速度。
但是gh-ost说它可以。
https://github.com/github/gh-ost
go-ost基于bin-log同步 , 基于binlog肯定都是伪装成一个replica。
由于使用单线程回放binlog来替换触发器,所以增量DML回放效率不如触发器,因为pt-osc的增量回放并发度是与业务DML并发度相同的,是多线程的。
相对于percona的优势是:
因为出的太晚了 ,然后percona 和 gh-ost等等开源产品已经大规模实践了,Mysql就更加没什么实践案例和经验了,大家就不太愿意尝试或者迁移了。
大厂来说基本上都是平台封装了,类似idb ,会把无锁变更细节屏蔽了,只需要提工单就可以了 ,但是底层基本上也是建表同步rename个思路。
小公司的话,可以使用percona 、 go-ost 等工具。
MySQL 8.0 Online DDL和pt-osc、gh-ost深度对比分析
Mysql Online DDL
pt-online-schema-change
gh-ost
MySQL5.6在线表结构变更(online ddl)总结
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)