面试场景题
一 . 抛出面试问题:联合索引的技巧回答
1、覆盖索引:如果查询条件使用的是普通索引(或是联合索引的最左原则字段),查询结果
是联合索引的字段或是主键,不用回表操作,直接返回结果,减少IO磁盘读写读取正行数据
2、最左前缀:联合索引的最左 N 个字段,也可以是字符串索引的最左 M 个字符
3、联合索引:根据创建联合索引的顺序,以最左原则进行where检索,比如(age,name)
以age=1 或 age= 1 and name=‘张三’可以使用索引,单以name=‘张三’ 不会使用索引,考虑
到存储空间的问题,还请根据业务需求,将查找频繁的数据进行靠左创建索引。
4、索引下推:like 'hello%’and age >10 检索,MySQL5.6版本之前,会对匹配的数据进行回
表查询。5.6版本后,会先过滤掉age<10的数据,再进行回表查询,减少回表率,提升检索速
度
二. 下面两条语句有什么区别,为什么都提倡使用2:
1.select * from T where k in(1,2,3,4,5)
2.select * from T where k between 1 and 5
第一个要树搜素5次
第二个搜索一次
三 . 在设计表结构时,也要以减少资源消耗作为目标,索引设计
实际上主键索引也是可以使用多个字段的。
DBA 小吕在入职新公司的时候,就发现自己接手
维护的库里面,有这么一个表,表结构定义类似这样的:
CREATE TABLE `geek` (
`a` int(11) NOT NULL,
`b` int(11) NOT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
PRIMARY KEY (`a`,`b`),
KEY `c` (`c`),
KEY `ca` (`c`,`a`),
KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;
公司的同事告诉他说,由于历史原因,这个表需要 a、b 做联合主键,这个小吕理解了。
但是,小吕又纳闷了,既然主键包含了 a、b 这两个字段,那意味着单独在字段 c 上创建一个索引,就已经包含了三个字段了呀,为什么要创建“ca”“cb”这两个索引?
同事告诉他,是因为他们的业务里面有这样的两种语句:
select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;
我给你的问题是,这位同事的解释对吗,为了这两个查询模式,这两个索引是否都是必须的?
为什么呢?
解答:
表记录
--a--|--b--|--c--
1 2 3
1 3 2
1 4 3
2 1 3
2 2 2
2 3 4
主键 a,b的聚簇索引组织顺序相当于 order by a,b
也就是先按a排序,再按b排序,c无序
索引 ca 的组织是先按c排序,在按a排序,同时记录主键
--c--|--a--|--主键ab--
2 1 1,3
2 2 2,2
3 1 1,2
3 1 1,4
3 2 2,1
4 2 2,3
索引 cb 的组织是先按c排序,在按b排序,同时记录主键
--c--|--b--|--主键ab--
2 1 2,2
2 3 1,3
3 1 2,1
3 2 1,2
3 4 1,4
4 3 2,3
对于下面的语句
select ... from geek where c=N order by a
走ca,cb索引都能定位到满足c=N主键
而且主键的聚簇索引本身就是按order by a,b排序,无序重新排序。所以ca可以去掉
select ... from geek where c=N order by b
这条sql如果只有 c单个字段的索引,定位记录可以走索引,但是order by b的顺序与主键顺序
不一致,需要额外排序
cb索引可以把排序优化调优。
详细解释为什么不要ca?
InnoDB会把主键字段放到索引定义字段后面,
当然同时也会去重。
所以,当主键是(a,b)的时候,
定义为c的索引,实际上是(c,a,b);
定义为(c,a)的索引,实际上是(c,a,b)
你看着加是相同的
ps 定义为(c,b)的索引,实际上是(c,b,a)
四 . MySQL 5.6 支持online ddl后,对表进行增加字段不会进行阻塞读写吗?
当执行Online DDL操作时,为了保证数据的一致性和可用性,数据库需要使用一种称为MDL(Metadata Lock)的机制来管理对元数据的访问。
拿MDL写锁: 在开始执行DDL操作之前,首先需要获取MDL写锁。这个过程通过向MySQL服务器发送请求并等待获得写锁来完成。当有其他会话已经持有MDL写锁或读锁时,当前会话将被阻塞直到锁被释放。
降级成MDL读锁: 一旦成功获取MDL写锁,可以将其降级为MDL读锁。降级的目的是允许其他会话仍然可以读取表的数据,但不允许进行写操作。这样可以实现在DDL操作期间对表的读取操作仍然能够继续进行。
真正做DDL: 在成功获取MDL读锁后,可以执行实际的DDL操作,例如添加、删除、修改表结构等操作。由于已经获取了MDL读锁,其他会话可以继续读取表的数据,但不能进行写入操作。
升级成MDL写锁: 在DDL操作完成后,可能需要对元数据进行一些更新以确保数据的一致性。为了进行这种更新,需要将MDL读锁升级为MDL写锁。升级MDL锁需要获取到写锁的许可,这会阻塞其他会话对表的读写操作。
释放MDL锁: 当DDL操作已经完成,并且不再需要MDL锁时,可以释放MDL锁。通过释放MDL锁,其他会话就可以继续获得读锁或写锁,并对表进行操作。
Online DDL操作可以通过获取MDL写锁、降级为MDL读锁、执行DDL操作、升级为MDL写锁和最后释放MDL锁的步骤来实现。其中,通过MDL机制,保证了在DDL操作期间数据库的可用性,允许其他会话对表进行读取操作,同时控制并发写入操作。这样可以减少对业务的影响,确保数据一致性。
详细进行"降级成MDL读锁"解释:
降级后仍然可以进行DDL操作。因为在获取MDL写锁时,已经对该表进行了排他性的控制,其他会话无法进行写入操作,但仍然可以进行读取操作。而在降级为MDL读锁后,虽然不能再进行写入操作,但仍然可以进行DDL操作,因为DDL操作不涉及数据的修改,只是修改表的结构。因此,在降级为MDL读锁后,仍然可以执行DDL操作,而其他会话仍然可以进行读取操作。
五 .根据加锁范围:MySQL里面的锁可以分为:全局锁、表级锁、行级锁
一、全局锁:
对整个数据库实例加锁。
MySQL提供加全局读锁的方法:Flush tables with read lock(FTWRL)
这个命令可以使整个库处于只读状态。使用该命令之后,数据更新语句、数据定义语句和更新
类事务的提交语句等操作都会被阻塞。
使用场景:全库逻辑备份。
风险:
1.如果在主库备份,在备份期间不能更新,业务停摆
2.如果在从库备份,备份期间不能执行主库同步的binlog,导致主从延迟
官方自带的逻辑备份工具mysqldump,当mysqldump使用参数--single-transaction的时候,会
启动一个事务,确保拿到一致性视图。而由于MVCC的支持,这个过程中数据是可以正常更新
的。
一致性读是好,但是前提是引擎要支持这个隔离级别。
如果要全库只读,为什么不使用set global readonly=true的方式?
1.在有些系统中,readonly的值会被用来做其他逻辑,比如判断主备库。所以修改global变量
的方式影响太大。
2.在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开,那么MySQ
L会自动释放这个全局锁,整个库回到可以正常更新的状态。而将整个库设置为readonly之
后,如果客户端发生异常,则数据库就会一直保持readonly状态,这样会导致整个库长时间处
于不可写状态,风险较高。
二、表级锁
MySQL里面表级锁有两种,一种是表锁,一种是元数据所(meta data lock,MDL)
表锁的语法是:lock tables ... read/write
可以用unlock tables主动释放锁,也可以在客户端断开的时候自动释放。lock tables语法除了
会限制别的线程的读写外,也限定了本线程接下来的操作对象。
对于InnoDB这种支持行锁的引擎,一般不使用lock tables命令来控制并发,毕竟锁住整个表的
影响面还是太大。
MDL:不需要显式使用,在访问一个表的时候会被自动加上。
MDL的作用:保证读写的正确性。
在对一个表做增删改查操作的时候,加MDL读锁;当要对表做结构变更操作的时候,加MDL写
锁。
读锁之间不互斥。读写锁之间,写锁之间是互斥的,用来保证变更表结构操作的安全性。
MDL 会直到事务提交才会释放,在做表结构变更的时候,一定要小心不要导致锁住线上查询
和更新。