MySQL
# MYSQL规模优化
https://juejin.cn/post/6844904127047139335
# 分片
https://zhuanlan.zhihu.com/p/57185574
# binlog
二进制日志，主从同步，replay
https://laijianfeng.org/2019/03/MySQL-Binlog-介绍/
订阅分库分表的 Binlog 怎么订阅？
分库分表的数据源中假如存在主键冲突要怎么解决？
怎么保证下游对 Binlog 的消费顺序？
# Innodb和MyIASM区别(事务，索引，锁。。。)
InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。
InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。
MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。
InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。
https://www.runoob.com/w3cnote/mysql-different-nnodb-myisam.html
# Innodb
https://blog.csdn.net/weixin_45320660/article/details/115326483
# 聚簇索引什么特点，为什么这样，顺序查询的实现，回表查询，联合索引特性
聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据
非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因
# 大表分页查询,10亿行数据，查找第N页数据，怎么优化
根据查询的页数和查询的记录数可以算出查询的id的范围，可以使用 id between and 来查询。
# 悲观锁和乐观锁，mysql相关锁说一下
当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来保证访问的次序，锁机制就是这样的一个机制。
从锁的类别上来讲，有共享锁和排他锁。
共享锁: 又叫做读锁。 当用户要进行数据的读取时，对数据加上共享锁。共享锁就是让多个线程同时获取一个锁。
排他锁: 又叫做写锁。 当用户要进行数据的写入时，对数据加上排他锁。排它锁也称作独占锁，一个锁在某一时刻只能被一个线程占有，其它线程必须等待锁被释放之后才可能获取到锁。排他锁只可以加一个，他和其他的排他锁，共享锁都相斥。
在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突
在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；
在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁。
SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。
在关系型数据库中，可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和页级锁(BDB引擎 )。
乐观锁（Optimistic Lock）：对加锁持有一种乐观的态度，即先进行业务操作，不到最后一步不进行加锁，"乐观"的认为加锁一定会成功的，在最后一步更新数据的时候再进行加锁。
悲观锁（Pessimistic Lock）：悲观锁对数据加锁持有一种悲观的态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）
# MySQL中InnoDB引擎的行锁是怎么实现的？
InnoDB是基于索引来完成行锁
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来完成行锁锁定，并且 id 是有索引键的列，如果 id 不是索引键那么InnoDB将完成表锁，并发将无从谈起
# InnoDB锁
- Record lock：单个行记录上的锁
- Gap lock：间隙锁，锁定一个范围，不包括记录本身
- Next-key lock：record+gap 锁定一个范围，包含记录本身
innodb对于行的查询使用next-key lock
Next-locking keying为了解决Phantom Problem幻读问题
当查询的索引含有唯一属性时，将next-key lock降级为record key
Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生
有两种方式显式关闭gap锁：（除了外键约束和唯一性检查外，其余情况仅使用record lock） A. 将事务隔离级别设置为RC B. 将参数innodb_locks_unsafe_for_binlog设置为1
# 如何分库分表
1）垂直分表
也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。一般是针对那种几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。
2）垂直分库
垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Producet一个库，订单Order一个库。切分后，要放在多个服务器上，提高性能。
3）水平分库分表
将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。
https://zhuanlan.zhihu.com/p/84224499
https://segmentfault.com/a/1190000038751310
# B+树和B树区别，优缺点
B树每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针，顺序访问指针，也就是每个叶子节点增加一个指向相邻叶子节点的指针。
# B树和二叉查找树或者红黑色区别
基本常识
# 索引原理
https://www.ituring.com.cn/article/986
https://www.jianshu.com/p/814c1675361c
B+树，二分查找
# 索引类型
https://segmentfault.com/q/1010000003832312
数据结构:
1、B+树索引(O(log(n)))：关于B+树索引，可以参考 MySQL索引背后的数据结构及算法原理
http://blog.codinglabs.org/articles/theory-of-mysql-index.html
2、hash索引：
a 仅仅能满足"=",“IN"和”<=>"查询，不能使用范围查询
b 其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引
c 只有Memory存储引擎显示支持hash索引
3、FULLTEXT索引（现在MyISAM和InnoDB引擎都支持了）
4、R-Tree索引（用于对GIS数据类型创建SPATIAL索引）
物理存储：
1、聚集索引（clustered index）
2、非聚集索引（non-clustered index）
逻辑角度：
1、主键索引：主键索引是一种特殊的唯一索引，不允许有空值
2、普通索引或者单列索引
3、多列索引（复合索引）：复合索引指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用复合索引时遵循最左前缀集合
https://segmentfault.com/a/1190000015416513
4、唯一索引或者非唯一索引
5、空间索引：空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。
MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MYISAM的表中创建
# mysql的主从备份
# 架构
# Sql编译
# 快速理解脏读、不可重复读、幻读和MVCC 🌟
https://cloud.tencent.com/developer/article/1450773
- Read uncommitted
- Read commited
- Repeatable read
- Serializable
# 回表
https://blog.csdn.net/CPLASF_/article/details/108799381
# 慢查询
- 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
- 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。
- 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。
# 数据结构
# 大库DDL
https://blog.csdn.net/frog4/article/details/82702745
# Mysql 集群如何保证数据的一致性。分别回答了弱一致性和强一致性。
# 高并发，强一致性
Mysql 集群在保证强一致性的情况下，如何保证高并发。聊了好多种方法，但是面试官都不是很满意，中间磕磕绊绊的。最后问可不可以用缓存，我前面提到了使用 redis 中间做一层，但是面试官说用
# 隔离级别和索引
# 性能优化
- 访问数据太多导致查询性能下降
- 确定应用程序是否在检索大量超过需要的数据，可能是太多行或列
- 确认MySQL服务器是否在分析大量不必要的数据行
- 避免犯如下SQL语句错误
- 避免查询不需要的数据。解决办法：使用limit解决
- 多表关联返回全部列。解决办法：指定列名
- 总是返回全部列。解决办法：避免使用SELECT *
- 重复查询相同的数据。解决办法：可以缓存数据，下次直接读取缓存
- 使用explain进行分析，如果发现查询需要扫描大量的数据，但只返回少数的行，可以通过如下技巧去优化：
- 使用索引覆盖扫描，把所有的列都放到索引中，这样存储引擎不需要回表获取对应行就可以返回结果。
- 改变数据库和表的结构，修改数据表范式
- 重写SQL语句，让优化器可以以更优的方式执行查询。
# 百万级别或以上的数据如何删除
关于索引：由于索引需要额外的维护成本，因为索引文件是单独存在的文件,所以当我们对数据的增加,修改,删除,都会产生额外的对索引文件的操作,这些操作需要消耗额外的IO,会降低增/改/删的执行效率。所以，在我们删除数据库百万级别数据的时候，查询MySQL官方手册得知删除数据的速度和创建的索引数量是成正比的。
所以我们想要删除百万数据的时候可以先删除索引（此时大概耗时三分多钟）
然后删除其中无用数据（此过程需要不到两分钟）
删除完成后重新创建索引(此时数据较少了)创建索引也非常快，约十分钟左右。
与之前的直接删除绝对是要快速很多，更别说万一删除中断,一切删除会回滚。那更是坑了
# 分布式ID
Snowflake
毫秒级时间41位 机器ID 10位 毫秒内序列12位
[TimeStamp][TransctionID][AutoIncrement]