① 若数据库操作commit发生异常，没有执行回滚，这时数据会存入数据库吗
弄清楚这个问题之前，要先要搞清楚执行数据修改（excute），但未提交事务之前，已修改的数据存放在哪里？这时的数据是在数据库内存缓冲区中。commit操作就是将缓冲区中已修改数据写入磁盘，形成持久化存储。
那么当commit提交的修改的数据是多条时，假设部分数据已经由缓冲区写入磁盘，另一部分还未完成时，出现异常，这个时候，如果不回滚，那么就无法保证数据修改的一致性（比如联机转账，A的账户扣了款，B的账户余额未增加）。
简单来说就是：若数据库操作commit发生异常，没有执行回滚，这时可能出现部分数据保存成功，部分保存失败，因此需要rollback回滚操作。
② online redo log 和undo各有什么作用
在MySQL中，两者存在的意义以及性能：
00 – Undo Log
Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。
- 事务的原子性(Atomicity)
事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。
- 原理
Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。
- 事务的持久性(Durability)
事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。不能因为错误/重启/宕机而丢失已经COMMIT的数据。为了保证持久性，数据库系统需要将修改后的数据完全的记录到持久的存储上。
- 用Undo Log实现原子性和持久化的事务的简化过程
假设有A、B两个数据，值分别为1,2。
A.事务开始.
B.记录A=1到undo log的内存buffer.
C.在内存中修改A=3.
D.记录B=2到undo log的内存buffer.
E.在内存中修改B=4.
F.将undo log的buffer写到磁盘。
G.将内存中修改后的数据写到磁盘。
H.事务提交
这里有一个前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。以上过程之所以能同时保证原子性和持久化，是因为以下特点：
A. 更新数据前记录Undo log。
B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的，可以用来回滚事务。
D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.
01 – Redo Log
- 原理
和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交时，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。
- Undo + Redo事务的简化过程
假设有A、B两个数据，值分别为1,2.
A.事务开始.
B.记录A=1到undo log的内存buffer.
C.内存中修改A=3.
D.记录A=3到redo log的内存buffer.
E.记录B=2到undo log的内存buffer.
F..内存中修改B=4.
G.记录B=4到redo log的内存buffer.
H.将redo log的内存buffer写入磁盘。
I.事务提交
- Undo + Redo事务的特点
A. 为了保证持久性，必须在事务提交时将Redo Log持久化。
B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C. Redo Log 保证事务的持久性。
D. Undo Log 保证事务的原子性。
E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。这是因为Recovery要依赖redo log. 如果redo log丢失了，系统需要保持事务的数据也没有被更新。
- IO性能
Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，减少了写数据的IO. 但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：
A. 尽量保持Redo Log存储在一段连续的空间上。以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。因此在系统第一次启动时就会将日志文件的空间完全分配，从而保证Redo Log文件在存储上的空间有更好的连续性。
B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时 (如事务提交),才将许多日志一起写入磁盘，这样可以减少IO次数。
C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，以减少Redo Log的IO次数。例如,Redo Log中的记录内容可能是这样的：
记录1: <trx1, insert …>
记录2: <trx2, update …>
记录3: <trx1, delete …>
记录4: <trx3, update …>
记录5: <trx2, insert …>
D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。
E. Redo Log上只进行顺序追加的操作，当一个事务需要回滚时，它的Redo Log记录也不会从Redo Log中删除掉。InnoDB的做法时将回滚操作也记入Redo Log(具体做法看下一节).
③ 在Oracle数据库中，进行了插入数据，如果未commit就关掉数据库了，下次打开数据库还能查到插
oracle的commit就是提交数据，在未提交前你前面的操作时，更新的都是内存，没有更新到物理文件中。所以未commit就关掉数据库，数据库中的数据并没有更新。
commit的提交针对的是:DML
DML(Data Manipulation Language) 需要提交，这部分是对数据管理操作，比如Insert（插入）、Update（修改）、Delete（删除）；
DDL (Data Definition Language)不需要提交，这部分是对数据结构定义，比如Create（创建）、Alter（修改)、Drop（删除）。
④ 如何查到未提交的事务，堵塞的记录
打开全日志后可以看。
打开的方法是：
1、5.0的版本
在配置文件的mysqld段中，增加
log=/var/log/mysql.log(或者其他的你想放日志的路径)
然后重启数据库
2、如果是5.1的版本
在配置文件的mysqld段中，增加
general_log_file=/var/log/mysql.log
然后重启数据库
5.1版本也可以不用重启，全局设置一下，方法是：
set global general_log=1;
set global general_log_file=/var/log/mysql.log;
打开日志后，查看未提交事务的方法为：
连接到数据库后，会分配一个连接id，然后追踪此连接id，找到此连接执行的所有sql，如果有begin，而没有commit，那么这个语句就是未提交的。
⑤ oracle一个没有提交的事务,数据库重启后,其他用户能看到吗
没提交的事务，放在回滚段空间中；数据库重启，自动回滚，以及你的数据库连接也关闭了。重启后，你重连接，所有用户都看不到了，包括你自已。
⑥ todo数据保存在哪里
localstorage。todo数据保存在localstorage里面。Todo清单是一款强大的跨平台GTD待办事项和时间管理软件。
⑦ 事务还未提交，修改的数据会被写入磁盘吗
题主，你说的这种情况是允许出现的。这与事务的隔离程度有关。
如果事务隔离程度设置得当，就没有必要显式的通过synchronized保护资源（除非资源是某个service中的公共属性）。
⑧ oracle的sqlplus怎样保存修改的数据
oracle中执行了insert、update、delete这三个DML语句后，结果在未提交前实际上是保存在undo空间内，只有提交之后，才会真正写入到表中。所以会发生你的问题。
提交语句：commit
另外，在未做提交前，其他人是无法select到你处理的数据的，看到的是未处理前的数据。
还有一点要说明，当你执行了update、delete时，语句所影响的数据会被oracle自动锁定，其他人只能查，而不能update或delete，如果执行update或delete，那么就会产生数据库锁。而锁一旦产生，对系统的影响会很大，因此应尽快提交。
⑨ 在oracle中，修改了一条语句，但未提交，那么该修改的数据保存在哪里
此时该数据存放在sga中的高速缓存区，存放的数据块叫脏数据块，
⑩ 数据库详解之事务
究竟什么是数据库的事务，为什么数据库需要支持事务，为了实现数据库事务各种数据库的是如何设计的。还是只谈理解，欢迎大家来讨论。
1. 数据库事务是什么
事务的定义，已经有太多文章写过，我就不重复了。我理解的事务就是用来保证数据操作符合业务逻辑要求而实现的一系列功能。换句话说，如果数据库不支持事务，上面业务系统的程序员就需要自己写代码保证相关数据处理逻辑的正确性。而数据库事务就是把一系列保证数据库处理逻辑正确性的通用功能在数据库内实现，并且尽量提高效率。
举个例子，数据库最开始普及就是在金融业，银行的存取款场景就是一个最典型的OLTP数据库场景，而事务就是设计用来保证类似场景的业务逻辑正确性的。
**原子性**，如果你要给家人转账，必须在你的账户里扣掉100块，在家人账户里加上100块，这两笔操作需要一起完成，业务逻辑才是正确的。但是程序在做修改的时，肯定会有先后顺序，试想一下程序扣了你的钱，这个时候程序崩溃了，家人账户的钱没有加上。那这100块是不是消失了？你是不是要发疯？那么，就把这两笔操作放进一个事务里，通过原子性保证，这两笔操作要么都成功，要么都失败。这样才能保证业务逻辑的正确性。
**一致性**，有很多文章讲过一致性，但是很多人会把一致性跟原子性混在一起说。事务的一致性指的是指每一个事务必须保证执行之后所有库内的规则依旧成立。比如内外键，constraint，触发器等。举例来说，你在储蓄卡里有100元，理财账户里有100元，基金账户有100元，那么你在资产总和里会看到300元，这个300元必须是其他三个账户余额加在一起得到的。你在给家人转帐100元是从储蓄卡里转出去了100元，那么在数据库上可以通过创建触发器的方式，当储蓄卡余额账户减100元的同时，把资产总和也同步减去100，不然的话，就会出现逻辑上的错误，因为你已经转走了100块储蓄卡余额，实际资产总和应该是200，如果还是300，数据库状态就不一致了。所以实现事务的时候，必须要保证相关联的触发器以及其他所有的内部规则都执行成功，事务才能算执行成功。如果在减去资产总时出错，那么这笔转帐交易也不能成功。因为这样数据库就会进入不一致的状态。
那么这里跟原子性的区别到底在哪里呢？原子性是指个多个用户指令之间必须作为一个整体完成或失败，而一致性更多是数据库内的相关数据规则必须同时完成或失败。
**持久性**，最容易理解的一个，事务只要提交了，那么对数据库的修改就会保存下来不会丢了。简单来说，只要提交了，数据库就算崩溃了，重启之后你刚存的100块依然在你的账户里。
**隔离性**，每个事务相对于其他的事务是有一定独立性的，不能互相影响。因为数据库需要支持并发的操作来提高效率。在并发操作时，一定要通过操作之间的隔离来保证业务逻辑的正确性。比如，你转帐100块给家人，一系列操作的最后一步可能是输入验证码，这个时候转帐还没有完成，但是在数据库里你的账户对应的记录中已经减去100块，家人账户也加了100块，就等着验证码输入以后，事务提交，完成操作。那么，这个时候，家人通过手机银行能够查到这100块么？你的答案可能是不能，因为这样才符合业务逻辑，因为你的转帐操作还没有提交，事务还没有完成。那么数据库就应该保证这两个并发操作之间具有一定的隔离性。
那么到底应该隔离到什么程度呢？隔离性又分为4个等级：由低到高依次为Read uncommitted(读未提交)、Read committed（读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。这些东西是什么意思？请有兴趣的小伙伴自行网络，很多文章都写的很清楚。
那么怎么理解不同的隔离等级呢，首先要理解并发操作，并发操作就是指有不同的用户同时对一个数据进行读、写操作，那么在这个过程中，每个用户应该看到什么数据才能保证业务逻辑的正确性呢？ 如果是前面存取款的场景，我必须看到的是已经存进来的钱，也就是必须是已经提交的事务。而12306刷火车票呢，你可以看到有10张余票，但是在下单的时候告诉你票卖完了，因为同时有10个用户把票买掉了，你需要重新刷余票，这个也是可以接受的，也就是说我可以读到一些虚假的余票，这样在业务上也没有什么问题。那么在设计这两个不同系统时，就可以选择不同的事务隔离级别来实现不同的并发效果。不同的隔离等级就是要在系统的并发性和数据逻辑的严谨性之间做出的平衡。
2. 数据库如何实现事务
数据库实现事务会有多种不同的方式，但基本的原理类似，比如都需要对事务进行统一的编号处理，都需要记录事务的状态（是成功了还是失败了），都需要在数据存储的层面对事务进行支持，以明确哪些数据是被哪些事务、插入、修改和删除的。同时还会记录事务日志等，对事务进行系统化的管理以实现数据的原子性，一致性和持久性。
要实现事务的隔离性，最基础的就是通过加锁机制把并发操作适当的串行化来保证数据操作的正确逻辑。但是为了要保证系统具有良好的并发性能，必须要在实现事务隔离性时需要找到合理的平衡点。大部分数据库（包括Oracle，MySQL，Postgres在内）在做并发控制的时候都会采用MVCC（多版本并发控制）的机制来保证系统具有较高的并发性，不同数据库实现MVCC的具体方案也不尽相同，但其基本原理类似。
3. MVCC实现原理
所谓MVCC，就是数据库中的同一查询根据相关事务执行的先后顺序以及隔离级别的不同，可能会存在不同版本的结果，通过这样的手段来保证大部分查询操作不会被修改操作阻塞并保证数据逻辑的正确性。也就是数据库通过保存多个版本的数据（ 历史 数据）来提高系统的并发查询能力。简单来说就是用存储空间来交换并发能力。下面以Postgres为例介绍一下MVCC的一种实现方式帮助大家理解这个重要的数据库概念。通过下面的图来解释Posrgres里最基本的数据可见性是如何实现多版本控制的。
首先，Postgres里的每一个事务都有编号，这里可以简单理解为时间顺序编号，编号越大的事务发生越晚。然后，数据库里的每一行记录都会保存创建这条记录的事务号（Cre），也会在记录删除时保存删除这条记录的事务号（Exp），换句话说，只要Exp这里一列里记录了事务编号，就说明这条记录被删除了。那么一个事务应该能看见那些记录呢？Postgres里每一个事务都会保存一个当前系统的事务快照（Snapshot），这个快照里会保存事务创建时当前系统的最高（最晚）事务编号，以及目前还在进行中的事务编号。那么如上图所示的一个事务的快照里最高事务编号为100，目前正在进行的事务有25，50和75。那么对应左边数据记录，这6行数据的可见性就如同标注的一般：
第一行，Cre 30，没有删除，在100这个时间点，应该能看到。
第二行，Cre 50，没有删除，但是50这个事务还没有提交，正在进行中，所以看不见。
第三行，Cre 110，没有删除，但是100这个时间点110事务还没有发生，所以看不见。
第四行，Cre 30，Exp 80，在80的时候数据被删掉了，所以看不见。
第五行，Cre 30，Exp 75，在30的时候被创建，75时候被删掉了，但是75这个事务在100的时候还没有提交，所以这条记录在100的时候还没有删掉，所以看得见。
第六行，Cre30，Exp 110，在30的时被创建，110时候被删掉，但是在100时候，110还没有发生，所以看得见。
综上，就是这个事务对这六条记录的可见性，也就是一个数据版本。那么大家可以看一下如果另一个事务的快照里存的是最高事务编号为110，正在进行的事务为50，那么它能看到的数据应该是哪几行呢？同时大家也看到，Postgres里删除一行数据其实就是在这一行的Exp这个列记录一个删除事务的编号，相当于做了一个删除标记，而数据没有真正被删除，因此Postgres数据库需要定期做数据清理操作（Vacuum）。Pstgres的在现实场景里会比这里介绍的要复杂，因为我们这里假定所有的事务最终都是正确提交了，如果存在某些事务没有提交的情况，那么可见性就会更加复杂，这里不再展开了。
数据库事务是基本的数据库概念，之前已经有很多很好文章做过介绍，这里希望能把自己的理解用比较通俗的描述分享给大家，欢迎来讨论交流。