MySQL随记
难点
索引选择
由于普通索引可以有多个值，在查找到满足条件的项后仍会继续查找，直到查询到不满足条件的项为止，而唯一索引在查找到后就可以返回了，因此普通索引查找效率要劣于唯一索引
索引结构为B+树，只有叶子存储值，其他存储索引
即便是索引，每次也是加载一个页框进内存，在查找数据都能够命中内存页时，普通索引和唯一索引的效率差距在内存上差距就不明显了，而在大部分情况下，查找数据都是可以命中内存的
对于更新操作(change buffer)而言，唯一索引还要判断是否会出现重复索引，因此需要再次扫描索引，此时效率反而劣于普通索引
索引错误选择
一些查询语句反而会由于加上索引条件后，MySQL的查询效率反而降低 ，此时并没有走索引树而是全表扫描
通过explain [SQL语句]可以查看指定查询指令的MySQL查询计划，其中possibie_key记录了计划查询的索引
我们可以通过force关键字强制SQL通过索引树查询
1 | SELECT * FROM T WHERE A BETWEEN 10000 AND 20000 //40ms |
通过explain语句可以发现，上述语句中第一条语句并没有通过A索引
这点是由于MySQL的优化策略，在判断是否查询某个索引树时，还会考虑索引的区分度或者说不重复率，，在数据重复率较高的时候（极端情况下，索引完全相同的情况下），效率通常反而会劣于全表扫描
对于数据量较大的MySQL数据库而言，显然不可能将重复数据拿出来除以总数量计算，而是随机抽取数个磁盘页，通过抽样的方式计算区分度
当我们在数据库事务中通过DELETE * FROM T删除全表数据，再将数据加回去，由于对事务而言，DELETE并没有进行磁盘数据上的数据删除，而是在数据项打上DELETE MARK的标签，但是数据仍然存在于数据库中，这种情况下，由于加入了重复数据，就会导致误导MySQL计算区分度，导致区分度过低
此外，类似ORDER BY B这种语句，也会诱导MySQL优先访问B索引，但是实际需求中可能出现查询索引A效率更高的情况
但是在生产环境中并不推荐通过FORCE强制MySQL访问某索引树，而是推荐诱导MySQL提供多个索引选择，相信MySQL的优化器，如ORDER BY B,A
幻读
幻读是指多个事务同时执行时，当事务A在执行多次查询操作时，事务B对表进行了插入/删除行，从而导致事务A查询的结果集不一致
MySQL保存数据除了持久化（保存在磁盘）外，还会建立主从节点，备份数据，以免主节点操作出现错误后数据难以恢复
在binlog为statement格式时，从节点是按照事务提交的顺序记录修改过程的
基于binlog，row格式只存储事务的修改结果而不记录过程，可以避免主从不一致
产生幻读的原因:行锁只能锁住行，但是插入数据会更新记录之间的间隙，可以通过引入间隙锁解决幻读问题
在A事务UPDATE行时，B事务仍然可以在行的间隙之间进行操作，而引入间隙锁后被操作行的行间隙无法被修改，就会阻止其他事务修改，在事务A提交后其他事务才会继续操作
性能优化
- 按数据类型分库分表
- 主从数据库
短链接风暴
MySQL是基于CS模式的，但是在操作时可能客户端与数据库建立起连接会话后，执行了少数操作就被断开，而在后续需要时再重连，这种情况下会在高并发场景下导致连接数暴涨
解决方案：
- 处理掉占有连接状态但是不进行操作的长连接线程
- 可以通过SHOW PROCESSLIST查询数据库中的工作线程
- 在LIST中，Command字段会指示线程状态：Sleep/Query
- 但是不能直接结束Sleep状态的字段，因为阻塞状态的事务也有可能导致线程睡眠，需要避开事务线程
- 可以通过INFORMATION_SCHEMA_TRX表查询事务状态
- 减少连接过程损耗
- 在数据库出现大量数据库连接请求时，可以让数据库暂时跳过权限验证阶段
慢查询性能
导致原因：
- 索引设计不当
- SQL语句没有合理运用索引
- MySQL优化器选择了错误索引（见上）
QPS突增
在业务过程中可能会导致某条查询语句的调用次数暴涨，影响SQL效率
可以通过模板替换的功能：在检测到调用没有运用索引的语句时可以替换为运用索引的查询语句
面试重点
- 数据库架构
- SQL优化
- 索引
- 联合索引、聚簇索引、B+树等
- 锁
- 共享锁、排他锁、行锁、表锁、间隙锁
- 事务
- ACID，隔离级别
- 实践