事务

好的学习链接： http://blog.csdn.net/taylor_tao/article/details/7063639 innodb的默认事务隔离级别是rr（可重复读）。它的实现技术是mvcc。基于版本的控制协议。该技术不仅可以保证innodb的可重复读，而且可以防止幻读。但是它防止的是快照读，也就是读取的数据虽然是一致的，但是数据是历史数据。如何做到保证数据是一致的（也就是一个事务，其内部读取对应某一个数据的时候，数据都是一样的），同时读取的数据是最新的数据。innodb提供了一个间隙锁的技术。也就是结合grap锁与行锁，达到最终目的。当使用索引进行插入的时候，innodb会将当前的节点和上一个节点加锁。这样当进行select的时候，就不允许加x锁。那么在进行该事务的时候，读取的就是最新的数据。 实现： 1. 快照读(snapshot read) 简单的select操作(不包括 select ... lock in share mode, select ... for update) 2.当前读(current read) select ... lock in share mode select ... for update insert update delete 在RR级别下，快照读是通过MVVC(多版本控制)和undo log来实现的，当前读是通过加record

我认为spring 就是一个框架的集成器，通常使用spring 来管理action 层和DAO 层。Spring本身有很多的组件，比如：MVC、IOC、AOP、DaoSupport等等。IOC 本身也就是一个容器，它管理了所有的bean 和bean 之间的依赖关系。 IOC 也叫作控制反转，核心是BeanFactory。也就意味着IOC 是基于工厂模式设计的，同时这个工厂生产的bean 默认是单例的。如果想修改单例变成多实例，则需要修改bean 的scope属性，值是prototype。在没有使用IOC 以前，程序员需要自己在对应的类中new 相关依赖的对象。 比如UserAction依赖于UserService完成业务操作，而UserService又依赖于UserDAO完成数据库操作。所以需要在action 中new servcie，在service 中new DAO。这样的方式，是由程序员来管理了对象的生命周期和他们之间的依赖关系，耦合度很高，不利于程序的拓展。所以通过IOC 来管理bean 和依赖关系，可以解耦合。 我们将所有的action、service 和dao等类定义成IOC 的一个bean 组件，此时类的实例化就交给了IOC 的beanFactory，由工厂来负责实例化bean 的对象。IOC 有三种注入方式，属性注入、构造器注入和接口注入。接口注入只是spring

3 月，跳不动了？>>> 节点指的是区块链网络中的计算机,包含手机,矿机和服务器等等。由大量个人或者家庭用户参与的区块链，每个个人或者家庭都是区块链的节点。下面我们以比特币为例，解释下节点是什么意思。 众所周知，比特币被设计为一种去中心化的点对点（P2P）网络，我们需要巨量的机器来维护这一散布全球的网络。比如，为了确认交易有效性，比特币需要多于一个单独网络的矿工处理交易单，它必须通过“节点”向网络广播。这是交易处理过程的第一步（区块链确认）。 区块链是个分布式系统，系统里有很多节点，这些节点你只要单纯地理解为通过互联网相连的电脑或者服务器就好了。然后根据区块链性质的不同，成为节点的方式也不同，当然，对于节点的定义也不同。对于像比特币这样的公有链，理论上来讲，你下载完整的区块链，参与交易和挖矿，才算是节点。 然而，在现在的比特币里，矿工，完全节点，轻量节点，甚至普通用户，在不同的语境下都可能被称为节点。但无论如何，比特币的系统与其说是“连入网络就会自动更新区块链”，不如说是你想要挖矿或者是交易外汇跟单www.gendan5.com（同时你不信任其他人的验证结果），就必须更新整条区块链，这不是一个自动义务的事情，而是自愿的事情。 区块链的节点有几个特点： 一、具有一定的存储空间 存储空间指电子存储空间，包括日常的TF卡、U盘、移动硬盘和计算机等。 二、连接网络

参考资料 一、视图 视图的含义： 视图是一个虚拟表，是从数据库中一个或者多个表中导出来的表。 1、创建视图 #语法：CREATE VIEW 视图名称 AS SQL语句 create view teacher_view as select tid from teacher where tname='李平老师'; #于是查询李平老师教授的课程名的sql可以改写为 mysql> select cname from course where teacher_id = (select tid from teacher_view); +--------+ | cname | +--------+ | 物理 | | 美术 | +--------+ rows in set (0.00 sec) #！！！注意注意注意： #1. 使用视图以后就无需每次都重写子查询的sql，但是这么效率并不高，还不如我们写子查询的效率高 #2. 而且有一个致命的问题：视图是存放到数据库里的，如果我们程序中的sql过分依赖于数据库中存放的视图， 那么意味着，一旦sql需要修改且涉及到视图的部分，则必须去数据库中进行修改，而通常在公司中数据库有专门的DBA负责， 你要想完成修改，必须付出大量的沟通成本DBA可能才会帮你完成修改，极其地不方便 2、查看视图 select * from course_view; create

01. 事务 什么是事务? 事务是单个的工作单元 如在某一项事务成功,则在该事务中进行的所有数据更改均会提交,成为数据库中的永久组成部分.如果事务遇到错误且必须取消或回滚,则所有数据更改均被清楚 为什么需要事务? 在银行业务中,有一条记账原则 ,即又借有贷,借贷相等,为了保证这种原则,每发生一笔银行业务,就必须确保会记账目上 借方科目和贷方科目至少各记一笔,并且这两笔账要么同时成功,要么同时失败. 视图使得人们可以为一个或者多个数据表定义一个特殊的表现形式。视图在表现行为上与表没有差别，可以select查询，也可以用insert，update，delete来修改数据。 一般使用视图的理由有两个，一个是安全，例如一个表中包含了员工的个人资料，那像电话姓名这些是所有人都可以查询的，但是像薪水这些东西就只有特定的人能查询了，因此最好的办法就是将所有人都可以访问的数据部分创建为一个视图，供别人查询。另一个是方便，视图使用起来很方便，不用输入复制的命令 在视图里修改数据：能不能修改某个视图中的数据取决于视图的select命令，可刷新的视图需要满足以下几个条件： （1）当初定义的select中不得包含group by、distinct、limit、union或having等子命令 （2）如果视图中的数据来自一个以上的表，那它总是不可刷新的 （3）视图中应包含主键索引，唯一索引

事务隔离级别：一个事务对数据库的修改与并行的另一个事务的隔离程度。 两个并发事务同时访问数据库表相同的行时，可能存在以下三个问题： 1、 幻想读 ：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。 2、 不可重复读取 ：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。 3、 脏读 ：事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。 为了处理这些问题，SQL标准定义了以下几种事务隔离级别 READ UNCOMMITTED 幻想读、不可重复读和脏读都允许。 READ COMMITTED 允许幻想读、不可重复读，不允许脏读 REPEATABLE READ 允许幻想读，不允许不可重复读和脏读 SERIALIZABLE 幻想读、不可重复读和脏读都不允许 Oracle数据库支持READ COMMITTED 和 SERIALIZABLE这两种事务隔离级别。所以Oracle不支持脏读 SQL标准所定义的默认事务隔离级别是SERIALIZABLE，但是Oracle

mysql的存储引擎架构把查询处理及其他系统任务和数据的存储/提取相分离 1.1 mysql逻辑架构 　　第一层：链接处理、授权认证、安全等大多数基于网络的工具或者服务都有类似的架构 　　第二层：核心服务，查询解析、分析、优化、缓存、所有的内置函数（日期、时间等），所有跨存储引擎的功能，存储过程、触发器、视图等 　　第三层：存储引擎，负责数据的存储和提取 　　1.1.1 连接管理与安全性 　　　　每个客户端连接都会在服务器进程中拥有一个线程，服务器会缓存线程， 　　1.1.2 优化与执行 　　　　mysql会解析查询，并创建解析书，然后优化。 　　　　在查询之前，会先检查查询缓存 1.2 并发控制 　　1.2.1 读写锁 　　　　读锁和写锁 　　　　1.2.2 锁颗粒 　　　　　　表锁： 　　　　　　行级锁：可以最大程度的支持并发，只在存储引擎层实现 1.3 事务 　　原子性、一致性、隔离性、持久性 　　1.3.1 隔离级别 　　　　未提交读：事务的修改，即使没有提交，对其他事务也都是可见的。脏读 　　　　提交读：一个事务只能看见已经提交的事务的修改。不可重复读 　　　　可重复读：保证了同一个事务中多次读取同样记录的结果是一致的，mvcc，mysql默认隔离级别 　　　　可串行化：强制事务串行执行 　　1.3.2 死锁 　　　　各种死锁检测和死锁超时机制

今天发现数据库事务日志竟然达到500多M,这也难怪,修改数据如此频繁 想要清理,发现没有办法,上GOOGLE上一搜,在ZDNET上找到答案也 先分离数据库,然后删掉日志文件,接下来再attach数据库,SQL会显示日志文件丢失,按确定ATTACH的时候,会提示你创建新的日志文件,只要确定即可完成,简单方便 不过,需要提醒的是,第一,在删除日志前,最好将老的日志文件全都备份一下 第二,如果你的事务日志存放于多个物理文件中,那么,上面的方面就没办法帮你清理喽 不过,下面的方法绝对快 backup log db_name with no_log dbcc shrinkfile (northwind_log,5) 来源： https://www.cnblogs.com/Heroman/archive/2004/12/15/77572.html

乐观锁和悲观锁的比较和探究 平时我们在多线程并发编程的情况下经常要使用到锁机制，本文主要讨论了常用的悲观锁和乐观锁机制，同时乐观锁中使用的CompareAndSet（CAS）跟踪了源码并进行一定的分析。 悲观锁(Pessimistic Lock) 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 我们认为系统中的并发更新会非常频繁，并且事务失败了以后重来的开销很大，这样以来，我们就需要采用真正意义上的锁来进行实现。悲观锁的基本思想就是每次一个事务读取某一条记录后，就会把这条记录锁住，这样其它的事务要想更新，必须等以前的事务提交或者回滚解除锁。 实现方式： 平时大多在数据库层面实现加锁操作，比如JDBC方式：在JDBC中使用悲观锁，需要使用select for update语句 e.g. Select * from Account where ...(where condition).. for update. 乐观锁(Optimistic Lock) 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据

简述项目中优化sql语句执行效率的方法，从哪些方面，sql语句性能如何分析？ （1）尽量选择较小的列； （2）将where中用的比较频繁的字段建立索引； （3）select中避免使用*； （4）避免在索引列上使用计算、not in和<>等操作； （5）当只需要一行数据时候使用limit1； （6）保证单表数据不超过200w，实时分割表； 针对查询较慢的语句，可以使用explain来分析该语句具体的执行情况。 sql语句应考虑哪些安全性？ （1）少使用root账户，应该为不同的动作分配不同的账户； （2）sql执行出错后，不能把数据库中显示的出错信息，直接展示给用户。防止泄露服务器和数据库相关信息； （3）防止sql注入，对特殊字符进行转义、过滤或者使用预编译的sql语句绑定变量 接下来重点说下Mysql半同步复制， 从MySQL5.5开始，MySQL以插件的形式支持半同步复制 。先来区别下mysql几个同步模式概念： 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous