5.数据库
要求: 能熟练使用、部署、调优、问题排查、懂原理
1.关系型数据库: MySQL/Oracle/PostSQL
1.InnoDB引擎,事务处理机制
由于mysql中有两套日志机制，一套是存储层的redo log，另一套是server层的binlog，每次更新数据都要对两个日志进行更新。为了防止写日志时只写了其中一个而没有写另外一个，mysql使用了一个叫两阶段提交的方式保证事务的一致性
执行流程:
- 首先执行器会找引擎取ID=2这一行数据
- 拿到数据后会把数据进行+1操作，然后调用引擎接口把新数据写入
- 引擎将数据更新到内存中，并将操作记录到redo log里，此时redo log处于prepare状态。但它不会提交事务，只是通知执行器已经完成任务，可以随时提交。
- 执行器生成这个操作的binlog，并把binlog写入磁盘
- 最后执行器调用引擎的事务接口，把redo log改为提交状态，更新完成。
2.MySQL优化
粗说:
加索引的时候尽量准确，避免造成不必要的锁定影响其他查询。
尽量减少给予范围的数据检索（间隙锁），避免因为间隙锁带来的影响，锁定了不该锁定的记录。
尽量控制事务的大小，减少锁定的资源量和锁定时间。
尽量使用较低级别的事务隔离，减少 MySQL 因为事务隔离带来的成本。
细说:
- 频繁变动的字段, 不适合建索引
- 离散度越高越好, 离散低不适合建索引
- like "asd%" 都不一定用索引,其他位置都不用索引查询
- 比对规则从左往右, 离散高放前边, 一个索引器反复, 最左前缀原则
- 去掉冗余索引, 有联合索引, 就不要单个的联合索引的列
- 能用覆盖索引(主键), 就千万不要 select *, 速度至少快1倍
- 用or 索引会失效
3.MySQL锁相关
锁分类:
表级锁：对整张表加锁。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁：对某行记录加锁。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
表级锁:
意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前，必须先取得该表的 IS 锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前，必须先取得该表的 IX 锁。
注：意向共享锁和意向排他锁是数据库主动加的，不需要我们手动处理。对于 UPDATE、DELETE 和 INSERT 语句，InnoDB 会自动给数据集加排他锁。
行级锁:
共享锁（S）：当一个事务读取一条记录的时候，不会阻塞其他事务对同一记录的读请求，但会阻塞对其的写请求。当读锁释放后，才会执行其他事务的写操作。
例如：select … lock in share mode
排他锁（X）：当一个事务对一条记录进行写操作时，会阻塞其他事务对同一表的读写操作，当该锁释放后，才会执行其他事务的读写操作。
共享锁，排他锁，意向共享锁，意向排他锁兼容图例
如果一个事务请求的锁模式与当前的锁兼容， InnoDB 就将请求的锁授予该事务；反之， 如果两者不兼容，该事务就要等待锁释放。
间隙锁
前面谈到行锁是针对一条记录进行加锁。当对一个范围内的记录加锁的时候，我们称之为间隙锁。
当使用范围条件索引数据时，InnoDB 会对符合条件的数据索引项加锁。对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB 也会对这个“间隙”加锁，这就是间隙锁。间隙锁和行锁合称（Next-Key锁）。
死锁
两个事务都需要获得对方持有的排他锁才能继续完成任务，这种互相等待对方释放资源的情况就是死锁。
避免死锁：
- 第一步查询，第二步更新.查询时直接上排它锁
- 同时需要查询修改多个表,按同样的顺序进行加锁
MySQL 锁定情况的查询
在实际开发中无法避免数据被锁的问题，那么我们可以通过哪些手段来查询锁呢？
表级锁可以通过两个变量的查询：
Table_locks_immediate，产生表级锁的次数。
Table_locks_waited，数显表级锁而等待的次数。
行级锁可以通过下面几个变量查询：
Innodb_row_lock_current_waits，当前正在等待锁定的数量。
Innodb_row_lock_time（重要），从系统启动到现在锁定总时长。
Innodb_row_lock_time_avg（重要），每次等待所花平均时间。
Innodb_row_lock_time_max，从系统启动到现在等待最长的一次花费时间。
Innodb_row_lock_waits（重要），从系统启动到现在总共等待的次数。
特别注意,行锁使用不当会造成排它锁:
原文链接：https://blog.csdn.net/claram/java/article/details/54023216
1、只根据主键进行查询，并且查询到数据，主键字段产生行锁。
begin;
select * from goods where id = 1 for update;
commit;
2、只根据主键进行查询，没有查询到数据，不产生锁。
begin;
select * from goods where id = 1 for update;
commit;
3、根据主键、非主键含索引（name）进行查询，并且查询到数据，主键字段产生行锁，name字段产生行锁。
begin;
select * from goods where id = 1 and name='prod11' for update;
commit;
4、根据主键、非主键含索引（name）进行查询，没有查询到数据，不产生锁。
begin;
select * from goods where id = 1 and name='prod12' for update;
commit;
5、根据主键、非主键不含索引（name）进行查询，并且查询到数据，如果其他线程按主键字段进行再次查询，则主键字段产生行锁，如果其他线程按非主键不含索引字段进行查询，则非主键不含索引字段产生表锁，如果其他线程按非主键含索引字段进行查询，则非主键含索引字段产生行锁，如果索引值是枚举类型，mysql也会进行表锁，这段话有点拗口，大家仔细理解一下。
begin;
select * from goods where id = 1 and name='prod11' for update;
commit;
6、根据主键、非主键不含索引（name）进行查询，没有查询到数据，不产生锁。
begin;
select * from goods where id = 1 and name='prod12' for update;
commit;
7、根据非主键含索引（name）进行查询，并且查询到数据，name字段产生行锁。
begin;
select * from goods where name='prod11' for update;
commit;
8、根据非主键含索引（name）进行查询，没有查询到数据，不产生锁。
begin;
select * from goods where name='prod11' for update;
commit;
9、根据非主键不含索引（name）进行查询，并且查询到数据，name字段产生表锁。
begin;
select * from goods where name='prod11' for update;
commit;
10、根据非主键不含索引（name）进行查询，没有查询到数据，name字段产生表锁。
begin;
select * from goods where name='prod11' for update;
commit;
11、只根据主键进行查询，查询条件为不等于，并且查询到数据，主键字段产生表锁。
begin;
select * from goods where id <> 1 for update;
commit;
12、只根据主键进行查询，查询条件为不等于，没有查询到数据，主键字段产生表锁。
begin;
select * from goods where id <> 1 for update;
commit;
13、只根据主键进行查询，查询条件为 like，并且查询到数据，主键字段产生表锁。
begin;
select * from goods where id like '1' for update;
commit;
14、只根据主键进行查询，查询条件为 like，没有查询到数据，主键字段产生表锁。
begin;
select * from goods where id like '1' for update;
commit;
乐观锁、悲观锁
悲观锁方案：每次获取商品时，对该商品加排他锁。也就是在用户A获取获取 id=1 的商品信息时对该行记录加锁，期间其他用户阻塞等待访问该记录。悲观锁适合写入频繁的场景。
乐观锁方案：每次获取商品时，不对该商品加锁。在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等，如果相等则进行更新，反之程序重新获取库存量，再次进行比较，直到两个库存量的数值相等才进行数据更新。乐观锁适合读取频繁的场景
商城浏览商品下单这种高并发场景下,一般采用读写分离、异构数据库结构,读从Redis等缓存库里读,并发下单操作,锁机制可以用lua脚本、Redisson、zookpeer等方式做分布式锁、或者MySQL的排它锁,同时要防止死锁
事务隔离级别
读未提交（read uncommitted）：它是最低的事务隔离级别，一个事务还没提交时，它做的变更就能被别的事务看到。有脏读的可能性。
读提交（read committed）：保证一个事物提交后才能被另外一个事务读取。另外一个事务不能读取该事物未提交的数据。可避免脏读的发生，但是可能会造成不可重复读。
可重复读（repeatable read MySQL 默认方式）：多次读取同一范围的数据会返回第一次查询的快照，即使其他事务对该数据做了更新修改。事务在执行期间看到的数据前后必须是一致的。即：事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容.
串行化（serializable）：是最可靠的事务隔离级别。“写”会加“排他锁”，“读”会加“共享锁”。
