MySql

1 连接层

2 服务层

3 引擎层

4 存储层

事务Transaction：一系列操作统称事务；

事务的特性：原子性，一致性，隔离性，持久性

一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

隔离性： 两个事物无法看到对方的中间状态的

@read uncommited  读未提交

脏读

原因：主要针对select，用户A更改了数据并未提交，用户B在select时候能查到用户A未提交的数据。

解决：设置隔离级别为读提交，利用快照读只读已经完成提交的数据。

@read commited    读提交

不可重复读

原因：主要针对update，用户A查询了数据后，用户B更新了数据值，等用户A再次查询数据时发现两次数据值不一样。

解决：设置隔离级别为可重复读，利用快照读，当A事务启动后不允许再修改数据，保证了可重复读，避免不了幻读

@repeatable read  可重复读

幻读

原因：主要针对insert delete,用户A查询了数据后，用户B插入了一条新数据或者删除了一条数据。等用户A再次读的时候发现数据数量两次不一样。

有一个操作是查询有没有这条数据，如果没有就插入一条。如果A B两个事物同时执行这个操作，A 发现没有数据，然后插入了一条，再A插入之前 B也发现了也插入一条。

解决：设置隔离级别为串行化，一个一个的事务施行，执行效率极差，开销贼大。

@serializable   串行执行

Spring事务支持

事物的传播性： 多个事务调用时，控制事务之间方法传播。

1. required 当没有事务时，创建一个事务，如果有就加入到这个事务。（默认）
2. supports 支持当前事务，如果没有当前事务，就按非事务执行
3. required_new 新建事务，如果当前有事务，就将当前事务挂起

事务执行方式：

（1）基于 TransactionProxyFactoryBean的声明式事务管理
（2）基于 @Transactional 的声明式事务管理
（3）基于Aspectj AOP配置事务

数据库查询性能下降 查询sql慢的原因:

1 查询语句写的烂，没用索引

2 索引失效

3 关联查询太多join

解决方式：

1 观察 看看生产中慢SQL的情况

2 开启慢查询日志  设置阈值 ，把超过5秒的慢SQL抓取出来

3 用explain进行分析

4 show profile

5 sql数据库参数调优

索引是一种数据结构  底层 B树(多路搜索树)

什么是索引， ： 排好序的快速查找数据结构就是索引     1排序  2查找

索引的目的： 1降低查找成本  2降低排序成本

缺点:  影响增删改速率  每次增删改都改更新索引

提高检索效率，单纯为检索而生

索引本身都很大，以索引文件的形式存储在磁盘

当一个表中有大量记录时，为表中的某一个字段建立索引，不用从头遍历整个表来查找，而是可以通过索引来快速查找。

索引会增加数据库存储空间，每次修改表数据时索引也要修改. 所以适合查找多修改少的操作

索引中不能包含空值的列，如果组合索引中有一个是空值那么整条索引都是无效的

索引种类

唯一索引：索引对应的列是唯一的，不允许有空值

主键索引：

组合索引：索引中包含多个字段

总的来说就这么一句话!

连接查询：

左连接 left join      select *from A left join B on  A.a = B.b where ?  左表的全部+左右共有利用补null)  select *from A left join B on A.a = B.b where B.b is null 左表全部去掉左右共有

右连接 right join     select *from A right join B on A.a = B.b where ?  右表的全部+左右共有

利用补null)_ select *from A right join B on A.a = B.b where A.a is null 右表全部去掉左右共有

内连接 inner join      select * from A inner join B on A.a = B.b  where ?  左右的共有

全连接 full outer join    select *from A full outer join B on A.a = B.b where? 左右全连接

左连接+右连接+union并联去重 = 全连接 (mysql不支持直接全连接)

Explain全解:

*id:  

相当于表读取的优先级      id相同 执行顺序由上到下   id不同 id越大优先级越高

select_type :

select类型   simple  primary  subquery derived union unionresult

*type:

访问类型排列  system > const > eq_ref > ref > range > index > All (一般range就很牛逼)

range(用索引检测给定范围内between and < > in)

index(用索引只遍历索引树查询，进行全表扫描)

All(全表扫描)

possible_keys:

本次查询可能用到的索引

*key:

本次查询实际用到的索引

key_len:

索引字段的最大可能长度，而不是索引实际长度

ref:

先使用到了索引的哪一个字段 const表示一个常量

*rows:

大致估算出查询所用的行数(越少越好)

*extra:

using Filesort: 产生原因排序查询order by时 不能完全按照索引的顺序排序。没办法mysql自己又创建一次排序

using Temporary: 产生临时表大量降低数据库性能, group by 时没按照索引顺序，

using Index : 表明要查询的列完全被索引覆盖——覆盖索引    

索引优化：  

~范围后的查找会导致索引失效(一楼二楼三楼的共有索引，当二楼是个范围查询，三楼会失效，导致索引用不到，新创建内部表(using Filesort))

~左连接索引加在右表，右连接加左表；

~多用小表驱动大表

~优先优化括号内查询

索引失效原因：

1最佳左前缀法则，（索引为多列时，不能跳过左边直接查右边）

2 查询语句中不要对索引列 使用计算函数 例如left

3 范围之后全失效  多列索引下 (左边的列是范围查询则右边的索引失效)

4 尽量使用覆盖索引  减少使用select *

5 使用 !=或<>时 is null 或 is not null 会进行全表扫描 造成索引失效 少用or

6 模糊查询like  %加右边时索引不失效

7 order by没按照索引顺序,group by 没按照索引顺序

小表驱动大表

select * from A where a in(select a from B);      in 是包含    exists是被包含于

select *from A where exists(select X from B where A.a = B.a);  exists相当于两次for循环，括号内为内部循环，当外部为小表 内部为大表时，小表驱动大表效率最佳，否则用in

MySql

标签：union   方法   res   更改   dash   nbsp   服务层   ora   写入