MySQL数据库引擎、数据事务与隔离级别

来源:转载




MySQL数据库引擎



MySQL数据库引擎取决于MySQL在安装的时候是如何被编译的。要添加一个新的引擎,就必须重新编译MYSQL。在缺省情况下,MYSQL支持三个引擎:ISAM、MYISAM和HEAP。另外两种类型INNODB和BERKLEY(BDB),也常常可以使用。标准安装程序中只提供部分引擎的支持,如果需要使用其他的存储引擎,需要使用源代码加不同的参数重新编译。其中DEFAULT表明系统的默认存储引擎,可以通过修改配置参数来变更:default-storage-engine=MyISAM。如果技术高超,还可以使用MySQL++
API自己做一个引擎。InnoDB被Oracle收购后,MySQL自行开发的新存储引擎Falcon将在MySQL6.0版本引进。下面介绍几种数据库引擎:



几种引擎简介



ISAM:ISAM是一个定义明确且历经时间考验的数据表格管理方法,它在设计之时就考虑到 数据库被查询的次数要远大于更新的次数。因此,ISAM执行读取操作的速度很快,而且不占用大量的内存和存储资源。ISAM的两个主要不足之处在于,它不
支持事务处理,也不能够容错:如果你的硬盘崩溃了,那么数据文件就无法恢复了。如果你正在把ISAM用在关键任务应用程序里,那就必须经常备份你所有的实 时数据,通过其复制特性,MYSQL能够支持这样的备份应用程序。



MyISAM:MyISAM是MySQL的ISAM扩展格式和缺省的数据库引擎。除了提供ISAM里所没有的索引和字段管理的大量功能,MyISAM还使用一种表格锁定的机制,来优化多个并发的读写操作,其代价是你需要经常运行OPTIMIZE
TABLE命令,来恢复被更新机制所浪费的空间。MyISAM还有一些有用的扩展,例如用来修复数据库文件的MyISAMCHK工具和用来恢复浪费空间的 MyISAMPACK工具。MYISAM强调了快速读取操作,这可能就是为什么MySQL受到了WEB开发如此青睐的主要原因:在WEB开发中你所进行的大量数据操作都是读取操作。所以,大多数虚拟主机提供商和INTERNET平台提供商只允许使用MYISAM格式。MyISAM格式的一个重要缺陷就是不能在表损坏后恢复数据。



HEAP:HEAP允许只驻留在内存里的临时表格。驻留在内存里让HEAP要比ISAM和MYISAM都快,但是它所管理的数据是不稳定的,而且如果在关机之前没有进行保存,那么所有的数据都会丢失。在数据行被删除的时候,HEAP也不会浪费大量的空间。HEAP表格在你需要使用SELECT表达式来选择和操控数据的时候非常有用。要记住,在用完表格之后就删除表格。



InnoDB:InnoDB数据库引擎都是造就MySQL灵活性的技术的直接产品,这项技术就是MYSQL++ API。在使用MYSQL的时候,你所面对的每一个挑战几乎都源于ISAM和MyISAM数据库引擎不支持事务处理(transaction
process)也不支持外来键。尽管要比ISAM和 MyISAM引擎慢很多,但是InnoDB包括了对事务处理和外来键的支持,这两点都是前两个引擎所没有的。如前所述,如果你的设计需要这些特性中的一者 或者两者,那你就要被迫使用后两个引擎中的一个了。



MySQL 官方对InnoDB是这样解释的:InnoDB给MySQL提供了具有提交、回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读,这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要,因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN
KEY强制。在SQL查询中,你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来,甚至在同一个查询中也可以混合。



InnoDB是为处理巨大数据量时的最大性能设计,它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。



InnoDB存储引擎被完全与MySQL服务器整合,InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB存储它的表&索引在一个表空间中,表空间可以包含数个文件(或原始磁盘分区)。这与MyISAM表不同,比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何尺寸,即使在文件尺寸被限制为2GB的操作系统上。



InnoDB默认地被包含在MySQL二进制分发中。Windows Essentials installer使InnoDB成为Windows上MySQL的默认表。



InnoDB被用来在众多需要高性能的大型数据库站点上产生。著名的Internet新闻站点Slashdot.org运行在InnoDB上。 Mytrix, Inc.在InnoDB上存储超过1TB的数据,还有一些其它站点在InnoDB上处理平均每秒800次插入/更新的。




Innodb引擎 VS.MyIASM引擎



Innodb引擎
Innodb引擎提供了对数据库ACID事务的支持,并且实现了SQL标准的四种隔离级别,关于数据库事务与其隔离级别的内容请见数据库事务与其隔离级别这篇文章。该引擎还提供了行级锁和外键约束,它的设计目标是处理大容量数据库系统,它本身其实就是基于MySQL后台的完整数据库系统,MySQL运行时Innodb会在内存中建立缓冲池,用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引,而且它没有保存表的行数,当SELECT COUNT(*) FROM TABLE时需要扫描全表。当需要使用数据库事务时,该引擎当然是首选。由于锁的粒度更小,写操作不会锁定全表,所以在并发较高时,使用Innodb引擎会提升效率。但是使用行级锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表。



MyIASM引擎
MyIASM是MySQL默认的引擎,但是它没有提供对数据库事务的支持,也不支持行级锁和外键,因此当INSERT(插入)或UPDATE(更新)数据时即写操作需要锁定整个表,效率便会低一些。不过和Innodb不同,MyIASM中存储了表的行数,于是SELECT COUNT(*)
FROM TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读操作远远多于写操作且不需要数据库事务的支持,那么MyIASM也是很好的选择。
两种引擎的选择:
大尺寸的数据集趋向于选择InnoDB引擎,因为它支持事务处理和故障恢复。数据库的大小决定了故障恢复的时间长短,InnoDB可以利用事务日志进行数据恢复,这会比较快。主键查询在InnoDB引擎下也会相当快,不过需要注意的是如果主键太长也会导致性能问题,关于这个问题我会在下文中讲到。大批的INSERT语句(在每个INSERT语句中写入多行,批量插入)在MyISAM下会快一些,但是UPDATE语句在InnoDB下则会更快一些,尤其是在并发量大的时候。



一般来说,MyISAM适合:(1)做很多count 的计算;(2)插入不频繁,查询非常频繁;(3)没有事务。InnoDB适合:(1)可靠性要求比较高,或者要求事务;(2)表更新和查询都相当的频繁,并且表锁定的机会比较大的情况。



查看、修改数据引擎



一般情况下,MySQL会默认提供多种存储引擎,可以通过下面的查看:



(1)看你的MySQL现在已提供什么存储引擎:
mysql>show engines;



(2)看你的MySQL当前默认的存储引擎: mysql>show variables like '%storage_engine%';



(3)你要看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎): mysql>show create table 表名;


1.可以在启动数据库服务器时在命令行后面加上–default-storage-engine或–default-table-type选项。
2.更灵活的方式是在随MySQL服务器发布同时提供的MySQL客户端时指定使用的存储引擎。最直接的方式是在创建表时指定存储引擎的类型,向下面这样:
CREATE TABLE mytable (id int, titlechar(20)) ENGINE = INNODB
修改表的存储引擎:
ALTER TABLE engineTest ENGINE = INNODB;
修改默认存储引擎:
在mysql配置文件(linux下为/etc/my.cnf),在mysqld后面增加default-storage-engine=INNODB即可。

但是如果表建立的时候是MyISAM,要更改整个数据库表的存储引擎,一般要一个表一个表的修改,比较繁琐,可以采用先把数据库导出,得到SQL,把MyISAM修改成INNODB,再导入的方式。


数据库事务


数据库事务概念与生命周期


事务是指一组相互依赖的操作行为,如银行交易、股票交易或网上购物。事务的成功取决于这些相互依赖的操作行为是否都能执行成功,只要有一个操作行为失败,就意味着整个事务失败。例如,Tom到银行办理转账事务,把100元钱转到Jack的账号上,这个事务包含以下操作行为:



–(1)从Tom的账户上减去100元。



–(2)往Jack的账户上增加100元。



•显然,以上两个操作必须作为一个不可分割的工作单元。假如仅仅第一步操作执行成功,使得Tom的账户上扣除了100元,但是第二步操作执行失败,Jack的账户上没有增加100元,那么整个事务失败。



•数据库事务是对现实生活中事务的模拟,它由一组在业务逻辑上相互依赖的SQL语句组成。


事务用来管理insert,update,delete语句
一般来说,事务是必须满足4个条件(ACID): Atomicity(原子性)、Consistency(稳定性)、Isolation(隔离性)、Durability(可靠性)
1、原子性:一组事务,要么成功;要么撤回。
2、稳定性 : 有非法数据(外键约束之类),事务撤回。
3、隔离性:事务独立运行。一个事务处理后的结果,影响了其他事务,那么其他事务会撤回。事务的100%隔离,需要牺牲速度。
4、可靠性:软、硬件崩溃后,InnoDB数据表驱动会利用日志文件重构修改。可靠性和高速度不可兼得, innodb_flush_log_at_trx_commit选项 决定什么时候吧事务保存到日志里。


生命周期:




声明事务的边界



•事务的开始边界。



•事务的正常结束边界(COMMIT):提交事务,永久保存被事务更新后的数据库状态。



•事务的异常结束边界(ROLLBACK):撤销事务,使数据库退回到执行事务前的初始状态。



在mysql.exe中声明事务



•每启动一个mysql.exe程序,就会得到一个单独的数据库连接。每个数据库连接都有个全局变量@@autocommit,表示当前的事务模式,它有两个可选值:



–0:表示手工提交模式。



–1:默认值,表示自动提交模式。



•如果要察看当前的事务模式,可使用如下SQL命令:



–mysql> select @@autocommit



•如果要把当前的事务模式改为手工提交模式,可使用如下SQL命令:



–mysql> set autocommit=0;





——在自动提交模式下提交事务:



•在自动提交模式下,每个SQL语句都是一个独立的事务。如果在一个mysql.exe程序中执行SQL语句:



–mysql>insert into ACCOUNTS values(1,'Tom',1000);



•MySQL会自动提交这个事务,这意味着向ACCOUNTS表中新插入的记录会永久保存在数据库中。此时在另一个mysql.exe程序中执行SQL语句:



–mysql>select * from ACCOUNTS;



•这条select语句会查询到ID为1的ACCOUNTS记录。这表明在第一个mysql.exe程序中插入的ACCOUNTS记录被永久保存,这体现了事务的ACID特性中的持久性。


——在手工模式下提交事务:



•在手工提交模式下,必须显式指定事务开始边界和结束边界:



–事务的开始边界:begin



–提交事务:commit



–撤销事务:rollback



例:



–mysql>begin;
–mysql>select * from ACCOUNTS;
–mysql>commit;


通过JDBC API声明事务边界



• Connection提供了以下用于控制事务的方法:



–setAutoCommit(boolean autoCommit):设置是否自动提交事务



–commit():提交事务



–rollback():撤销事务



例:

try {
con = java.sql.DriverManager.getConnection(dbUrl,dbUser,dbPwd);
//设置手工提交事务模式
con.setAutoCommit(false);
stmt = con.createStatement();
//数据库更新操作1
stmt.executeUpdate("update ACCOUNTS set BALANCE=900 where ID=1 ");
//数据库更新操作2
stmt.executeUpdate("update ACCOUNTS set BALANCE=1000 where ID=2 ");
con.commit(); //提交事务
}catch(Exception e) {
try{
con.rollback(); //操作不成功则撤销事务
}catch(Exception ex){
//处理异常
……
}
//处理异常
……
}finally{…}

通过Hibernate API声明事务边界



•声明事务的开始边界:Transaction tx=session.beginTransaction();



•提交事务: tx.commit();



•撤销事务: tx.rollback();


多个事务并发时的并发问题



•第一类丢失更新:撤销一个事务时,把其他事务已提交的更新数据覆盖。



•脏读:一个事务读到另一事务未提交的更新数据。



•虚读:一个事务读到另一事务已提交的新插入的数据。



•不可重复读:一个事务读到另一事务已提交的更新数据。



•第二类丢失更新:这是不可重复读中的特例,一个事务覆盖另一事务已提交的更新数据。


以取款事务和支票转账事务例



•取款事务包含以下步骤:



–(1)某银行客户在银行前台请求取款100元,出纳员先查询账户信息,得知存款余额为1000元。



–(2)出纳员判断出存款额超过了取款额,就支付给客户100元,并将账户上的存款余额改为900元。



•支票转账事务包含以下步骤:



–(1)某出纳员处理一转帐支票,该支票向一帐户汇入100元。出纳员先查询账户信息,得知存款余额为900元。



–(2)出纳员将存款余额改为1000元。






并发运行的两个事务导致脏读




取款事务在T5时刻把存款余额改为900元,支票转账事务在T6时刻查询账户的存款余额为900元,取款事务在T7时刻被撤销,支票转账事务在T8时刻把存款余额改为1000元。



由于支票转账事务查询到了取款事务未提交的更新数据,并且在这个查询结果的基础上进行更新操作,如果取款事务最后被撤销,会导致银行客户损失100元。



并发运行的两个事务导致第二类更新丢失






取款事务在T5时刻根据在T3时刻的查询结果,把存款余额改为1000-100元,在T6时刻提交事务。支票转账事务在T7时刻根据在T4时刻的查询结果,把存款余额改为1000+100



元。由于支票转账事务覆盖了取款事务对存款余额所做的更新,导致银行最后损失100元。

数据库的隔离级别





(1)隔离级别与并发性能的关系




(2)设置隔离级别的原则



•隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大。



•对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed,它能够避免脏读,而且具有较好的并发性能。尽管它会导致不可重复读、虚读



和第二类丢失更新这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁乐观锁来控制。





(3)在mysql.exe程序中中设置隔离级别



•每启动一个mysql.exe程序,就会获得一个单独的数据库连接。每个数据库连接都有个全局变量@@tx_isolation,表示当前的事务隔离级别。MySQL默认的隔离



级别为Repeatable Read。如果要察看当前的隔离级别,可使用如下SQL命令:



–mysql> select @@tx_isolation;



•如果要把当前mysql.exe程序的隔离级别改为Read Committed,可使用如下SQL命令:



–mysql> set transaction isolation level read committed;





(4)在Hibernate中设置隔离级别




•在Hibernate的配置文件中可以显式的设置隔离级别。每一种隔离级别都对应一个整数:


–1:Read Uncommitted



–2:Read Committed



–4:Repeatable Read


–8:Serializable


•例如,以下代码把hibernate.cfg.xml文件中的隔离级别设为Read Committed:



hibernate.connection.isolation=2



对于从数据库连接池中获得的每个连接,Hibernate都会把它改为使用Read Committed隔离级别。


参考材料


【整理】MySQL引擎



MySQL修改默认存储引擎



MySQL数据库引擎详解



MySQL数据库引擎介绍、区别、创建和性能测试的深入分析



数据库事务与隔离级别






博客内容仅作学习/交流/参考之用,欢迎大家交流探讨;E-Mail:dwang2014#hotmail.com(#
——> @)



如果内容信息侵犯了您的合法权益,请告知我,我将及时处理。



站在巨人的肩上才能看得更远,一步一个脚印才能走得更远。分享成长,交流进步,转载请注明出处!

分享给朋友:
您可能感兴趣的文章:
随机阅读: