面试场景题
一 . 抛出面试问题：联合索引的技巧回答
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 会直到事务提交才会释放，在做表结构变更的时候，一定要小心不要导致锁住线上查询
和更新。
六 . 优化器选择了错的索引怎么办
有个500万的表 分页查询特别慢。 select * from table where create_time and create_time>=时间戳 and create_time<=时间戳 and subtype='xx' and type='xx' and company_id =x order by create_time limited 90,30 ; 已经建立了组合索引 union_index包括字段 create_time subtype type company_id 但是 explain 发现竟然走了create_time 的索引 语句里加了一个use index(union_index) ，立马好了 真正的解决了客户的实际问题啊。
