标签：union 方法 res 更改 dash nbsp 服务层 ora 写入
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）基于 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
标签：union 方法 res 更改 dash nbsp 服务层 ora 写入
原文地址：https://www.cnblogs.com/ttaall/p/12546165.html
