innodbtrx表数据被锁

① 一文详解-MySQL 事务和锁

当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常闭友必要的，事务具有以下四个特性：

MySQL 提供了多种事务型存储引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事务。为了支持事务，InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志，同时事务依赖于 MySQL 提供的锁机制

事务执行时需要将执行的事务日志写入日志文件，对应的文件为 REDO 日志。当每条 SQL 进行数据更新操作时，首先将 REDO 日志写进日志缓冲区。当客户端执行 COMMIT 命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制

REDO 日志对应磁盘上的 ib_logifleN 文件，该文件默认为 5MB，建议设置为 512MB，以便容纳较大的事务。MySQL 崩溃恢复时会重新执行 REDO 日志的记录，恢复最新数据，保证已提交事务的持久性

与 REDO 日志相反，UNDO 日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到 UNDO 缓冲区，然后在合适的时间将内容刷新到磁盘

假如由于系统错误或者 rollback 操作而导致事务回滚，可以根据 undo 日志回滚到没修改前的状态，保证未提交事务的原子性

与 REDO 日志不同的是，磁盘上不存在单独的 UNDO 日志文件，所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中，即使 MySQL 服务启动了独立表空间

在 MySQL 中，可以使用 BEGIN 开始事务，使用 COMMIT 结束事务，中间可以使用 ROLLBACK 回滚事务。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务

MySQL 定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少

InnoDB 系统级事务隔离级别可以使用以下语句设置：

查看系统级事务隔离级别：

InnoDB 会话级事务隔离级别可以使用以下语句设置：

查看会话级事务隔离级别：

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据称为脏读（Dirty Read），即困蔽是：首先开启 A 和 B 两个事务，在 B 事务更新但未提交之前，A 事务读取到了更新后的数据，但由于 B 事务回滚，导致 A 事务出现了脏读现象

所有事务只能看见已经提交事务所做的改变，此级别可以解决脏读，但也会导致不可重复读（Nonrepeatable Read）：首先开启 A 和 B 两个事务，A事务读取了 B 事务的数据，在 B 事务更新并提交后，A 事务又读取到了更新后的数据，此时就出现了同一 A 事务中的查询出现了不同的查询结果

MySQL 默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（Phontom Read）。例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生操作第一个事务的用户发现表中还有没有修改的数据行

InnoDB 通过多版本并汪态州发控制机制（MVCC）解决了该问题：InnoDB 通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果

通过强制事务排序，使其不可能相互冲突，从而解决幻读问题。简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用

为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询操作，需要对并发操作进行控制，因此产生了锁

共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读操作

排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写操作

有两个事务 A 和 B，如果事务 A 获取了一个元组的共享锁，事务 B 还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁，必须等到事务 A 释放共享锁之后。如果事务 A 获取了一个元组的排他锁，事务 B 不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到 A 释放排他锁之后

意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁和意向排他锁。意向共享锁表示一个事务有意对数据上共享锁或者排他锁。有意表示事务想执行操作但还没真正执行

锁的粒度主要分为表锁和行锁

表锁的开销最小，同时允许的并发量也是最小。MyISAM 存储引擎使用该锁机制。当要写入数据时，整个表记录被锁，此时其他读/写动作一律等待。一些特定的动作，如 ALTER TABLE 执行时使用的也是表锁

行锁可以支持最大的并发，InnoDB 存储引擎使用该锁机制。如果要支持并发读/写，建议采用 InnoDB 存储引擎

② MySQL数据库表被锁、解锁，删除事务

在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量操作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！

用户反馈系统部分功能无法使用，紧急排查，定位是数据库表被锁，然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程，建议点赞收藏，以备不时之需。

用户反馈某功能页面报502错误，于是第一时间看服务是否正常，数据库是否正常。在控制台看到数据库CPU飙升，堆积大量未提交事务，部分事务已经阻塞了很长时间，基本定位是数据库层出现问题了。

查看阻塞事务列表，发现其中有锁表现象，本想利用控制台直接结束掉阻塞的事务，但控制台账号权限有限，于是通过客户端登录对应账号将锁表事务kill掉，才避免了情况恶化。

下面就聊聊，如果当突然面对类似的情况，我们该如何紧急响应？

想象一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序，某一天突然数据库的表被锁了，业务无法正常运转，那么我们该如何快速定位是哪个事务锁了表，如何结束对应的事物？

首先最简单粗暴的方式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于后果如何，你能不能跑了，要你自己三思而后行了！

重启是可以解决表被锁的问题的，但针对线上业务很显然不太具有可行性。

下面来看看不用跑路的解决方案：

遇到数据库阻塞问题，首先要查询一下表是否在使用。

如果查询结果为空，那么说明表没在使用，说明不是锁表的问题。

如果查询结果不为空，比如出现如下结果：

则说明表（test）正在被使用，此时需要进一步排查。

查看数据库当前的进程，看看是否有慢SQL或被阻塞的线程。

执行命令：

该命令只显示当前用户正在运行的线程，当然，如果是root用户是能看到所有的。

在上述实慧明践中，阿里云控制台之所以能够查看到所有的线程，猜测应该使用的就是root用户，而笔者去kill的时候，无法kill掉，是因为登录的用户非root的数据库账号，无法操作另外一个用户的线程。

如果情况伍碧腔紧急，此步骤可以跳过，主要用来查看核对：

如果情况紧急，此步骤可以跳过，主要用来查看核对：

看事务表INNODB_TRX中是否有正在锁定的事务线程，看看ID是否在show processlist的sleep线程中。如果在，说明这个sleep的线程事务一直没有commit或者rollback，而是卡住了，需要手动kill掉。

搜索的结果中，如果在事务表发现了很多任务，最好都kill掉。

执行kill命令：

对应的线程都执行完kill命令之后，后续事务便可正常处理。

针对紧急情况，通常也会直接操作第一、第二、第六步。

这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地腔衫控制资源的访问规则，而锁就是用来实现这些访问规则的重要数据结构。

根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL中表级别的锁有两种：一种是表锁，一种是元数据锁（metadata lock，MDL)。

表锁是在Server层实现的，ALTER TABLE之类的语句会使用表锁，忽略存储引擎的锁机制。表锁通过lock tables… read/write来实现，而对于InnoDB来说，一般会采用行级锁。毕竟锁住整张表影响范围太大了。

另外一个表级锁是MDL（metadata lock），用于并发情况下维护数据的一致性，保证读写的正确性，不需要显式的使用，在访问一张表时会被自动加上。

常见的一种锁表场景就是有事务操作处于：Waiting for table metadata lock状态。

MySQL在进行alter table等DDL操作时，有时会出现Waiting for table metadata lock的等待场景。

一旦alter table TableA的操作停滞在Waiting for table metadata lock状态，后续对该表的任何操作（包括读）都无法进行，因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列。如果核心表出现了锁等待队列，就会造成灾难性的后果。

通过show processlist可以看到表上有正在进行的操作（包括读），此时alter table语句无法获取到metadata 独占锁，会进行等待。

通过show processlist看不到表上有任何操作，但实际上存在有未提交的事务，可以在information_schema.innodb_trx中查看到。在事务没有完成之前，表上的锁不会释放，alter table同样获取不到metadata的独占锁。

处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，让其回滚。

通过show processlist看不到表上有任何操作，在information_schema.innodb_trx中也没有任何进行中的事务。很可能是因为在一个显式的事务中，对表进行了一个失败的操作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效，没有释放。从performance_schema.events_statements_current表中可以查到失败的语句。

处理方法：通过performance_schema.events_statements_current找到其sid，kill 掉该session，也可以kill掉DDL所在的session。

总之，alter table的语句是很危险的（核心是未提交事务或者长事务导致的），在操作之前要确认对要操作的表没有任何进行中的操作、没有未提交事务、也没有显式事务中的报错语句。

如果有alter table的维护任务，在无人监管的时候运行，最好通过lock_wait_timeout设置好超时时间，避免长时间的metedata锁等待。

关于MySQL的锁表其实还有很多其他场景，我们在实践的过程中尽量避免锁表情况的发生，当然这需要一定经验的支撑。但更重要的是，如果发现锁表我们要能够快速的响应，快速的解决问题，避免影响正常业务，避免情况进一步恶化。所以，本文中的解决思路大家一定要收藏或记忆一下，做到有备无患，避免突然状况下抓瞎。

③ MySQL innodb引擎深入讲解

表空间(ibd文件),一个MySQL实例可以对应多个表空间，用于存储记录，索引等数据。

段，分为数据段、索引段、回滚段，innodb是索引组织表，数据段就是B+Tree的叶子节点，索引段为非叶子节点，段用来管理多个区。

区，表空间的单元结构，每个区的大小为1M,默认情况下，innodb存储引擎页大小为16K，即一个区中一共有64个连续的页。

页，是innodb存储引擎磁盘管理的最小单元，每个页的大小为16K，为了保证页的连续性，innodb存储引擎每次从磁盘申请4~5个区。

行，innodb存储引擎数据是按行进行存储的。Trx_id 最后一次事务操作的id、roll_pointer滚动指针。

i nnodb的内存结构 ，由Buffer Pool、Change Buffer和Log Buffer组成。

Buffer Pool : 缓冲池是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据(若缓冲池么有数据，则从磁盘加载并缓存)，然后再以一定频率刷新磁盘，从而减少磁盘IO，加快处理速度。

缓冲池以page页为单位，底层采用链表数据结构管理page，根据状态，将page分为三种类型:

1、free page 即空闲page，未被使用。

2、clean page 被使用page，数据没有被修改过。

3、dirty page 脏页，被使用page，数据被修改过，这个page当中的数据和磁盘当中的数据 不一致。说得简单点就是缓冲池中的数据改了，磁盘中的没改，因为还没刷写到磁盘。

Change Buffer ：更改缓冲区(针对于非唯一二级索引页)，在执行DML语句时，如果这些数据page没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区Change Buffer中，在未来数据被读取时。再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。

二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引页，同样，删除和更新可能会影响索引树中不相邻的二级索引页。如果每一次都操作磁盘，会造成大量磁盘IO，有了Change Buffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO。

Adaptive Hash Index： 自适应hash索引，用于优化对Buffer Pool数据的查询，InnoDB存储引擎会监控对表上各索引页的查询，如果观察到hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。无需人工干预，系统根据情况自动完成。

参数：innodb_adaptive_hash_index

Log Buffer: 日志缓冲区，用来保存要写入到磁盘中的log日志数据(redo log、undo log)，默认大小为16M，日志缓冲区的日志会定期刷新到磁盘中，如果需要更新，插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘IO。

参数: innodb_log_buffer_size 缓冲区大小

innodb_flush_log_at_trx_commit 日志刷新到磁盘时机

innodb_flush_log_at_trx_commit=1 表示日志在每次事务提交时写入并刷新到磁盘

2 表示日志在每次事务提交后写入，并每秒刷新到磁盘一次

0 表示每秒将日志写入并刷新到磁盘一次。

InnoDB 的磁盘结构，由系统表空间(ibdata1)，独立表空间(*.ibd),通用表空间，撤销表空间(undo tablespaces), 临时表空间(Temporary Tablespaces), 双写缓冲区(Doublewrite Buffer files), 重做日志(Redo Log).

系统表空间(ibdata1)： 系统表空间是更改缓冲区的存储区域，如果表是在系统表空间而不是每个表文件或者通用表空间中创建的，它也可能包含表和索引数据。

参数为: innodb_data_file_path

独立表空间(*.ibd): 每个表的文件表空间包含单个innodb表的数据和索引，并存储在文件系 统上的单个数据文件中。 参数: innodb_file_per_table

通用表空间: 需要通过create tablespace 语法创建，创建表时 可以指定该表空间。

create tablespace xxx add datafile 'file_name' engine=engine_name

create table table_name .... tablespace xxx

撤销表空间(undo tablespaces): MySQL实例在初始化时会自动创建两个默认的undo表空间(初始大小16K，undo_001,undo_002)，用于存储undo log 日志

临时表空间(Temporary Tablespaces)： innodb使用会话临时表空和全局表空间，存储用 户创建的临时表等数据。

双写缓冲区(Doublewrite Buffer files)： innodb引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入缓冲区文件中，便于系统异常时恢复数据。

重做日志(Redo Log)： 是用来实现事务的持久性，该日志文件由两部分组成，重做日志缓冲区(redo log buffer)以及重做日志文件(redo log)，前者是在内存中，后者在磁盘中，当事务提交之后会把修改信息都会存储到该日志中，用于在刷新脏页到磁盘时，发送错误时，进行数据恢复使用。以循环方式写入重做日志文件，涉及两个文件ib_logfile0,ib_logfile1。

那内存结构中的数据是如何刷新到磁盘中的? 在MySQL中有4个线程负责刷新日志到磁盘。

1、Master Thread， mysql核心后台线程，负责调度其它线程，还负责将缓冲池中的数据异 步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新，合并插入缓冲、undo页的回 收。

2、IO Thread，在innodb存储引擎中大量使用了AIO来处理IO请求，这样可以极大地提高数 据库的性能，而IO Thead主要负责这些IO请求的回调。

4个读线程 Read thread负责读操作

4个写线程write thread负责写操作

1个Log thread线程 负责将日志缓冲区刷新到磁盘

1个insert buffer线程 负责将写入缓冲区内容刷新到磁盘

3、Purge Thread，主要用于回收事务已经提交了的undo log，在事务提交之后，undo log 可能不用了，就用它来回收。

4、Page Cleaner Thread， 协助Master Thread 刷新脏页到磁盘的线程，它可以减轻主线程 的压力，减少阻塞。

事务就是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失效。

事务的4大特性分为:

如何保证事务的4大特性，原子性，一致性和持久性是由innodb存储引擎底层的两份日志来保证的，分别是redo log和undo log。对于隔离性是由锁机制和MVCC(多版本并发控制)来实现的。

redo log，称为重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。该日志文件由两部分组成: 重做日志缓冲redo log buffer及重做日志文件redo log file，前者是在内存中，后者是在磁盘中，当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发送错误时，进行数据的恢复使用，从而保证事务的持久性。

具体的操作流程是：

1、客户端发起事务操作，包含多条DML语句。首先去innodb中的buffer pool中的数据页去查找有没有我们要更新的这些数据，如果没有则通过后台线程从磁盘中加载到buffer pool对应的数据页中，然后就可以在缓冲池中进行数据操作了。

2、此时缓冲池中的数据页发生了变更，还没刷写到磁盘，这个数据页称为脏页。脏页不是实时刷新到磁盘的，而是根据你配置的刷写策略进行刷写到磁盘的（innodb_flush_log_at_trx_commit，0,1,2三个值）。如果脏页在往磁盘刷新的时候出现了故障，会丢失数据，导致事务的持久性得不到保证。为了避免这种现象，当对缓冲池中的数据进行增删改操作时，会把增删改记录到redo log buffer当中，redo log buffer会把数据页的物理变更持久化到磁盘文件中(ib_logfile0/ib_logfile1)。如果脏页刷新失败，就可以通过这两个日志文件进行恢复。

undo log，它是用来解决事务的原子性的，也称为回滚日志。用于记录数据被修改前的信息，作用包括:提供回滚和MVCC多版本并发控制。

undo log和redo log的记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，当update一条记录时，它记录一条对应相反的update记录，当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

undo log销毁: undo log 在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日子可能用于MVCC。

undo log存储: undo log 采用段的方式进行管理和记录，存放在前面介绍的rollback segment回滚段中，内部包含1024个undo log segment。

mvcc(multi-Version Concurrency Control),多版本并发控制，指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能，MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段，undo log日志、readView。

read committed 每次select 都生成一个快照读

repeatable read 开启事务后第一个select语句才是快照读的地方

serializable 快照读会退化为当前读。

mvcc的实现原理

DB_TRX_ID: 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID

DB_ROLL_PTR: 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个 版本

DB_ROW_ID: 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。

m_ids当前活跃的事务ID集合

min_trx_id: 最小活跃事务id

max_trx_id: 预分配事务ID，当前最大事务id+1，因为事务id是自增的

creator_trx_id: ReadView创建者的事务ID

版本链数据访问规则:

trx_id: 表示当前的事务ID

1、trx_id == creator_trx_id? 可以访问读版本-->成立的话,说明数据是当前这个事务更改的

2、trx_id 成立,说明数据已经提交了。

3、trx_id>max_trx_id？不可用访问读版本-> 成立的话，说明该事务是在ReadView生成后才开启的。

4、min_trx_id

④ mysql数据库锁表如何解锁

当前运行的所有事务
select * from information_schema.innodb_trx
当前出现的锁
select * from information_schema.innodb_locks
锁等待的对应关系
select * from information_schema.innodb_lock_waits
通过找到线程id号，进行kill

通过 select * from information_schema.innodb_trx 查询 trx_mysql_thread_id然后执行 kill 线程ID

⑤ mysql 中InnoDB和MyISAM的区别分析小结

InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。
下面是已知的两者之间的差别，仅供参考。

innodb
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。
InnoDB所有的表都保存在同一个数据文件 ibdata1 中（也可能是多个文件，或者是独立的
表空间文件）,相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份 binlog，
或者用 mysqlmp。

MyISAM
MyISAM 是MySQL缺省存贮引擎 .

每张MyISAM 表被存放在三个文件 。frm 文件存放表格定义。 数据文件是MYD (MYData) 。
索引文件是MYI (MYIndex) 引伸。

因为MyISAM相对简单所以在效率上要优于InnoDB..小型应用使用MyISAM是不错的选择.

MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦

MyISAM是ISAM表的新版本，有如下扩展：

·二进制层次的可移植性。
·NULL列索引。
·对变长行比ISAM表有更少的碎片。
·支持大文件。
·更好的索引压缩。
·更好的键吗统计分布。
·更好和更快的auto_increment处理。

以下是一些细节和具体实现的差别：

◆1.InnoDB不支持FULLTEXT类型的索引。
◆2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，
InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。
注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
◆3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM
表中，可以和其他字段一起建立联合索引。
◆4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
◆5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成
MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的
表不适用。

◆MyISAM类型的二进制数据文件可以在不同操作系统中迁移。

另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的
范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

再另外，使用两种的选择：如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，
应该使用InnoDB表。如果执行大量的SELECT，MyISAM是更好的选择。若需要使用事务处理，
但是原来的数据表使用的是myisam，就需要改为bdb或者innodb，这样基于myisam的程序，
将类型改为innodb后，其程序不用改动……

综上所述，任何一种表都不是万能的，只有恰当的针对业务类型来选择合适的表类型，才能
最大的发挥MySQL的性能优势。

MyISAM和InnoDB优化：
key_buffer_size - 这对MyISAM表来说非常重要。如果只是使用MyISAM表，可以把它设置
为可用内存的 30-40%。合理的值取决于索引大小、数据量以及负载 -- 记住，MyISAM表会
使用操作系统的缓存来缓存数据，因此需要留出部分内存给它们，很多情况下数据比索引大
多了。尽管如此，需要总是检查是否所有的 key_buffer 都被利用了 -- .MYI 文件只有 1GB
，而 key_buffer 却设置为 4GB 的情况是非常少的。这么做太浪费了。如果你很少使用
MyISAM表，那么也保留低于 16-32MB 的 key_buffer_size 以适应给予磁盘的临时表索引
所需。
innodb_buffer_pool_size - 这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更
为敏感。MyISAM可以在默认的 key_buffer_size 设置下运行的可以，然而Innodb在默认的
innodb_buffer_pool_size 设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来，
无需留给操作系统太多的内存，因此如果只需要用Innodb的话则可以设置它高达 70-80% 的
可用内存。一些应用于 key_buffer 的规则有 -- 如果你的数据量不大，并且不会暴增，那
么无需把
innodb_additional_pool_size - 这个选项对性能影响并不太多，至少在有差不多足够内存
可分配的操作系统上是这样。不过如果你仍然想设置为 20MB(或者更大)，因此就需要看一下
Innodb其他需要分配的内存有多少。
innodb_log_file_size 在高写入负载尤其是大数据集的情况下很重要。这个值越大则性能相
对越高，但是要注意到可能会增加恢复时间。我经常设置为 64-512MB，跟据服务器大小而异。
innodb_log_buffer_size 默认的设置在中等强度写入负载以及较短事务的情况下，服务器性
能还可以。如果存在更新操作峰值或者负载较大，就应该考虑加大它的值了。如果它的值设置
太高了，可能会浪费内存 -- 它每秒都会刷新一次，因此无需设置超过1秒所需的内存空间。
通常 8-16MB 就足够了。越小的系统它的值越小。
innodb_flush_logs_at_trx_commit 是否为Innodb比MyISAM慢1000倍而头大？看来也许你忘
了修改这个参数了。默认值是 1，这意味着每次提交的更新事务（或者每个事务之外的语句）
都会刷新到磁盘中，而这相当耗费资源，尤其是没有电池备用缓存时。很多应用程序，尤其是
从 MyISAM转变过来的那些，把它的值设置为 2 就可以了，也就是不把日志刷新到磁盘上，
而只刷新到操作系统的缓存上。日志仍然会每秒刷新到磁盘中去，因此通常不会丢失每秒1-
2次更新的消耗。如果设置为 0 就快很多了，不过也相对不安全了 -- MySQL服务器崩溃时
就会丢失一些事务。设置为 2 指挥丢失刷新到操作系统缓存的那部分事务。
table_cache -- 打开一个表的开销可能很大。例如MyISAM把MYI文件头标志该表正在使用
中。你肯定不希望这种操作太频繁，所以通常要加大缓存数量，使得足以最大限度地缓存打
开的表。它需要用到操作系统的资源以及内存，对当前的硬件配置来说当然不是什么问题了。
如果你有200多个表的话，那么设置为 1024 也许比较合适（每个线程都需要打开表），
如果连接数比较大那么就加大它的值。我曾经见过设置为 100,000 的情况。
thread_cache -- 线程的创建和销毁的开销可能很大，因为每个线程的连接/断开都需要。
我通常至少设置为 16。如果应用程序中有大量的跳跃并发连接并且 Threads_Created 的值
也比较大，那么我就会加大它的值。它的目的是在通常的操作中无需创建新线程。
query_cache -- 如果你的应用程序有大量读，而且没有应用程序级别的缓存，那么这很有
用。不要把它设置太大了，因为想要维护它也需要不少开销，这会导致MySQL变慢。通常设置
为 32-512Mb。设置完之后最好是跟踪一段时间，查看是否运行良好。在一定的负载压力下，
如果缓存命中率太低了，就启用它。
sort_buffer_size --如果你只有一些简单的查询，那么就无需增加它的值了，尽管你有
64GB 的内存。搞不好也许会降低性能

⑥ 怎么看mysql有没阻塞

通过下面的查询，来查询当前数据库，有哪些事务，都锁定哪些资源。

SELECT
	trx_idAS`事务ID`,
	trx_stateAS`事务状态`,
	trx_requested_lock_idAS`事务需要等待的资源`,
	trx_wait_started	AS`事务开始等待时间`,
	trx_tables_in_useAS`事务使用表`,
	trx_tables_lockedAS`事务拥有锁`,
	trx_rows_lockedAS`事务锁定行`,
	trx_rows_modifiedAS`事务更改行`
FROM
	information_schema.innodb_trx;

SELECT
	lock_id			AS	`锁ID`,
	lock_trx_id	AS	`拥有锁的事务ID`,
	lock_mode		AS	`锁模式	`,
	lock_type		AS	`锁类型`,
	lock_table		AS	`被锁的表`,
	lock_index		AS	`被锁的索引`,
	lock_space		AS	`被锁的表空间号`,
	lock_page		AS	`被锁的页号`,
	lock_rec		AS	`被锁的记录号`,
	lock_data		AS	`被锁的数据`
FROM
	information_schema.innodb_locks;

SELECT
requesting_trx_idAS`请求锁的事务ID`,
requested_lock_idAS`请求锁的锁ID`,
blocking_trx_idAS`当前拥有锁的事务ID`,
blocking_lock_idAS`当前拥有锁的锁ID`
FROM
innodb_lock_waits;