MySQL

索引失效

1、or查询，有1个字段不走索引，索引失效

2、类型不匹配，索引失效

3、like模糊搜索，%在左边，索引失效

4、联合索引，查询条件列不是联合索引第一个列，索引失效

5、对索引列使用函数、做运算，索引失效

6、索引字段使用!=、<>、not in，可能失效

7、索引字段使用is null、is not null，可能失效

8、左右连接查询，关联字段类型不一致，索引失效

9、MySQL估计全表扫描更快，不使用索引

索引不适用场景

1、数据量少

2、更新频繁

3、区分度低，如性别

索引潜规则

1、覆盖索引

2、回表

3、索引数据结构，B+树

4、最左前缀原则

5、索引下推

死锁

1、查看日志show engine innodb status;

2、找出死锁SQL，分析SQL加锁情况

3、模拟死锁发生，优化SQL

SQL优化

1、总体原则，减少扫描范围、走索引

2、分析业务优化SQL，避免返回不必要数据

3、分批执行

4、分库分表

5、读写分离

InnoDB、MyISAM区别

1、InnoDB支持事务、外键、行级锁、MVCC（多版本并发控制）

2、InnoDB表必须有主键，按主键大小顺序插入，需要维护主外键关系、缓存

3、MyISAM查询表行数更快，直接读取变量

4、MyISAM按记录插入顺序保存，插入速度快，可以被压缩

5、MySQL5.5版本之后默认InnoDB

索引用B+树原因

树贯彻思想

采用数据平衡策略、二分法查找，提升数据查找效率

二叉树

每个节点最多有2颗子树，子树必须区分左子树、右子树

满二叉树

所有分支节点都存在左子树、右子树，叶子节点在同一层，类似树上长满了叶子

完全二叉树

二叉树左部分多一层子节点，最多只能有1个单节点子树并且为左节点

二叉排序树，二叉查找树

左小右大

平衡二叉树

左子树、右子树深度最多相差1

基于二分法策略查询，时间复杂度O(logN)

红黑树

1、一种平衡二叉树，二叉树退化成链表场景查找效率低下，于是有了红黑树

2、根节点黑色，NIL空节点黑色

3、一个节点为红色，子节点必须黑色

4、叶子节点路径，包含相同数目黑节点

5、TreeSet、1.8HashMap有使用红黑树

B树

多叉树，查找路径不止2个，数据库索引大量使用B树、B+树

所有节点关键字按照递增次序排列，左小右大

B+树

B树升级版，树更矮更胖，IO次数减少，查询速度接近二分法查找，更快速更稳定

B+树非叶子节点不存储数据，只进行数据索引，保存关键字个数增加

聚集索引非聚集索引区别

1、1个表只能有1个聚集索引，索引逻辑顺序决定物理顺序

2、聚集索引叶子节点就是数据节点，非聚集索引叶子节点仍然是索引节点

3、聚集索引：列排序，范围查询，小数目不同值，非频繁更新

事务隔离级别

1、读未提交

2、读已提交

3、可重复读

4、串行化

limit 1000000很慢

1、限制id查询范围

2、排序，order by id

3、使用子查询快速获取id范围，再关联查询另外字段

4、限制最大页数

分布式主键方案

1、数据库自增长序列

2、UUID

3、Redis自增ID

4、Zookeeper生成ID

脏读

A事务读到B事务未提交数据

幻读

A事务两次查询数据集不一致，期间B事务悄悄做了修改

不可重复读

同一个事务下，2个相同查询返回不同数据

高并发安全修改同一行数据

1、乐观锁，版本号机制、CAS算法，先放行修改，如果没有其他线程修改就修改成功

2、悲观锁，将其他线程拒之门外，等待锁释放