【导语】“zeezhang”通过精心收集，向本站投稿了7篇InnoDB 中文参考手册 10 multiversioning 的实现数据库教程，今天小编在这给大家整理后的InnoDB 中文参考手册 10 multiversioning 的实现数据库教程，我们一起来看看吧！
- 目录
篇1：InnoDB 中文参考手册 10 multiversioning 的实现数据库教程
参考|参考手册|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 10 multiversioning 的实现因为 InnoDB 是一个 multiversioned 数据库系统，它必须在表空间内保存记录行的先期版本信息，这个信息被存储在被称为回滚段(rollback segment)的数据结构中，这与 Oracle 相似。
InnoDB 在内部处理时在数据库中为每行记录添加两个字段。一个6-byte 字段描述最后一个插入或更新该行的事务的标识符。同样被删除记录在内部处理上为更新该行的某一标志位， 该标志位用于记录它已被删除。每行记录同样包含着一个名为滚指针(roll pointer)的 7-byte 字段。这个指针指向一个在回滚段中存储的撤消日志记录(undo log record)。如果该行被更新过，那么撤消日志记录中包含必要的信息来重建它被更新前的内容。
InnoDB 需要通过一个事务的回滚来实现使用回滚段中的信息执行撤销操作，
它也用于为一个 consistent read 来重建一个记录行的早期版本。
在回滚段中的撤销日志被分为插入和更新撤销日志。插入撤销日志(Insert undo logs)仅仅只在事务回滚时需要，它可以在事务一提交就被抛弃。更新撤销日志(Update undo logs)同样也在 consistent reads 中使用，它们将在当前没有事务时被抛弃。InnoDB 指派了一个数据快照，而 consistent read 需要更新撤销日志中的信息来重建一个数据库行的早期版本。
必须记录有规律地提交你的事务，同样的这些事务只发出了consistent reads。否则 InnoDB 不能够从更新撤销日志中抛弃数据，则回滚段可能会增加地太大而填满了整个表空间。
回滚段中的撤销日志记录的物理尺寸通常比它们相对应的插入或更新的记录要小些。 你可以通过学习这些信息估算出回滚段所需的空间。
在 multiversioning 的设计中，以一条 SQL 语句删除一个记录行时，该记录并不会立即从数据库中移除。只在当 InnoDB 抛弃删除的更新撤销日志记录时，它才会从数据库中物理地移除相应的记录行以及它的索引。 这个移除操作被称为 purge，它是非常快的，通常以与执行删除的 SQL 语句相同的时间顺序执行。
篇2：InnoDB 中文参考手册 InnoDB Tables 概述数据库教程
参考|参考手册|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 1 InnoDB Tables 概述InnoDB 给 MySQL 提供了具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表，InnoDB 提供了行锁(locking on row level)，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)。这些特性均提高了多用户并发操作的性能表现。在InnoDB表中不需要扩大锁定(lock escalation)，因为 InnoDB 的列锁定(row level locks)适宜非常小的空间。InnoDB 是 MySQL 上第一个提供外键约束(FOREIGN KEY constraints)的表引擎。
InnoDB 的设计目标是处理大容量数据库系统，它的 CPU 利用率是其它基于磁盘的关系数据库引擎所不能比的。
在技术上，InnoDB 是一套放在 MySQL 后台的完整数据库系统，InnoDB 在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。 InnoDB 把数据和索引存放在表空间里，可能包含多个文件，这与其它的不一样，举例来说，在 MyISAM 中，表被存放在单独的文件中。InnoDB 表的大小只受限于操作系统的文件大小，一般为 2 GB。
在www.innodb.com/上可以找到 InnoDB 最新的信息。InnoDB 手册的最新版本总是被放置在那里，并且在那里可以得到 InnoDB 的商业许可(order commercial licenses)以及支持。
InnoDB 现在(十月)在一些大的需高性能的数据库站点上被使用。著名的 Internet 新闻站点 Slashdot.org 就是使用的 InnoDB，
Mytrix, Inc. 在 InnoDB 表上存储了超过 1 TB 的数据，而且另外的一个站点在 InnoDB 表上处理着平均每秒 800 次的插入/更新的负载。
在 MySQL 的源代码中，从 3.23.34a 开始包含 InnoDB 表引擎，并在 MySQL -Max 的二进制版本中激活。
为了使用 InnoDB 表引擎，必须在‘my.cnf’或‘my.ini’文件中详细指定 InnoDB 的启动配置。最小的修改方法就是在 [mysqld] 区中加入下面一行：
innodb_data_file_path=ibdata:30M
但是为了得到最好的性能推荐详细指定配置选项，查看 2 InnoDB Startup Options。
InnoDB 以 GNU GPL 版本 2 的许可发布(1991年六月)。
1.1 MySQL/InnoDB 发布版本间的差别
MySQL-Max-3.23: 这是一个稳定版本，被推荐为产品使用。 MySQL-4.0: 这是一个开发版本，与 MySQL 3.23 相比它包含了一些新特性，比如多表删除(multi-table delete)、查询结果缓冲(cached query results)和 SSL 通信。4.0 版与 3.23 版中的 InnoDB 表引擎是一致的。4.0.1 的稳定性可被归类为 beta。 MySQL-4.0 embedded server library: You can link this into your application. The benefits are easier deployment for your application, better performance, and easier use. The stability of the embedded library is classified as alpha, but it should be gamma within a few months.
篇3：InnoDB 中文参考手册 6 备份和恢复 InnoDB 数据库数据库教程
备份|参考|参考手册|恢复|数据|数据库|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 6 备份和恢复 InnoDB 数据库安全的数据库管理就是使用正规的数据备份，
InnoDB Hot Backup 是一个在线备份工具，你可以在 InnoDB 数据库运行时使用它来实现在线备份。InnoDB Hot Backup 不需要你关闭你的服务器也不需要加任何锁或影响其它普通的数据操作。InnoDB Hot Backup 是一个非免费的附加工具，它的费用为每 MySQL 服务器每年 400 欧元。浏览网页 InnoDB Hot Backup homepage 可获得更多的信息以及程序屏幕截图。
如果你可以关闭你的 MySQL 服务，那么可以通过下面几个步骤进行数据库的“二进制”备份：
关闭 MySQL 数据库服务，并确定在关闭时没有发生任何错误 将你的所有数据文件复制到一个安全的地方 将所有的 InnoDB 日志文件复制到一个安全的地方 将 my.cnf 配置文件复制到一个安全的地方 将所有的 InnoDB 表 .frm 文件复制到一个安全的地方
在需要高性能的数据库服务站点上，可以通过 MySQL 的复制特性来保持数据库的一个副本，MySQL 的复制特性同样适用于 InnoDB 表类型。
除了上面描述的二进制备份方式之外，最好定期地使用 mysqldump 转储数据表。原因是二进制文件可能会在你未注意时而被破坏，而表转储(dump)文件是以文本文件方式保存的，它与二进制文件相比更简单、有更好的的可读性。因为转储文件更简单所以更容易发现表损坏， 重要数据损环的可能性很小。
一个好的主意就是在对数据库做二进制备份的同时也做一个转储(dump)备份。为了得到一致的数据快照，必须关闭所有客户端的连接。然后就可以进行二进制备份，这样你就有了数据一致的两种格式的备份。
如了实现通过上面所述的二进制备份方法将 InnoDB 数据库恢复到当前状态，必须打开 MySQL 的二进制日志(binlogging)开关。这样你就可以二进制日志 与备份数据配合实现分时间点的恢复：
mysqlbinlog yourhostname-bin.123 | mysql
为了恢复一个崩溃了的 MySQL 服务进程，你所能做的唯一一件事就是重新启动。InnoDB 将自动地检查日志并完成数据库的前滚(roll-forward)到当前状态。同时，InnoDB 将自动回滚崩溃前未提交的事务。在恢复过程中，mysqld 将显示如下所示的提示：
heikki@donna:~/mysql-3.23.48/sql>mysqld 020204 23:08:31 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 177573790 InnoDB: Doing recovery: scanned up to log sequence number 0 177638912 InnoDB: Doing recovery: scanned up to log sequence number 0 177704448 InnoDB: Doing recovery: scanned up to log sequence number 0 177769984 InnoDB: Doing recovery: scanned up to log sequence number 0 177835520 InnoDB: Doing recovery: scanned up to log sequence number 0 177901056 InnoDB: Doing recovery: scanned up to log sequence number 0 177966592 InnoDB: Doing recovery: scanned up to log sequence number 0 178032128 InnoDB: Doing recovery: scanned up to log sequence number 0 178097664 InnoDB: Doing recovery: scanned up to log sequence number 0 178163200 InnoDB: Doing recovery: scanned up to log sequence number 0 178228736 InnoDB: After this prints a line for every 10th scan sweep: InnoDB: Doing recovery: scanned up to log sequence number 0 178884096 ... InnoDB: Doing recovery: scanned up to log sequence number 0 193302016 InnoDB: Doing recovery: scanned up to log sequence number 0 193957376 InnoDB: Doing recovery: scanned up to log sequence number 0 194612736 020204 23:08:40 InnoDB: Starting an apply batch of log records to the database. .. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 0 195268096 InnoDB: Doing recovery: scanned up to log sequence number 0 195923456 ... InnoDB: Doing recovery: scanned up to log sequence number 0 203132416 InnoDB: Doing recovery: scanned up to log sequence number 0 203787776 InnoDB: Doing recovery: scanned up to log sequence number 0 204443136 InnoDB: 5 uncommitted transaction(s) which must be rolled back InnoDB: Trx id counter is 0 129792 InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx with id 0 129400 InnoDB: Rolling back of trx id 0 129400 completed InnoDB: Rolling back trx with id 0 129217 InnoDB: Rolling back of trx id 0 129217 completed InnoDB: Rolling back trx with id 0 129098 InnoDB: Rolling back of trx id 0 129098 completed InnoDB: Rolling back trx with id 0 128743 InnoDB: Rolling back of trx id 0 128743 completed InnoDB: Rolling back trx with id 0 127939 InnoDB: Rolling back of trx id 0 127939 completed InnoDB: Rollback of uncommitted transactions completed 020204 23:08:51 InnoDB: Starting an apply batch of log records to the database. .. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file offset 0 40418561, file name ./donna-bin.001 020204 23:08:53 InnoDB: Flushing modified pages from the buffer pool... 020204 23:09:03 InnoDB: Started mysqld: ready for connections
如果数据库遭到损坏或磁盘失败，则不得不从一个备份文件恢复，
在损坏的情况下，首先可以恢复一个未损坏的备份文件。然后依照 MySQL 手册提示从一般的日志文件中恢复数据。
在某些数据库损坏的情况下，可能通过转储(dump)、撤销(drop)和重新建立一个或多个损坏的表就足够了。可怜通过 CHECK TABLE SQL 命令检查一个受损的表，虽然 CHECK TABLE 并不能发现所有的损坏类型。你可能使用 innodb_tablespace_monitor 来检查数据文件时的文件空间管理的完整性。
在某些情况下，数据库页面显示损坏，而实际上是由于操作系统的文件高速缓冲损坏，而磁盘上的数据文件还是好的。 这时最好先重起你的系统。这可能解决数据库页面错误。
6.1 强制(Forcing)恢复
如果出现数据库页面损坏，可以通过 SELECT INTO OUTFILE 从数据库中转储出表数据，通常大部分的数据并未受损坏。 但是这些损坏可能引起 SELECT * FROM table 或 InnoDB 后台操作崩溃或中断(assert)，甚至是 InnoDB 的前滚(roll-forward)恢复崩溃。从 InnoDB version 3.23.44 开始，在 my.cnf 中有个设置选项可以强制 InnoDB 启动，以及防止后台操作的运行，因而你可以转储数据。例如，你可以 my.cnf 在中加入如下设置：
set-variable = innodb_force_recovery = 4
innodb_force_recovery 代替选择将在下面列出。 这个参数不能用于数据库的其它方面！当设置值大于 0 时，作为安全尺度，InnoDB 禁止用户使用 INSERT, UPDATE, 或 DELETE 。
从 3.23.53 和 4.0.4 开始，即使强制恢复被使用你也可以使用 DROP 或 CREATE 一个表。 如果你确定表如引起回滚崩溃，你可以移除(drop)它。你也可以通过这个停止一个因导入大量数据或 ALTER TABLE 而引起的失控(runaway)回滚。你可以杀死 mysqld 进程，并使用 my.cnf 设置项 innodb_force_recovery=3 不使用回滚。然后就可以 DROP 那个引起失控(runaway)回滚的表。
下面较大的数意味着包含所有较低数所对就的安全防范。为了能够转储表设置至少为 4 ，这是相对安全的，仅仅只有一些损坏的页面数据掉失。Option 6 is more dramatic, because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures. 1 (SRV_FORCE_IGNORE_CORRUPT) 即使发现一个错误也启动服务；试着使用 SELECT * FROM table 跳过损坏的索引记录和页面，这将帮助转储表。 2 (SRV_FORCE_NO_BACKGROUND) prevent the main thread from running: 如果在清理过程中将发生崩溃，这将预防它。 3 (SRV_FORCE_NO_TRX_UNDO) 恢复时不运行事务回滚。 4 (SRV_FORCE_NO_IBUF_MERGE) 防止插入缓冲区的归并操作：如果他们将引起崩溃，最好不要操作他们；不要考虑表统计(table statistics)。 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) 当启动数据库时不撤销日志(undo logs)：InnoDB 将未完成的事务已提交。 6 (SRV_FORCE_NO_LOG_REDO) do not do the log roll-forward in connection with recovery.
6.2 检查点(Checkpoints)
InnoDB 通过调用一个模糊的检查点来实现检查点机制。InnoDB 以很小的批量从缓冲池中刷新修改了的数据库页面。这就不需要在一个批量中刷新整个缓冲池，因这个实话上将可能停止用户 SQL 语句运行进程一段时间。
In crash recovery InnoDB 在崩溃修复时会检查记录在日志文件中的检查点标签。它知道，在标签前所有对数据库的修改已被记录到数据库的磁盘镜像中。然后 InnoDB 扫描日志文件中检查点后面的日志并将修改记入数据库。
InnoDB 以一个环形方式记录日志文件。所有使缓冲池中的数据库页面与磁盘镜像不相同已提交了的修改必须记录在日志文件中，以防 InnoDB 需要恢复。 这就意味着 InnoDB 以环形方式重新启用一个日志文件，它必须确定将被重新使用的日志文件中的操作日志结果已被磁盘镜像文件包含。用另一句话来说就是，InnoDB 必须时常地建立检查点并将修改了的数据库页面更新到磁盘中。
上面所述要以解释为什么将日志文件设置和大一点可以减少因建立检查点所用的磁盘 I/O。 这就可以理解设置日志文件的总尺寸与缓冲池一样大或更大。大的日志文件的缺点就是当进行崩溃修复时将需要很长的时间，因为有更多的操作日志需要更新到数据库中。
篇4：InnoDB 中文参考手册 13 出错处理数据库教程
参考|参考手册|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 13 出错处理InnoDB 的出错处理不总是与 ANSI SQL 指定的一致，依照 ANSI 标准，在一个 SQL 语句中的任何错误都将引起这条语句的回滚。InnoDB 有时只回滚语句的一部分，有时则是整个事务。 下面的列表详细说明了 InnoDB 的出错处理。
如果用完了表空间内的文件空间，将会得到 MySQL 的 'Table is full' 错误，InnoDB 将回滚这条 SQL 语句。 事务的死锁或锁定等待的超时将会使 InnoDB 回滚整个事务。 一个重复键(duplicate key)只会回滚插入的细节行，甚至在如同 INSERT INTO ... SELECT ...的一个语句中。这或许会发生改变，所以如果在语句中没有指定 IGNORE 选项这个语句将产生回滚。 'row too long' 的错误将回滚整个 SQL 语句。 其它的错误主要由 MySQL 的代码层发现，它们将回滚相应的 SQL 语句。
13.1 MySQL 返回的某些错误代码
1005 ER_CANT_CREATE_TABLE 不能建立表。如果错误信息串引用 errno 150，那么表创建失败是由于外键约束没能正确的形成。 1016 ER_CANT_OPEN_FILE 不能够通过 .frm 文件在 InnoDB 数据文件中找到 InnoDB 表。查看下面的“发现并修复数据字典错误的操作”章节。 1114 ER_RECORD_FILE_FULL InnoDB 用光了表空间内的剩余空间。你必须增加一个新的数据文件。 1205 ER_LOCK_WAIT_TIMEOUT 锁等待超时期满。事务被回滚。 1213 ER_LOCK_DEADLOCK 事务死锁。需要重新运行事务。 1216 ER_NO_REFERENCED_ROW 当试图增加一个新行时，但是没有父记录存在，外键约束失败。必须先添加父记录。 1217 ER_ROW_IS_REFERENCED 删除一个有子记录存在的父行，外键约束失败。必须先删除子记录。
13.2 某些操作系统的错误编码
在 Unix 系统中，使用 perror 程序来显示操作系统错误编码的含义，它包含在 MySQL 的分发中。
下面的列表显示常见的 Linux 系统错误代码。 1 EPERM
Operation not permitted
操作不许可 2 ENOENT
No such file or directory
无此文件或目录 3 ESRCH
No such process
无此过程 4 EINTR
Interrupted system call
系统调用被禁止 5 EIO
I/O error
I/O 错误 6 ENXIO
No such device or address
无此器件或地址 7 E2BIG
Arg list too long
Arg 列表太长 8 ENOEXEC
Exec format error
Exec 格式错误 9 EBADF
Bad file number
文件数目错误
10 ECHILD
No child processes
无子过程
11 EAGAIN
Try again
再试一遍
12 ENOMEM
Out of memory
内存溢出
13 EACCES
Permission denied
许可拒绝
14 EFAULT
Bad address
错误的地址
15 ENOTBLK
Block device required
需要块设备
16 EBUSY
Device or resource busy
设备或资源忙
17 EEXIST
File exists
文件存在
18 EXDEV
Cross-device link
跨器链接
19 ENODEV
No such device
无此设备
20 ENOTDIR
Not a directory
不是一个目录
21 EISDIR
Is a directory
是一个目录
22 EINVAL
Invalid argument
无效的函数自变量
23 ENFILE
File table overflow
文件表溢出
24 EMFILE
Too many open files
打开的文件太多
25 ENOTTY
Inappropriate ioctl for device
26 ETXTBSY
Text file busy
文本文件忙
27 EFBIG
File too large
文件太大
28 ENOSPC
No space left on device
磁盘空间不足
29 ESPIPE
Illegal seek
不合法的寻找
30 EROFS
Read-only file system
只读文件系统
31 EMLINK
Too many links
太多的链接
下面的列表显示常见的 Windows 系统错误代码。 1 ERROR_INVALID_FUNCTION
Incorrect function
函数错误
2 ERROR_FILE_NOT_FOUND
The system cannot find the file specified
系统找不到指定文件
3 ERROR_PATH_NOT_FOUND
The system cannot find the path specified
系统找不到指定路径
4 ERROR_TOO_MANY_OPEN_FILES
The system cannot open the file
系统不能打开文件
5 ERROR_ACCESS_DENIED
Access is denied
访问被拒绝
6 ERROR_INVALID_HANDLE
The handle is invalid
句柄无效
7 ERROR_ARENA_TRASHED
The storage control blocks were destroyed
存储控制块被损坏
8 ERROR_NOT_ENOUGH_MEMORY
Not enough storage is available to process this command
没有足够的存储空间执行这个指令
9 ERROR_INVALID_BLOCK
The storage control block address is invalid
存储控制块地址无效
10 ERROR_BAD_ENVIRONMENT
The environment is incorrect.
环境错误
11 ERROR_BAD_FORMAT
An attempt was made to load a program with an incorrect format.
以错误的格式尝试装入一个程序
12 ERROR_INVALID_ACCESS
The access code is invalid.
存取码无效
13 ERROR_INVALID_DATA
The data is invalid.
数据无效
14 ERROR_OUTOFMEMORY
Not enough storage is available to complete this operation.
没有足够的存储空间来完成这个操作
15 ERROR_INVALID_DRIVE
The system cannot find the drive specified.
系统无法找到指定的驱动器
16 ERROR_CURRENT_DIRECTORY
The directory cannot be removed.
目录无法被移除
17 ERROR_NOT_SAME_DEVICE
The system cannot move the file to a different disk drive.
系统无法将文件移到不同的磁盘驱动器上
18 ERROR_NO_MORE_FILES
There are no more files.
没有更多的文件
19 ERROR_WRITE_PROTECT
The media is write protected.
媒体写保护 20 ERROR_BAD_UNIT
The system cannot find the device specified.
系统无法找到指定的设备
21 ERROR_NOT_READY
The device is not ready.
设备未准备好
22 ERROR_BAD_COMMAND
The device does not recognize the command.
设备不支持这个指令
23 ERROR_CRC
Data error (cyclic redundancy check).
数据出错（循环冗余检验）
24 ERROR_BAD_LENGTH
The program issued a command but the command length is incorrect.
程序发出指令，但指令长度出错
25 ERROR_SEEK
The drive cannot locate a specific area or track on the disk.
驱动器无法在磁盘上定位指定的区域或磁道
26 ERROR_NOT_DOS_DISK
The specified disk or diskette cannot be accessed.
指定的磁盘或磁碟无法访问
27 ERROR_SECTOR_NOT_FOUND
The drive cannot find the sector requested.
驱动器无法找到需要的扇区
28 ERROR_OUT_OF_PAPER
The printer is out of paper.
打印机缺纸
29 ERROR_WRITE_FAULT
The system cannot write to the specified device.
系统不能够向指定的设备中写入
30 ERROR_READ_FAULT
The system cannot read from the specified device.
系统无法从指定设备中读入
31 ERROR_GEN_FAILURE
A device attached to the system is not functioning.
系统附着的设备无法运作
32 ERROR_SHARING_VIOLATION
The process cannot access the file because it is being used by another process.
进程无法访问该文件因为文件已被其它进程使用
33 ERROR_LOCK_VIOLATION
The process cannot access the file because another process has locked a portion of the file.
进程无法访问该文件因为文件已被其它进程锁定部分
34 ERROR_WRONG_DISK
The wrong diskette is in the drive. Insert %2 (Volume Serial Number: %3) into drive %1.
驱动器中磁盘错误，
插入 %2 (盘卷序列号：%3)到驱动器 %1中
36 ERROR_SHARING_BUFFER_EXCEEDED
Too many files opened for sharing.
太多的文件为共享打开
38 ERROR_HANDLE_EOF
Reached the end of the file.
达到文件结束
39 ERROR_HANDLE_DISK_FULL
The disk is full.
磁盘已满
112 ERROR_DISK_FULL
The disk is full.
磁盘已满
123 ERROR_INVALID_NAME
The filename, directory name, or volume label syntax is incorrect.
文件名，目录名或卷标语法出错
篇5：InnoDB 中文参考手册 9 性能调整技巧数据库教程
参考|参考手册|技巧|性能|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 9 性能调整技巧(Performance tuning tips)1. 如果 Unix top 或 Windows 任务管理器(Task Manager) 显示服务的 CPU 占用率小于 70%，(shows that the CPU usage percentage with your workload is less than 70 %,）你的系统瓶颈可能在磁盘读写上，或许你提交了大量的事务，或者是缓冲池(buffer pool)太小了。将缓冲池设大点会有所帮助，但一定要注意不能大于物理内存的 80%。
2. 在一个事务中包含几个修改。如果事务对数据库进行了修改，那么在这个事务提交时 InnoDB 必须刷新日志到磁盘上。因为硬盘的旋转速度通常至多为 167 转/秒，那么只要磁盘不欺骗操作系统，提交的事务数目限止也同样为 167 次/秒・用户。
3. 如果掉失最近的几个事务无所谓的话，可以在 my.cnf 文件中将参数 innodb_flush_log_at_trx_commit 设置为 0。InnoDB 无论如何总是尝试一秒刷新(flush)一次日志，尽管刷新并不能得到保证。
4. 将日志文件(log files)设大一点，使日志文件的总和正好与缓冲池(buffer pool)一样大。当 InnoDB 用光日志文件的空间时，它不得不在一个时间点上将缓冲池内修改过的内容写到磁盘上。 小的日志文件可能引起不必要的磁盘写操作。但是大的日志文件的缺点就是在数据恢复时将占用较长的时间。
5. 同样 log buffer 尽量设大点，比如说 8 MB。
6. 如果要存储变长的字符串或字段可能会包含大量的 NULLs，请使用 VARCHAR 型字段代替 CHAR 。一个 CHAR(n) 字段总是使用 n bytes 来存储数据，即使这个字符串很短或是一个 NULL 值。较小的表更加适合缓冲池同时能够减少磁盘 I/O 。
7. (适合从 3.23.41 以上版本) 在某些版本的 Linux 和 Unixes 中，使用 Unix fsync 或其它类似的方法将文件刷新到磁盘是异常地慢的。InnoDB 默认的方法就是 fsync 。如果你对数据库系统的磁盘写性能不能感到满意，你可以尝试在 my.cnf 中将 innodb_flush_method 设置为 O_DSYNC，尽管 O_DSYNC 选项在多数的系统上看起来比较慢。
8. 在向 InnoDB 导入数据时，请确认 MySQL 没有打开 autocommit=1 。否则每个插入语句都要将 log 刷新到磁盘。在你的 SQL 导入文件的第一行加入
set autocommit=0;
并在最后一行加入
commit;
如果使用 mysqldump 选项 --opt，你将会得到一个快速导入 InnoDB 表的转储(dump)文件，甚至可以不再使用上面所提的 set autocommit=0; ... commit; 。
9. 小心 insert 集全的大回滚(roolback)：在插入时 InnoDB 使用插入缓冲来减少磁盘 I/O，但在相应的回滚中却没有使用这样的机制。一个 disk-bound rollback 可能会花费相应插入时间的 30 倍。如果发生一个失控的回滚，你可以查看第 6.1 章节的技巧来停止它。
10. 同样也要小心一个大的 disk-bound 的操作。使用 DROP TABLE 或 TRUNCATE (从 MySQL-4.0 以上) 来清空一个表，而不要使用 DELETE FROM yourtable。
11. 如果需要插入大量记录行可以使用多行(multi-line)的 INSERT 来减少客户端与服务器端的通信开销：
INSERT INTO yourtable VALUES (1, 2), (5, 5);
这个技巧对插入任何表均有效，而不仅仅是 InnoDB。
12. 如果在辅键上有 UNIQUE 约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将唯一键检查(uniqueness check)关闭来提高数据导入速度：
SET UNIQUE_CHECKS=0;
一个大的表导入这将减少大量的磁盘 I/O，因为这时 InnoDB 可能使用自身的插入缓冲来分批地记录辅助索引。
13. 如果在表中有一个子 FOREIGN KEY 约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将外键检查(foreign key check)关闭来提高数据导入速度：
SET FOREIGN_KEY_CHECKS=0;
对一个大的表导入这将减少大量的磁盘 I/O。
9.1 InnoDB 监视器(Monitors)
从版本 3.23.42 开始，InnoDB 中就包含了 InnoDB Monitors，它可以显示出 InnoDB 的内部状态。从版本 3.23.52 和 4.0.3 开始，你可以使用一个新的 SQL 命令
SHOW INNODB STATUS
来读取标准 InnoDB Monitor 给 SQL client 的输出信息。这些信息对性能调整有益。
另外一个使用 InnoDB Monitors 方法就是让它在服务程序 mysqld 的标准输出上持续地写出信息。当开关打开时，InnoDB Monitors 大约每 15 秒显示一次数据(注意：MySQL 的客户端并不会显示任何东西)。一个简单地使用它的方法就是以一个命令行方式执行 mysqld 。否则输出将会定向到 MySQL 服务错误日志(error log file)中 'yourhostname'.err (在 Windows 下为 mysql.err)，在 Windows 系统中必须在 MS-DOS 使用提示符下以 --console 选项运行 mysqld-max 来指令信息输出在命令提示符窗口上。
显示的信息包含下列信息： 每一个活动的事务(active transaction)保持的表和记录锁定 事务的锁等待 (lock waits of a transactions) 线程的信号量等待 (semaphore waits of threads) 文件 I/O 的等待请求 (pending file i/o requests) 缓冲池(buffer pool)的统计信息 InnoDB 主线程的 purge buffer 和 insert buffer 归并活动(merge activity)
通过下列的 SQL 命令，可以使标准的 InnoDB Monitor 记录到标准的 mysqld 的输出上：
CREATE TABLE innodb_monitor(a int) type = innodb;
通过它来停止：
DROP TABLE innodb_monitor;
CREATE TABLE 句法只不过是为了通过 MySQL SQL 语法分析而提供给 InnoDB 引擎命令的一种方式：那个被创建的表根本与 InnoDB Monitor 无任何关系。如果你在监视器运行着的状态下关闭数据库，并且你需要再次启动监视器， 那么你不得不在发出一个新的 CREATE TABLE 来启动监视器之前先移除(drop)这个表。
与之相类似的，你可以启动 innodb_lock_monitor ，它在某些方面与 innodb_monitor 一致，但是它会显示更多的锁定信息。一个单独的 innodb_tablespace_monitor 将显示在现有表空间内所建立的文件段列表以及可以分配数据结构的有效表空间。从 3.23.44 开始，提供了 innodb_table_monitor ，通过它可以获得 InnoDB 内部数据字典的信息。
3.23.52 中 InnoDB 输出的示例：
===================================== 020805 22:07:41 INNODB MONITOR UTPUT ===================================== Per second averages calculated from the last 3 seconds ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 194, signal count 193 --Thread 7176 has waited at ../include/btr0btr.ic line 28 for 0.00 seconds the s emaphore: X-lock on RW-latch at 44d980bc created in file buf0buf.c line 354 a writer (thread id 7176) has reserved it in mode wait exclusive number of readers 1, waiters flag 1 Last time read locked in file ../include/btr0btr.ic line 28 Last time write locked in file ../include/btr0btr.ic line 28 Mutex spin waits 0, rounds 0, OS waits 0 RW-shared spins 77, OS waits 33; RW-excl spins 188, OS waits 161 ------------ TRANSACTIONS ------------ Trx id counter 0 657853517 Purge done for trx's n:o < 0 657853429 undo n:o < 0 80 Total number of lock structs in row lock hash table 22 020805 22:07:36 LATEST DETECTED DEADLOCK: *** (1) TRANSACTION: TRANSACTION 0 657853503, ACTIVE 0 sec, OS thread id 15373 inserting LOCK WAIT 3 lock struct(s), heap size 336 MySQL thread id 6, query id 3741 localhost heikki update insert into ibtest11b (D, B, C) values (5, 'khdkkkk' ,'khdkkkk') *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 104865 n bits 208 table test/ibtest11b index PRI MARY trx id 0 657853503 lock_mode X waiting Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc supremum.;; *** (2) TRANSACTION: TRANSACTION 0 657853500, ACTIVE 0 sec, OS thread id 11275 setting auto-inc lock 19 lock struct(s), heap size 2672, undo log entries 5 MySQL thread id 2, query id 3750 localhost heikki update insert into ibtest11b (D, B, C) values (5, 'khD' ,'khD') *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 0 page no 104865 n bits 200 table test/ibtest11b index PRI MARY trx id 0 657853500 lock_mode X Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc supremum.;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: TABLE LOCK table test/ibtest11b trx id 0 657853500 lock_mode AUTO-INC waiting *** WE ROLL BACK TRANSACTION (2) LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0 657853516, ACTIVE 5 sec, OS thread id 15373 setting auto-inc lo ck LOCK WAIT 1 lock struct(s), heap size 336 MySQL thread id 6, query id 3895 localhost heikki update insert into ibtest11b (D, B, C) values (5, 'khdkkkk' ,'khdkkkk') ------- TRX HAS BEEN WAITING 5 SEC FOR THIS LOCK TO BE GRANTED: TABLE LOCK table test/ibtest11b trx id 0 657853516 lock_mode AUTO-INC waiting ------------------ ---TRANSACTION 0 657853514, ACTIVE 5 sec, OS thread id 11275 inserting LOCK WAIT 13 lock struct(s), heap size 2672, undo log entries 2 MySQL thread id 2, query id 3898 localhost heikki update insert into ibtest11d (D, B, C) values (5, 'khdkkkk' ,'khdkkkk') ------- TRX HAS BEEN WAITING 5 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 104879 n bits 384 table test/ibtest11d index B t rx id 0 657853514 lock_mode X gap type lock waiting Record lock, heap no 130 RECORD: info bits 32 0: len 9; hex 6b48646b6b6b6b6b6b; asc kHdkkkkkk;; 1: ------------------ ---TRANSACTION 0 657853512, ACTIVE 5 sec, OS thread id 14348 updating or deletin g 20 lock struct(s), heap size 2672, undo log entries 175 MySQL thread id 5, query id 3874 localhost heikki updating delete from ibtest11a where A = 215 -------- FILE I/O -------- I/O thread 0 state: waiting for i/o request I/O thread 1 state: waiting for i/o request I/O thread 2 state: waiting for i/o request I/O thread 3 state: waiting for i/o request Pending normal aio reads: 0, aio writes: 0, ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0 Pending flushes (fsync) log: 0; buffer pool: 0 272 OS file reads, 56 OS file writes, 29 OS fsyncs 0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s ------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- Ibuf for space 0: size 1, free list len 5, seg size 7, 0 inserts, 0 merged recs, 0 merges Hash table size 124633, used cells 1530, node heap has 4 buffer(s) 2895.70 hash searches/s, 126.62 non-hash searches/s --- LOG --- Log sequence number 19 3267291494 Log flushed up to 19 3267283711 Last checkpoint at 19 3266545677 0 pending log writes, 0 pending chkp writes 30 log i/o's done, 0.00 log i/o's/second ---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 82593970; in additional pool allocated 1406336 Buffer pool size 1920 Free buffers 1711 Database pages 205 Modified db pages 39 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages read 178, created 27, written 50 0.00 reads/s, 0.00 creates/s, 0.00 writes/s Buffer pool hit rate 1000 / 1000 -------------- ROW OPERATIONS -------------- 1 queries inside InnoDB, 0 queries in queue; main thread: purging Number of rows inserted 2008, updated 264, deleted 162, read 9 0.00 inserts/s, 0.00 updates/s, 14.66 deletes/s, 0.00 reads/s ---------------------------- END OF INNODB MONITOR UTPUT ============================
输出信息的某些注意点： 如果 TRANSACTIONS 部分报告锁定等待(lock waits)，那么你的应用程序可能有锁争用(lock contention)，
输出信息可以帮助跟踪事务死锁的原因。 SEMAPHORES 部分报告线程等待信号量以及统计出线程需要旋转(spin)或等待(wait)一个互斥(mutex)或 rw-lock 信号量的次数。一个较大的线程等待信号量的次数可能是由于磁盘 I/O 引起，或 InnoDB 内部的争用问题(contention problems)。争用(Contention)可能是由于比较繁重的并发性查询，或操作系统的线程调度的问题。 在这种情形下，可将 innodb_thread_concurrency 设置地小于默认的 8 。 FILE I/O 部分列出了文件 I/O 的等待请求。过大的值就意味着磁盘 I/O 瓶颈。 BUFFER POOL AND MEMORY 部分给出了页面读写的统计。通过这些值可以计算出你的查询通常所需的数据文件 I/O 量。
篇6：InnoDB 中文参考手册 14 InnoDB 表的限制数据库教程
参考|参考手册|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 14 InnoDB 表的限制 在 < 3.23.50 版本的 InnoDB 中，不可以使用 ALTER TABLE 或 CREATE INDEX 来修改一个已经有了外键约束或参考了外键约束的表，InnoDB 中文参考手册 14 InnoDB 表的限制数据库教程
。使用 DROP TABLE 和 CREATE TABLE 来代替它。 不可以将 MySQL 系统表(如 'user' 或 'host' )转换成 InnoDB 类型。系统表必须总是为 MyISAM 类型的。 InnoDB 表不支持全文搜索(fulltext search)。 MySQL 以自动提交模式(autocommit mode)执行复制(replication)。因此slave中的 consistent reads 可能看起来你部分处理过的事务，所以在 slave 中这种读取(read)并不是真正的 consistent 。这个限制在 3.23.52 不再存在。 InnoDB 在内部不保存一个表记录总数，这是由于 multiversioning 的原因使它实现有点复杂。为了响应一个查询 SELECT COUNT(*) FROM T ，InnoDB 不得不扫描表的一个索引，如果表没有完全在缓冲池中这将花费一些时间。 为了得到更快的计数你不得不使用自己创建一个计数表，让你的应用程序在插入与删除时自己更新它。 消除因锁等待引起的瓶颈的一个方法就是创建整体的计数器集。应用程序可以随机地每次选择一个。 为了得到计数，仅仅只要对计数器求和：SELECT SUM(counter_column) FROM your_counter_table。 表中有 auto-increment 列的必须为它定义一个键，这个键必须仅仅包含这个 auto-increment 列。InnoDB 不支持在一个 CREATE TABLE 语句中使用 AUTO_INCREMENT=... 。这个子句是为了给一个 auto-increment 列设置第一个值(默认的第一个值为 1)。工作区(Workaround)：向自增列中插入一个指定的值做为第一个值。从此，InnoDB 将从这值开始增加。 SHOW TABLE STATUS 不能给出 InnoDB 表的精密统计数据，除了由表保留的物理大小之外。记录行数只能通过一个优化的 SQL 来获得大致的估计。 在 MySQL 中复制(replication)中，load table from master 仍然不能在 InnoDB 表中工作， 在主(master)服务器中开设一个工作区(workaround )用于将表转换成 MyISAM 型，然后再进行 load，之后再在 master 中将表改回 InnoDB 类型。 如果以一个列的前面部分建立索引：CREATE TABLE T (A CHAR(20), B INT, INDEX T_IND (A(5))) TYPE = InnoDB;
InnoDB 将内在的在整个列上建立一个索引，而不是仅以设定的首部分。 InnoDB 表不支持 INSERT DELAYED 。 MySQL 的 LOCK TABLES 操作无法知道一个 SQL 语句已完成对 InnoDB 的行锁定：这就意味着即使已有其它用户的事务在同一张表上设置了行锁，你仍然会锁定该表。 所以你在这张表上的操作与其它用户的锁定冲突则不得不等待。同样死锁也是可能的。无论如何， 这能事务完整性(transaction integrity)并不危险，因为 InnoDB 设置的行级锁定通常会照顾完整性(integrity)的。同样，一个表级锁定可以防止其它事务在表上获得更多的行级锁定(锁定模式不一致)。 在 BLOB 或 TEXT 字段上无法设置索引。 一张表不可以有超过 1000 个字段。 DELETE FROM TABLE 除了删除所有记录行之外不再重建表，一个接一个地删除，这并不那么快。在将来的 MySQL 版本中可以使用 TRUNCATE ，这是相当快的。 在 <= 3.23.43 的 InnoDB 中，在对 InnoDB 表调用 DROP DATABASE 之前，必须调用 DROP TABLE 来移除(drop) 个体的 InnoDB 表。这个限制在 >= 3.23.44 的版本中不再存在。 InnoDB 默认的数据库页面大小为 16 kB。通过重新编译源代码可以设置为 8 kB 到 64 kB。你必须在 univ.i 中更新 UNIV_PAGE_SIZE 和 UNIV_PAGE_SIZE_SHIFT 。在版本 <= 3.23.39a 的 InnoDB中，最大记录行长度为比数据库页面长度的一半稍小点。从源释放版本 3.23.39b (但是在 MySQL -Max 3.23.40 二进制释放版本中仍然没有)开始， BLOB 和 TEXT 字段允许 < 4 GB，整个行长度同样 < 4 GB。InnoDB 不在分开的页面中存储尺寸 <= 128 bytes 的字段。在 InnoDB 通过将长字段存储在分开的页面上修改记录后，剩余的记录行长度必须小于数据库页面的一半。最大键长为 500 bytes。 日志文件的总尺寸必须 < 4 GB。 最大表空间尺寸为数据库页面的 4 十亿(billion)倍。这同样也是一个表的最大尺寸。最小表空间为 10 MB。
篇7：InnoDB 中文参考手册 11 表和索引结构数据库教程
参考|参考手册|索引|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 11 表和索引结构MySQL 在数据库目录下的 .frm 文件中存储它的数据字典信息，但是每个 InnoDB 类型表也同样在 InnoDB 表空间内的内部的数据字典中存在它自己的进入点。当 MySQL 移除(drop) 一个表或一个数据库时，它将同时删除 .frm 文件，以及在 InnoDB 的数据字典中相对应的进入点。这就是为什么不能通过简单的删除 .frm 文件为移除数据库中的 InnoDB 类型表的原因，以及为什么在 MySQL 版本 <= 3.23.43 的版本中，DROP DATABASE 不能用于 InnoDB 表的原因。
每一个 InnoDB 表都有一个被称为聚簇索引的特殊索引用于保存记录行信息。如果一个表定义一个 PRIMARY KEY ，那么主键的索引就是聚簇索引。
如果表没有定义一个 PRIMARY KEY ，MySQL 将选出第一个 NOT NULL 字段的 UNIQUE 键做为主键，InnoDB 也将用这个键的索引做为聚簇索引。如果表中没有这样的键，InnoDB 将在内部产生一个聚簇索引，它是由按 InnoDB 分配给它们的 row id 顺序排序的记录行组成。这个 row id 是一个单调地增加并插入新行的 6-byte 字段。因而由 row id 排序的记录顺序也就是插入时的物理顺序。
通过聚簇索引访问一个记录行是非常快的，因为记录行数据与引导我们查找到它的索引在同一个页面上。 在大多数的数据库系统中记录行数据与索引记录通常并不是放在同一个页面上的。如果一个表太大了，那么聚簇索引体系通常比传统的方式更能减少磁盘 I/O 。
在非-聚簇索引(non-clustered indexes)中的记录 (我们通常称它为辅助索引secondary indexes)，在 InnoDB 中会为这行包含主键值。InnoDB 将使用这个主键值来在聚簇索引中查找这行。注意如果主键太长，那么辅助索引将会占用更多的空间。
InnoDB 在比较不同长度的 CHAR 和 VARCHAR 时，较短字串的多余长度将被空格(spaces)填充。
11.1 索引的物理结构
All indexes in InnoDB 中所有的索引是索引记录存放在树的叶页面(leaf pages)上的 B-trees。一个索引页面的大小默认为 16 kB。当新的记录 入时，InnoDB 将试图为将来的插入与更新索引记录保留页面的 1 / 16 空余。
如果索引记录以一个连续的 (升序或降序) 入，那么索引页面的将会被使用约 15/16 。如果以一个随机的顺序插入，那么页面大约使用了 1/2 - 15/16 。如果一个索引页面被撤销(drop)地低于 1/2，那么 InnoDB 将缩短索引树并释放页面空间。
11.2 插入缓冲
主键是一个唯一标识符，新的记录以主键的升序 入，这在数据库系统中是一个普遍的情形。因而在聚簇索引内插入的值不需要在硬盘上随意读取，
另一方面，辅助索引通常是非唯一的(non-unique)，插入在辅助索引中是相当随意的顺序。如果在 InnoDB 中不使用一个特殊的机制这将会引起大量随机的磁盘 I/O。
如果一个索引记录 入到一个非唯一的辅助索引中去，InnoDB 将检查辅助索引页面是否已在缓冲池(buffer pool)中。在这种情形下，InnoDB 直接地将它插入到索引页面中去。但是，如果在缓冲池中没有发现索引页面，InnDB 将索引记录插入到一个特殊的插入缓冲结构中去。插入缓冲被控制地如些小以至于可以完全放在缓冲池中， 因而插入速度很快。
插入缓冲会定时地归并到数据库中的辅助索引树中去。为了减少磁盘 I/O，通常将同一个页面上的几个插入同时归并到索引树上。插入缓冲可以提高向一个表中插入速度 15倍。
11.3 适应性的散列索引 (Adaptive hash indexes)
如果一个数据库几乎占满了所有主同存，那么在其上运行查询的一个快捷之路就是使用散列索引(hash indexes)。InnoDB 有一个用于监视在表定义的索引上的索引搜索动作的自动调整结构，如果 InnoDB 发现一个散列索引对查询有益，那么它将自动地建造这个散列索引。
但是要注意地就是散列索引通常是基于表中已存在的 B-tree 创建的。InnoDB 可能通过 B-tree 中定义的任何长度的键的前缀来构建散列索引，这依赖于 InnoDB 观察 B-tree 上索引的模式。一个散列索引可以是部分的：它在缓冲池中并不需要有整个 B-tree 索引的高速缓冲。InnoDB 按照需要来为经常访问的索引页面构建散列索引。
在理论上，通过这个适应性的散列索引机制，InnpDB 使它自己更适合于大的主存(ample main memory)，更接近于主存储器数据库系统体系(the architecture of main memory databases)。
11.4 记录的物理结构 InnoDB 中每个索引记录都包含一个 6 字节的头。这个头部用于联连相连贯的记录，也同样用于行锁定。 聚簇索引中的记录包含了所有用户定义的字段。另外，有一个 6-byte 字段用于记录事务 id(transaction id)和一个 7-byte 字段用于行指针(roll pointer)。 在一个表中，如果用户没有定义一个主键，那么每个聚簇索引记录包含一个 6-byte 的行 id 字段(row id field)。 每个辅助索引记录包含为聚簇索引键定义的所有字段。 一个索引包含着一个指向对应字段记录的指针。如果一个记录的所有字段总长度< 128 bytes，那么这个指针为 1 byte，否则为 2 bytes。 InnoDB 在内部也是以一个固定长度来存储定长的字符型字段，比如 CHAR(10)。对于 VARCHAR 型字段，InnoDB 将截去结尾的空间。注意，MySQL 可能内部地将 CHAR 转换为 VARCHAR。查看 MySQL 用户手册有关“列规约的默认地改变”( 'Silent column specification changes')。 如果存储一个变长的字段，一个 SQL NULL 为一个 0 bytes 被存储，但是如果是一个定长字段将以固定的长度被存储。以相应的 NULLs 存储定长的空间的目的地就在于在将 NULL 字段值更新为 非 NULL 的值时不至产生索引页面的磁盘碎片。
★ ADO.NET读书笔记系列之DataSet对象数据库教程
InnoDB 中文参考手册 10 multiversioning 的实现数据库教程（精选7篇）
