事务的使用、设置、以及工作中常见应用方式的总结。
Spring事务传播机制：
1、Spring事务是让我在业务中去选择开不开启，要不要有事务，这样一个逻辑。
Spring里面，方法嵌套调用外层读取数据和内层读取数据效果与数据库隔离级别的关系。
2、可重复读是默认,可不一定是常用的，这个也有可以读已提交，这个每个公司都不一样。
3、死锁、逻辑怪圈、并发场景
死锁：不光数据库，编程也会出现，数据库之间更新、删除等操作或者分布式锁的时候，都有可能跟事务冲突，发生死锁，所以一定要在写业务的时候要避免死锁。
逻辑怪圈：在业务场景下面逻辑很奇怪，比如使用乐观锁更改数据，实际上并发更改时就会出现问题，可能会出现ABA的问题，所以我们采用加入版本号字段可避免。
并发场景：有一些高并发业务场景，qps请求很高，要做事务操作会对数据库有压力，读写分离也不一定能够解决，所以要根据业务注意使用方式和方法。
例：explain select t.tcid from teacher t, teacherCard tc where t.tcid = tc.tcid;
| Select-type查询语句的种类复杂度 | table | type查找种类 | possible-keys | key | key-len |
|---|---|---|---|---|---|
| simple、 primary、 union 、dependent 、subquery | 表名 | Const（最快常数级别）、 eq_reg(唯一性索引)、 Ref（根据普通索引等值匹配）、 Range(进行范围查找)、 Index(索引覆盖查询索引中的所有数据)、 all（全表扫描） | 可能使用到的索引 | 实际使用的索引 | 表示本次查询中所选择的索引长度有多少字节 |
联合索引最左原则
我们用的innodb的B+tree结构是有先后顺序的，会有一个范围的关联，从第一个建立索引字段关联的，
区分度低的字段不适合建索引
联合索引字段个数不宜太多，充分权衡插入删除操作及DBA操作表成本
字段太多其实搞索引就没啥意义了，插入和删除成本就大了，要更改很多索引，索引树修改的资源就很多了。
索引组合索引、少用单列索引
创建和使用最好是多个列建立索引，不要每个列建一个，搞一个联合索引就好了。
where, on, group by, order by 后面跟着字段创建索引
创建了索引，不代表就走了索引
这个就跟第一个一样，用explain查一下，看看到底走没走
举例：
ABC创建索引，哪些能走索引呢？
where A = 10 ；可以走
where B =10； 不能走
where A=10 AND C=3 ； A可以走 B不能
where B=7 AND A=6； 可以走，因为mysql有自己的优化器
where A in (1,2,3)；可以走，要看覆盖范围，数据量
where A>8 and A<100 ;可以走，也是要看覆盖数据范围
where A like ‘%2%’; 不能走，不能从范围解析，前面有%模糊匹配
where A like ‘2%’; 可以走
where A *3 = 90 ; 不能走，有数据计算表达式不能走
B+树
区别：B+在b树上有一个升级，节点上b树每一个节点都存储的数据，而B+ 是索引信息，叶子结点存储的才是数据，叶子结点还有指针关联，横向遍历有优势，支持范围查询。
可重复读不是直接解决幻读问题，Mysql版本下没有幻读问题，因为有MVCC多版本并发控制，是通过Next-key Lock（前开后闭区间，锁定范围，next-key lock 由行锁和间隙锁组成）机制解决了幻读问题。
由于不同线程之间对于同一资源的争抢和等待，产生死锁。
读写分离、加机器、分库分表都可以减少读写压力，但是不同的方案也会造成一些其他的问题，造成复杂度提升，这个就因公司而异。
索引覆盖：就是我们直接把结果查询出来，直接索引就能覆盖，不同二次回表。
回表：在使用索引时候，带着索引id的值，在去查询下表里的其他字段。
聚簇索引：聚簇索引就是按照每张表的主键构造一颗B+树，同时叶子节点中存放的就是整张表的行记录数据，也将聚集索引的叶子节点称为数据页。这个特性决定了索引组织表中数据也是索引的一部分，每张表只能拥有一个聚簇索引。Innodb通过主键聚集数据，如果没有定义主键，innodb会选择非空的唯一索引代替。如果没有这样的索引，innodb会隐式的定义一个主键来作为聚簇索引。