今天有些累了，废话我在这里就不跟大家多说了，直接上图.
Server Initialization Module
服务器初始化模块负责服务器在启动时初始化。大部分的代码文件中的sql/mysqld.cc发现。入口点是一个C/c++程序员期望:main()。感兴趣的其他一些功能。如果文件没有提到的,位置是sql/mysqld.cc:
init_common_variables( ) init_thread_environment( ) init_server_components( ) grant_init( ) in sql/sql_acl.cc init_slave( ) in sql/slave.cc get_options( )
虽然3.22版本中的代码发现从未从头重写,被显著地重构为新功能被添加到MySQL。One big chunk的块初始化代码,用于在main()得到重组逐渐变成一个许多辅助函数代码的一生。此外,该命令行和配置文件选项解析从GNU getopt()转向了MySQL核心API选项解析器在4.0版本一旦可用。在version 5.1中,很大一部分是添加到init_server_components()插件初始化.总的来说,这一地区的代码是相当稳定的。基于过去的历史,我们应该预测未来可能的增量增加新功能要求特别在启动时初始化。然而,重写的代码是不可能的。
Connection Manager
连接管理器侦听传入的连接的客户,和分派线程管理器的请求。这个模块实际上只是一个函数sql/mysqld。答:handle_connections_sockets()。然而,它应该被归类为一个单独的模块由于其关键作用的操作服务器。丰富# ifdef指示说,将网络代码移植到一个的挑战各种各样的操作系统。随着时间的推移，代码的演变有所适应网络系统的 quirks 不同的操作系统调用。进一步的变化可能在是必要的 未来的新港口的企图，或为不同的操作系统厂商介绍 在他们产品的新版本的新特性。
Thread Manager
线程管理器是负责跟踪的线程并确保一个线程被分配到处理来自客户端的连接。这又是一个很小模块。大部分代码是在SQL/mysqld.cc发现。入口点是CREATE_new_thread（）。另一个感兴趣的功能start_cached_thread（），在定义同一个文件。一个也许可以考虑THD类SQL / sql_class.h定义和实现在SQL / sql_class.cc作为本模块的一部分。总谐波失真类型的对象是线程描述符，并且是在关键的多数服务器模块的操作。许多功能采取THD指针作为第一个参数。线程管理代码是在3.23版本显著返工时，线程缓存增加了。从那时起，它一直没有被显著改变。这是合理的期待它不会在将来收到任何显著的变化。但是，如果我们在我们的抽象，考虑THD类本身作为本单元的一部分，我们有一个不同的故事，尽可能的变化有关。新加入如准备语句，服务器端游标和存储过程的特点，LED的THD在版本4.1和5的重大返工。它现在是一个超类的query_arena，声明，security_context，和Open_tables_state类在sql / sql_class.h也定义。
Connection Thread
连接线程处理客户机请求的工作的核心建立连接。这个模块也是非常小的。它由一个功能: 在sql/sql_parse.cc handle_one_connection()。然而,尽管它的大小,它应该被列为一个模块由于其在服务器的角色。代码的发展随着时间的推移,逐渐变得更加紧凑和可读的是不同的初始化(THD类已涉及的变量都被感动了。它是合理的希望代码在未来不会改变太多。
User Authentication Module
用户身份验证模块验证连接用户和初始化包含信息的结构和变量水平的特权。的这个模块入口点是check_connection sql / sql_parse.cc()。然而,其他的功能是在sql/sql_acl找到。cc和sql/password.cc。一些有趣的功能检查包括:
acl_check_host( ) in sql/sql_acl.cc create_random_string( ) in sql/password.cc check_user( ) in sql/sql_parse.cc acl_getroot( ) in sql/sql_acl.cc
代码已经明显只修改了一次,在版本4.1。由于可能的的影响变化,MySQL开发人员尝试前等了一会儿协议的更新需要实现一个更安全的身份验证.从那时起,这段代码也没有太多变化。然而,通过添加5.1插件功能的MySQL开发人员计划添加可插拔身份验证和角色功能,这就需要这段代码的变化。
Access Control Module
访问控制模块验证客户端用户拥有足够的权限执行所请求的操作。大部分的代码是在sql/sql_acl.cc。然而,一个最常用的功能,check_access(),是在sql/sql_parse.cc找到。一些感兴趣的其他功能,全部位于sql / sql_acl。cc除非另有indicated:
check_grant( ) check_table_access( ) in sql/sql_parse.cc check_grant_column( ) acl_get( )
代码本身没有改变非常自3.22版。然而,新的特权类型被添加在version 4.0中,这有点改变了这个模块的方式用剩下的代码。MySQL开发人员计划添加支持角色,这将需要进行大量更改这个模块。
Parser
解析器负责解析查询，并生成一个解析树。入门点mysql_parse（）在SQL/ sql_parse.cc，它执行一些初始化和然后调用yyparse（），由GNU Bison从生成的SQL/sql_yacc.cc功能 SQL/sql_yacc.yy，其中包含理解SQL语言的子集的定义 由MySQL。请注意，与许多开源项目，MySQL有自己的生成的词法扫描器，而不是使用LEX。一些相关的文件，除了刚才提到的那些，包括：
sql/gen_lex_hash.cc sql/lex.h sql/lex_symbol.h sql/lex_hash.h (generated file) sql/sql_lex.h sql/sql_lex.cc The group of files under sql/ with names starting in item_ and extensions of .h or .cc
添加新的SQL特性,解析器不断改变来适应他们。然而,解析器的核心结构非常稳定,迄今为止,能够容纳的增长。这是合理的期望,虽然一些元素将被添加,非常核心不会改变一段时间.MySQL开发人员一直在,有时仍然是讨论的核心重写解析器和移动它远离yacc /Bison,让它更快。然而,他们有在谈论至少7年了,这还没有成为一个优先级
Command Dispatcher
指挥调度程序负责指挥对低层的请求模块会知道如何解决它们。它由两个函数的sql/sql_解析。答:do_command()和dispatch_command()。该模块不断随着时间的推移增加支持的命令集。小增长预计在未来,但不太可能改变的核心结构。
Query Cache Module
查询缓存模块缓存查询结果,and tries to short-circuit the execution 尽可能提供缓存的查询的结果。它是如何实现的在sql/sql_cache.cc。感兴趣的一些方法包括:
Query_cache::store_query( ) Query_cache::send_result_to_client( )
Optimizer
优化器是负责创建最好的策略来回答查询,和执行提供结果给客户端。它可能是最复杂的模块在MySQL代码。入口点是mysql_select sq /sql_select.cc()。sql/sql_select。cc,包括
JOIN::prepare( ) JOIN::optimize( ) JOIN::exec( ) make_join_statistics( ) find_best_combination( ) optimize_cond( )
当你陷入优化器的深处，有一个值得参观的洞穴。它是范围的优化，并从优化核心和足够复杂的分离可以分离到一个单独的文件，SQL / opt_range.cc。范围优化负责使用密钥与一个给定的值的范围或一组查询优化范围。用于范围优化器的切入点是sql_select：：test_quick_select（）。优化器一直处于变化的状态。4.1子查询的加法增加了一层复杂性。5版增加了一个贪婪搜索优化表的连接顺序，并有能力每桌使用几个键（索引合并）。它是合理的预期，更多的变化将在未来。一个期待已久的变化是在子查询的优化改进。
Table Manager
表管理器负责创建、读取、修改表定义文件(。纳扩展),维护表描述符称为表的缓存缓存和管理表级锁。大部分的代码是在sql/sql_base.cc发现,sql /表。cc、sql / unireg。cc和sql / lock.cc。 include:
openfrm( ) in sql/table.cc mysql_create_frm( ) in sql/unireg.cc open_table( ) in sql/sql_base.cc open_tables( ) in sql/sql_base.cc open_ltable( ) in sql/sql_base.cc mysql_lock_table( ) in sql/lock.cc
3.22版本的代码并没有太大改变,除了新表定义在4.1版本的文件格式。在过去,蒙蒂表示不满表中的低效缓存代码,想重写它。有一段时间,这一点不是一个首要任务。然而,在5.1版本终于取得了一些进展。
Table Modification Modules
这组模块负责操作,如创建、删除、重命名,删除、更新或插入到表中。这实际上是一个非常重要块的代码。不幸的是,由于空间的限制,这本书不会覆盖在细节。然而,一旦你熟悉余下的代码,你应该能够找出细节通过阅读源代码和使用调试器码没有太多的麻烦,从入口点如下:mysql_update()and mysql_multi_update() ins ql/sql_update.cc
mysql_insert( ) in sql/sql_insert.cc mysql_create_table( ) in sql/sql_table.cc mysql_alter_table( ) in sql/sql_table.cc mysql_rm_table( ) in sql/sql_table.cc mysql_delete( ) in sql/sql_delete.cc
更新和删除模块在版本4.0已经发生重大的改变 添加多表更新和删除。一些重组也发生 在更新,插入和删除模块支持在4.1版本准备好的语句 在5.1和触发器。否则,除了相当轻微的改善 时间,他们并没有改变多少。它很大程度上是合理的预期
Table Maintenance Module
表维护模块负责表等维护操作检查、修理、备份、恢复、优化(整理),并分析(更新密钥分布统计信息)。代码是在sql/sql_table.cc找到。核心功能是mysql_admin_table(),方便包装如下:
mysql_check_table( ) mysql_repair_table( ) mysql_backup_table( ) mysql_restore_table( ) mysql_optimize_table( ) mysql_analyze_table( )
mysql_admin_table()将进一步分派请求到适当的存储引擎的方法。大部分发生在存储引擎的工作水平。该模块是在版本3.23中引入的提供表的SQL接口维护。表维护前必须执行离线。在版本 4.1,大大改变了网络协议模块支持的准备语句。这影响了所有的模块谈话回客户端,包括表维护模块。否则,不自引入以来,发生了很大的改变,这是合理的期望,没有多少将在未来实现之
Status Reporting Module
状态报告模块负责回答查询服务器配置设置,性能跟踪变量,表结构信息,复制进步,条件表的缓存和其他东西。它处理查询首先显示。大部分的代码是在sql/sql_show.cc找到。一些功能兴趣,所有在sql/sql_show。cc除非表示,否则,有:
mysqld_list_processes( ) mysqld_show( ) mysqld_show_create( ) mysqld_show_fields( ) mysqld_show_open_tables( ) mysqld_show_warnings( ) show_master_info( ) in sql/slave.cc show_binlog_info( ) in sql/sql_repl.cc
该模块不断进化。添加新功能需要额外的状态报告。这是合理的期望,这种模式在未来将继续。
Abstracted Storage Engine Interface (Table Handler)
这个模块实际上是一个抽象类处理程序和结构称为命名handlerton。handlerton结构添加插件集成在5.1版本中。它提供了一个标准化的接口来执行低级的存储和检索操作。中定义的表夹头是sql /处理程序。h和部分sql/handler.cc中实现。派生的特定存储引擎类必须实现所有的纯虚拟这个类的方法。它将在第9章中详细讨论。这个模块是在版本3.23中引入的促进伯克利的集成数据库表。这一举动有深远的影响:现在各种底层存储引擎可以把大量的轻松地在MySQL。的代码期间进一步完善InnoDB的集成。
Storage Engine Implementations (MyISAM, InnoDB, MEMORY, Berkeley DB)
每一个存储引擎提供了一个标准接口的操作 扩展前面提到的处理程序类。派生类的方法 定义的标准接口操作的低级调用的特定方面 存储引擎。这个过程和个人存储引擎将在讨论 细节在第10章。与此同时,对于一个简短的介绍,您可能想要 看一些感兴趣的文件和目录:
sql/ha_myisam.h and sql/ha_myisam.cc sql/ha_innodb.h and sql/ha_innodb.cc sql/ha_heap.h and sql/ha_heap.cc sql/ha_ndbcluster.h and sql/ha_ndbcluster.cc myisam/ innobase/ heap/ ndb/
当存储引擎接口是第一次抽象(版本3.23),只有三个功能齐全的存储引擎:MyISAM ISAM MyISAM(老版本),和记忆。(注意,被称为堆使用的内存存储引擎,和一些文件和目录名称的源树仍然反映了早些时候的名字。)然而,与添加BerkeleyDB迅速增长,合并,InnoDB,最近,NDB MySQL集群。大多数存储引擎依然相当活跃的开发中,我们可能会看到一些在未来新的补充道。
L0o2gging Module
日志记录模块负责维持较高级别的（逻辑）的日志。存储发动机可以另外保持自身的较低级别（物理或逻辑）的日志达到自己的目的，但日志记录模块不会与有关人员;该存储引擎本身负责。在这一点上的逻辑日志包括二进制更新日志（主要用于复制，不然） ，命令日志（主要用于服务器监控和应用程序调试） ，和慢查询日志（用于跟踪进行了优化不好的查询） 。在版本5.1之前，该模块被包含在大多数情况下由类MYSQL_LOG ，在SQL / sql_class.h定义和SQL / log.cc实施。 5.1版带来了重写这个模块。现在存在的日志管理类的层次结构，并MYSQL_LOG是超一流TC_LOG的，这两者在SQL / LOG.H定义。然而，大多数在伐木的工作发生在二进制复制日志。该类事件日志创建和读取的二进制复制日志中定义SQL/log_event.h和SQL /log_event.cc实施。无论是复制和法师
复制从模块在很大程度上依赖于日志记录模块的这一功能。显著变化对这一模块进行与引进的复制。5.0版带来了所需的XA事务的一些变化。 5.1版
添加的能力来搜索日志，好像他们是一个SQL表，它需要一个显著重构这段代码。二进制日志记录部分所需要显著变化以适应基于行的复制。在这一点上是很难预料的地方这段代码会在未来。
Replication Master Module
复制主站模块负责对复制功能master。最常见的操作此模块是提供一个连续进料 复制日志事件应要求奴隶。大部分代码是在SQL发现/sql_repl.cc。其核心功能是mysql_binlog_send（）。ParserLogging该模块中添加了3.23版本，它并没有经历任何重大 变化不是一个彻底的清除隔离的代码块到其他功能。在开始的时候，代码有故障安全的复制非常雄心的发展计划。然而，这些计划可以实现之前，MySQL的收购NDB簇从爱立信的代码，并开始寻求另一条路线，以自动的最终目标故障转移。鉴于这些事态发展，目前尚不清楚在这一点上如何原生MySQL复制才会进步。
Replication Slave Module
复制从站模块 复制从站模块负责的复制功能 奴隶。从站的作用是获取从主更新，并应用它们在从节点。在开始4.0版本的奴隶是两个线程。网络I/ O线程 请求，并接收来自主更新的连续进料，并将其记录在 本地中继日志。 SQL线程应用它们，因为它从中继日志读取它们。 此模块的代码在SQL/ slave.cc被发现。最重要的功能，以 学习是handle_slave_io（）和handle_slave_sql（）。 该模块中添加了3.23一起复制主站模块。它去 通过在4.0版时，单片从属线程是一个重大变化 分解成SQL线程和I/O线程。
Client/Server Protocol API
MySQL客户端/服务器通信协议的顶端安装操作系统协议(TCP/IP或本地套接字)在协议栈。这个模块实现API用于服务器创建、读取、解释,并发送协议 包。代码是在sql /协议。cc、sql /协议。h和sql / net_serv.cc。 sql /协议的文件。h和sql /协议。cc定义和实现一个类的层次结构。协议是基类,Protocol_simple Protocol_prep,Protocol_cursor 源于它。一些感兴趣的功能模块有:
my_net_read( ) in sql/net_serv.cc my_net_write( ) in sql/net_serv.cc net_store_data( ) in sql/protocol.cc send_ok( ) in sql/protocol.cc send_error( ) in sql/protocol.cc
在版本4.0协议改为支持4 GB大小的数据包。之前,极限是24 MB。4.1版本的协议增加了类层次结构准备好的语句。看来在这一点上的大部分问题地区在这个层次的协议解决,这是合理的 希望这段代码将在不久的将来不能在很大程度上改变。然而, MySQL开发人员正在考虑添加支持通知。
Low-Level Network I/O API
底层网络I/O API提供了一个抽象的底层网络I/O和SSL会话。代码在vio/目录中找到。所有的功能在这模块名称从vio_开始。介绍了该模块在3.23中,由于需要支持SSL连接。抽象底层网络I / O也促进移植到新的平台and maintaining the old ports
Core API
核心API是MySQL的瑞士×××。它提供了便携功能文件I/O 、内存管理、字符串操作,文件系统导航,格式化印刷、丰富的数据结构和算法的集合,和许多其他的事情。如果一个问题时,通常有一个解决方案的核心API模块。如果没有,它将被编码。此模块在很大程度上是一个蒙蒂的表达的能力和决心永远只解决一个问题。这是也许MySQL的奇迹的核心组件。代码是mysys /和字符串/目录中找到。的许多核心API函数有名字从my_开始。模块一直处于成长和进步。随着新功能是补充说,伟大的保健投入保持其稳定性和高水平+的性能。这是合理的期望
如下图所示MySQL的逻辑架构图：
第一层：
Connection/thread handling 第一层的服务并不是MySQL所独有的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构,比如连接处理，授权认证、安全等等。
第二层：
核心层 MySQL实现的
第二层架构是MySQL比较有意思的部分，大多数MySQL的核心服务功能都在这一层，包括查询解析器，分析，优化，缓存以及所有的内置函数(例如，日期、时间、数学和加密函数)，所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。
第三层：
第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取.
优化与执行
MySQL 会解析查询，并创建内部结构(解析树)，然后对其进行各种优化，包括重写查询，决定表的读取顺序，以及选择合适的索引等。用户通过特殊的关键字提示(hint)优化器，影响它的决策过程。也可以请求优化解释(explain) 优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参数基准，便于用户重构查询和schema、修改相关配置。使应用尽可能高效运行。
优化器并不关系表适用的是什么存储引擎，但存储引擎对于优化查询是有影响。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。
对于select语句，在解析查询之前，服务器会先检查查询缓存(query Cache)，如果能够在起重工找到对应的查询,服务器就不必再执行查询解析、优化和执行的整个过程而是直接返回查询缓存中的结果集.
并发控制
无论何时，只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。
读写锁
从邮箱读取数据没有这样的麻烦，即使同一时刻多个用户并发读取也不会有什么问题，因为读取数据不会修改数据，所以不会出错，但是如果某个用户正在读取邮箱，同时另一外一个用户试图删除邮箱中的数据，会产生什么结果？结果是不确定的，读的用户可能会报错退出，也可能读到了不一致的邮箱数据，所以安全起见，即使是读取邮箱也需要特别注意。
如果把上述的邮箱当做成数据库中的一张表，把邮件当成表中的一行记录，就很容易看出，同样的问题依然存在，在很多方面来说，邮箱就是一张简单的数据库表，修改数据库表中的记录，和删除或者修改休想中的信息十分类似。
解决这类经典问题的方法就是并发控制，其实非常简单，在处理方法读或者写时，可以通过实现一个由两种类型的锁组成的锁系统来解决问题。这两种类型的锁通常被称为共享锁(shared lock)和排他锁(exclusive lock)，也叫读锁(read lock)和写锁(write lock)，读锁是共享的，或者说是互相不阻塞的，多个客户在同一时刻可以同时读取同一资源，而互不干扰，写锁则是排他的，u、也就是说一个写锁会阻塞其它的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。
锁粒度
一种提高共享资源并发性的方式就是让锁定对象更有选择性，尽量只锁定需要修改的部分数据，而不是所有的资源，更理想的方式是，只对修改的数据片进行精确的锁定，任何时候在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可
问题是加锁也需要消耗资源，锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会受到影响，
所谓的锁策略，就是在锁开销和数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库系统没有提供更多的选项，一般都是在表上施加行级锁(row-level lock)，并以各种复杂的方式来实现，以便在锁比较多的情况下尽可能提供更好的性能。
而MySQL则提供了多种选择。每种MySQL存储引擎都可以实现自己的锁策略和锁粒度。在存储引擎的设计中，锁管理是个非常重要的决定，将锁粒度固定在某个级别，可以为某些特定的应用场景提供更高的性能，但同时却会失去对另外一些应用场景的良好支持。好在MySQL支持多个存储引擎的架构，所以不需要单一的通用解决方案。
Table Lock
表锁是MySQL中最基本的锁策略，并且是开销最小的策略，表锁它会锁定整张表，一个用户对表进行写操作(插入、删除、更新等)前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不相互阻塞的。
尽管存储引擎可以管理自己的锁，MySQL本身还是会使用各种有效的表锁来实现不同的目的，
Row Lock
行级锁可以最大程度地支持并发处理(同时可带来了最大的锁开销)。众所周知，在InnoDB和xtraDB，以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层次实现。而MySQL服务器层没有实现，服务器层完全不了解存储引擎中的锁实现，所有的存储引擎都以自己的方式显示了锁机制。 读锁：只能读不能写(共享锁)(非阻塞) 写锁：独占锁，排它锁(阻塞) (粒度越小，开销越大，但并发性越好：) (粒度越大，开销越小，但并发性越差：)
MVCC：多版本并发控制MVCC的实现，是通过保存数据库在某个时间点的快照来实现的,也就是说，不管执行多长时间，每个事务看到的数据都是一致的，根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能不一样的，
每个事务启动时，InnoDB为每个启动的事务提供一个当下时刻的快照
为了实现此功能,InnoDB会为每个表提供两个隐藏的字段，一个用于保存行的创建时间，一个用于保存行的失效时间；
里面存储的是系统版本号：(system version number)
两个隔离级别下有效：read committee 和 repeatable read
MySQL中的事务
MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。另外还有一些第三方存储引擎也支持事务,比较知名的包括xtraDB和PBXT，
自动提交(AUTOCOMMIT)
MySQL默认采用自动提交(AUTOCOMMIT)模式。也是就是说，如果不是显式地开始一个事务，则每个查询都被当做一个事务执行提交操作，在当前连接中，可以通过设置AUTOCOMMIT变量来启用或禁用自动提交模式：
mysql> show variables LIKE 'AUTOCOMMIT'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+ 1 row in set (0.00 sec) mysql> set AUTOCOMMIT = 1; Query OK, 0 rows affected (0.00 sec)
1或者ON表示启用，0或者OFF表示禁用。当AUTOCOMMIT=0时，所有的查询都是在一个事务中，直到显式地执行COMMIT提交或者ROLLBACK回滚，该事务结束,同时又开始了另一个新事务。MySQL可以通过执行 SET TRANSACTION ISOLATION LEVEL 使命来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前会话的隔离级别
mysql> set session transaction isolation level READ COMMITTED; Query OK, 0 rows affected (0.00 sec)
MySQL 能够识别所有的4个ANSI隔离级别，InnoDB引擎也支持所有的隔离级别。4个ANSI隔离级别请参考http://zhangxiaocen.blog.51cto.com/7933682/1390479
读锁：只能读不能写(共享锁)(非阻塞) 写锁：独占锁，排它锁(阻塞)
隐式和显示锁定
InnoDB 采用的是两个阶段锁协议(two-phase locking protocol)。 在事务执行过程中，随时都可以执行锁定，锁定只有在执行commit或者rollback的时候才会释放，并且所有的锁是在同一时刻被释放.
另外,InnoDB也支持通过特定的语句进行显式锁定，这些语句不属于SQL规范；
select .....lock in share mode
select...for update；
MySQL也支持 LOCK TABLES 和UNLOCK TABLES 语句，这是服务器层实现的，很存储引擎无关。它们有自己的用途，但并不能替代事务处理，如果应用需要用到事务，还是应该选择事务型存储引擎。
事务：transaction 事务详解请参考： http://zhangxiaocen.blog.51cto.com/7933682/1390479
事务就是一组原子性的查询语句，也即将多个查询当作一个独立的工作单元。
ACID 测试： 能满足ACID测试就表示其支持事务，或兼容事务。
A： 原子性
C:consistency，一致性
I：Isolation，隔离性，一个事务的所有修改操作在提交之前对其它事务是不可见的。
D: durability ， 持久性，一旦事务得到提交，其所做的修改会永久有效
跟事务相关的常用命令；
mysql>start transaction # 启用事务
mysql>commit # 提交事务 ，在提交事务之前应该有SQL语句的执行过程；
mysql>rollback # 回滚事务，回滚到开启事务的那个点
mysql>savepoint identifier # 设置事务的point
mysql>rollback to [savepoint] identifier # 回滚到当前事务的point
查看mysql的事务隔离级别
mysql> show global variables LIKE 'tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | # 可重读 +---------------+-----------------+ 1 row in set (0.01 sec)
mysql>select @@global.tx.isolation
MySQL： 存储引擎：表级别 存储引擎也通常称作“表类型”
mysql>show engines； mysql>show tables status [LIKE clause] [where clause] show table status in hellodb LIKE 'classes'\G
建议：对事务要求不特别严格的场景下，可以使用读提交
如果没有显式启动事务，每个语句都会当作一个独立的事务，其执行完成后会被自动提交；
mysql> SELECT @@global.autocommit; mysql> SET GLOBAL autocommit = 0;
MySQL存储引擎： 存储引擎也通常称作“表类型”
mysql> SHOW TABLES STATUS [LIKE clause] [WHERE clause]
SHOW TABLE STATUS [{FROM | IN} db_name]
[LIKE 'pattern' | WHERE expr]
mysql> SHOW TABLE STATUS IN hellodb WHERE Name='classes'\G
*************************** 1. row ***************************
Name: classes
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 8
Avg_row_length: 2048
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 9437184
Auto_increment: 9
Create_time: 2014-04-08 11:14:52
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.01 sec)
Name: 表名
Engine: 存储引擎
Version: 版本
Row_format: 行格式
{DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
Rows: 表中的行数
Avg_row_length: 平均每行所包含的字节数；
Data_length: 表中数据总体大小，单位是字节
Max_data_length: 表能够占用的最大空间，单位为字节
Index_length: 索引的大小，单位为字节
Data_free: 对于MyISAM表，表示已经分配但尚未使用的空间，其中包含此前删除行之后腾出来的空间
Auto_increment: 下一个AUTO_INCREMENT的值；
Create_time: 表的创建时间；
Update_time：表数据的最近一次的修改时间；
Check_time：使用CHECK TABLE或myisamchk最近一次检测表的时间；
Collation: 排序规则
Checksum: 如果启用，则为表的checksum；
Create_options: 创建表时指定使用的其它选项；
Comment: 表的注释信息
InnoDB：
两种格式
1、InnoDB_file_per_table=OFF， 即使用共享表空间
每张表一个独有的格式定义文件：ta_name.frm
还一个默认位于数据目录下共享的表空间文件：ibdata#
2、InnoDB_file_per_table=ON，即使用独立表空间
每个表在数据库目录下存储两个文件：
tb_name.frm
tb_name.idb
表空间： table space，有InnoDB管理的特有格式数据文件，内部可同时存储数据和索引
如何修改默认存储引擎：通过default_storage_engine服务变量实现
MyISAM:
每个表都在数据库目录下存储三个文件：
tb_name.frm
tb_name.MYD
tb_name.MYI
表空间：table space，由InnoDB管理的特有格式数据文件，内部可同时存储数据和索引
如何修改默认存储引擎：通过default_storage_engine服务变量实现
各存储引擎的特性：
InnoDB：
事务：事务日志
外键：
MVCC：
聚簇索引：
聚簇索引之外的其它索引，通常称为辅助索引
行级锁：间隙锁
支持辅助索引
支持自适应hash索引
支持热备份
MyISAM:
全文索引
压缩：用于实现数据仓库，能节约存储空间并提升性能
空间索引
表级锁
延迟更新索引
不支持事务、外键和行级锁
崩溃后无法安全恢复数据
适用场景：只读数据、较小的表、能够容忍崩溃后的修改操作和数据丢失
ARCHIVE：
仅支持INSERT和SELECT，支持很好压缩功能；
适用于存储日志信息，或其它按时间序列实现的数据采集类的应用；
不支持事务，不能很好的支持索引；
CSV：
将数据存储为CSV格式；不支持索引；仅适用于数据交换场景；
BLACKHOLE：
没有存储机制，任何发往此引擎的数据都会丢弃；其会记录二进制日志，因此，常用于多级复制架构中作中转服务器；
MEMORY：
保存数据在内存中，内存表；常用于保存中间数据，如周期性的聚合数据等；也用于实现临时表
支持hash索引，使用表级锁，不支持BLOB和TEXT数据类型
MRG_MYISAM：是MYISAM的一个变种，能够将多个MyISAM表合并成一个虚表；
NDB：是MySQL CLUSTER中专用的存储引擎
第三方的存储引擎：
OLTP类：
XtraDB: 增强的InnoDB，由Percona提供；
编译安装时，下载XtraDB的源码替换MySQL存储引擎中的InnoDB的源码
PBXT: MariaDB自带此存储引擎
支持引擎级别的复制、外键约束，对SSD磁盘提供适当支持；
支持事务、MVCC
TokuDB: 使用Fractal Trees索引，适用存储大数据，拥有很压缩比；已经被引入MariaDB；
列式存储引擎：
Infobright: 目前较有名的列式引擎，适用于海量数据存储场景，如PB级别，专为数据分析和数据仓库设计；
InfiniDB
MonetDB
LucidDB
开源社区存储引擎：
Aria：前身为Maria，可理解为增强版的MyISAM(支持崩溃后安全恢复，支持数据缓存)
Groona：全文索引引擎，Mroonga是基于Groona的二次开发版
OQGraph: 由Open Query研发，支持图结构的存储引擎
SphinxSE: 为Sphinx全文搜索服务器提供了SQL接口
Spider: 能数据切分成不同分片，比较高效透明地实现了分片(shared)，并支持在分片上支持并行查询；
如何选择？
是否需要事务
备份的类型的支持
崩溃后的恢复
特有的特性
转载于:https://blog.51cto.com/chrome/1392722
1354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
