扫一扫获取全部面试题
1.1. MySQL的binlog(主从复制机制)
开启
-- 配置文件中开启
-- 开启binlog
log_bin=ON
-- 指定名称
log_bin_basename=/var/lib/mysql/mysql-bin
-- 索引名称
log_bin_index=/var/lib/mysql/mysql-bin.index
mysql 使用binlog 实现主从复制
从库中开启线程去主库中读取binlog，然后同步从库数据（就是执行binlog中的sql），从而实现主从复制
binlog 三种存储模式
statement: 保存每个sql语句到binlog 中，从库拿去这些sql去执行
row:基于行模式，行更新之后就同步到从库
mixed:混合模式，以上两种方式混合
全部面试题+v：YDT939领取
1.2. InnoDB与MyISAM的区别
MyISAM的索引与行记录是分开存储的（非聚集索引）
InnoDB的主键索引与行记录是存储在一起的（聚集索引）
MyISAM 多用数据查询，不建议做更新、删除操作
InnoDB支持事务，MyISAM不支持事务
MyISAM不支持外键，InnoDB支持外键
1.3. 行锁表锁的区别
锁定粒度：表锁 > 行锁
加锁效率：表锁 > 行锁
冲突概率：表锁 > 行锁
并发性能：表锁 < 行锁
1.4. 乐观锁与悲观锁
乐观锁是指在操作一条数据时，认为不会发生冲突，不加锁。在MySQL通常加一个version字段来实现乐观锁，它是一种人为的方式
悲观锁是指没次操作总任务会发生冲突，每一次操作都会先获取锁，MYSQL中S锁和X锁就是悲观锁的一种形式
1.5. 隔离级别是什么，有什么作用
在事务并发情况下，各个事务之间会出现幻读（数据读取条数不一致——>范围查找），可重复读（事务内两次读取的数据不一致），脏读（读到事务未提交的数据）
1.6. 什么情况下不会使用索引
在索引字段上计算、函数、（自动or手动）类型转换，会导致全表扫描，而不会使用索引
SELECT*FROMstaffsWHERELEFT(NAME,2)='lee'
使用（！=或者<>、is null,is not null ）时也是用不到索引
like以通配符开头（'%James'）mysql索引失效会变成全表扫描操作
字符串不加单引号索引失效(出现隐式类型装换到时索引失效)
SELECT*FROMstaffsWHEREname=2000
少用or,用它连接时会索引失效
1.7. 创建检索的基本原则是什么
频繁作为查询的条件的字段应该创建索引
频繁更新的字段不适合创建索引：因为每次更新不单单是更新了记录还会更新索引，加重IO负担
Where条件里用不到的字段不创建索引
查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度
查询中统计或者分组的字段
经常增删改的表不适合建立索引
离散性比较低的列不适合做索引（count(distinct col):count(col)的比例）
1.8. 查询优化技巧
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最右，覆盖索引不写*；
不等空值还有OR，索引失效要扫用；
VAR引号不能丢，SQL高级也不难；
1.9. B+索引数据结构，和B树的区别
B树
每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null
遵守二叉树的基本准则，每次插入数据或则删除数据都会计算保持一个平衡（旋转）
B+Tree(B树加强版)
节点关键字搜索采用闭合区间
非叶节点不保存数据相关信息，只保存关键字和子节点的引用
关键字对应的数据保存在叶子节点中
叶子节点是顺序排列的，并且相邻节点具有顺序引用的关系
这种方式的好处就是快，性能更好
1.10. 事务四大特性（ACID）
原子性（Atomicity）
最小的工作单元，整个工作单元要么一起提交成功，要么全部失败回滚
一致性（Consistency）
事务中操作的数据及状态改变是一致的，即写入资料的结果必须完全符合预设的规则， 不会因为出现系统意外等原因导致状态的不一致
隔离性（Isolation）
一个事务所操作的数据在提交之前，对其他事务的可见性设定（一般设定为不可见）
持久性（Durability）
事务所做的修改就会永久保存，不会因为系统意外导致数据的丢失
1.11. MVCC机制
Multiversion concurrency control (多版本并发控)
并发访问(读或写)数据库时，对正在事务内处理的数据做多版本的管理。以达到用来避免写操作的堵塞，从而引发读操作的并发问题。
解决了InnoDB的幻读问题（RR隔离级别）
全部面试题+v：YDT939领取