mysql介绍讲解(mysql的基本介绍)

目录：

• 1、MySQL详解
• 2、一文详解-MySQL 事务和锁
• 3、MYSQL的概念
• 4、MySQL innodb引擎深入讲解
• 5、MySQL数据库存储引擎详解

MySQL详解

数据查询语言（凡是带有 select 关键字的都是查询语句）

select...

数据操作语言（凡是对表中的 数据 进行增删改的都是 DML）

insert 增 delete 删 update 改

数据定义语言（凡是带有 create、drop、alter 的都是 DDL）

主要操作的是 表的结构 ，不是表的数据

事务控制语言（包括：事务提交 commit、事务回滚 rollback）

数据控制语言（授权 grant、撤销权限 revoke）

select 字段 from 表名 where 条件;

in(具体值，具体值，......) 不是区间

一个输入对应一个输出，和其对应的是多行处理函数（多个输入，对应一个输出）

输入多行，最终输出一行

如果你 没有对数据进行分组，整张表默认为一组 。

在实际的应用中，可能需要先进行分组，然后对每一组的数据进行操作

案例： 查询每个员工所在部门的名称，显示员工名和部门名？

emp e 和 dept d 表进行连接。条件是：e.deptno = d.deptno

SQL92语法：（结构不够清晰，表的连接条件和后期进一步筛选的条件，都放到了 where 子句中）

SQL99语法：（表连接的条件是独立的，连接之后，如果还需要进一步筛选，再往后继续添加 where 子句）

技巧： 把一张表看成两张表

思考： 外连接的查询结果条数 = 内连接的查询结果条数

select 语句中 嵌套 select 语句，被嵌套的 select 语句称为 子查询。

将查询结果集的一部分取出来。（通常使用在分页查询当中）

将字符串 varchar 类型转换成 date 类型

将日期转换成字符串

可以获取当前系统的时间，并且获取的时间是 datetime 类型的

注意：若没有条件限制将会导致所有数据全部更新。

注意：若没有条件，会删除整张表的数据。

constraint

not null 约束的字段 不能为 NULL （只有列级约束）

unique 约束的字段 不能重复 ，但是可以为 NULL

primary key

foreign key

transaction

实现原理 ：缩小扫描的范围（形成树），避免全表扫描

Database Administrator 数据库管理员

数据库表的设计依据。教你怎么进行数据库表的设计。

免费领取有关于java面试题材料和讲解！

一文详解-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的概念

MySQL是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 旗下公司。MySQL 最流行的关系型数据库管理系统，在 WEB 应用方面 MySQL 是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。

MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL 所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权政策，它分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。由于其社区版的性能卓越，搭配 PHP 和 Apache 可组成良好的开发环境。

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_idmax_trx_id？不可用访问读版本- 成立的话，说明该事务是在ReadView生成后才开启的。

4、min_trx_id

MySQL数据库存储引擎详解

存储引擎是什么？

MySQL中的数据用各种不同的技术存储在文件(或者内存)中 这些技术中的每一种技术都使用不同的存储机制 索引技巧 锁定水平并且最终提供广泛的不同的功能和能力 通过选择不同的技术 你能够获得额外的速度或者功能 从而改善你的应用的整体功能

例如 如果你在研究大量的临时数据 你也许需要使用内存存储引擎 内存存储引擎能够在内存中存储所有的表格数据 又或者 你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)

这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型) MySQL默认配置了许多不同的存储引擎 可以预先设置或者在MySQL服务器中启用 你可以选择适用于服务器 数据库和表格的存储引擎 以便在选择如何存储你的信息 如何检索这些信息以及你需要你的数据结合什么性能和功能的时候为你提供最大的灵活性

选择如何存储和检索你的数据的这种灵活性是MySQL为什么如此受欢迎的主要原因 其它数据库系统(包括大多数商业选择)仅支持一种类型的数据存储 遗憾的是 其它类型的数据库解决方案采取的 一个尺码满足一切需求 的方式意味着你要么就牺牲一些性能 要么你就用几个小时甚至几天的时间详细调整你的数据库 使用MySQL 我们仅需要修改我们使用的存储引擎就可以了

在这篇文章中 我们不准备集中讨论不同的存储引擎的技术方面的问题(尽管我们不可避免地要研究这些因素的某些方面) 相反 我们将集中介绍这些不同的引擎分别最适应哪种需求和如何启用不同的存储引擎 为了实现这个目的 在介绍每一个存储引擎的具体情况之前 我们必须要了解一些基本的问题

如何确定有哪些存储引擎可用

你可以在MySQL(假设是MySQL服务器 以上版本)中使用显示引擎的命令得到一个可用引擎的列表

mysql show engines;    + + + +    | Engine     | Support | Comment                                                    |    + + + +    | MyISAM     | DEFAULT | Default engine as of MySQL   with great performance     |    | HEAP       | YES     | Alias for MEMORY                                           |    | MEMORY     | YES     | Hash based  stored in memory  useful for temporary tables  |    | MERGE      | YES     | Collection of identical MyISAM tables                      |    | MRG_MYISAM | YES     | Alias for MERGE                                            |    | ISAM       | NO      | Obsolete storage engine  now replaced by MyISAM            |    | MRG_ISAM   | NO      | Obsolete storage engine  now replaced by MERGE             |    | InnoDB     | YES     | Supports transactions  row level locking  and foreign keys |    | INNOBASE   | YES     | Alias for INNODB                                           |    | BDB        | NO      | Supports transactions and page level locking               |    | BERKELEYDB | NO      | Alias for BDB                                              |    | NDBCLUSTER | NO      | Clustered  fault tolerant  memory based tables             |    | NDB        | NO      | Alias for NDBCLUSTER                                       |    | EXAMPLE    | NO      | Example storage engine                                     |    | ARCHIVE    | NO      | Archive storage engine                                     |    | CSV        | NO      | CSV storage engine                                         |    + + + +     rows in set (  sec)  

这个表格显示了可用的数据库引擎的全部名单以及在当前的数据库服务器中是否支持这些引擎

对于MySQL 以前版本 可以使用mysql show variables like have_% (显示类似 have_% 的变量):

mysql show variables like  have_% ;     + + +     | Variable_name    | Value    |     + + +     | have_bdb         | YES      |     | have_crypt       | YES      |     | have_innodb      | DISABLED |     | have_isam        | YES      |     | have_raid        | YES      |     | have_symlink     | YES      |     | have_openssl     | YES      |     | have_query_cache | YES      |     + + +      rows in set (  sec)    

你可以通过修改设置脚本中的选项来设置在MySQL安装软件中可用的引擎 如果你在使用一个预先包装好的MySQL二进制发布版软件 那么 这个软件就包含了常用的引擎 然而 需要指出的是 如果你要使用某些不常用的引擎 特别是CSV RCHIVE(存档)和BLACKHOLE(黑洞)引擎 你就需要手工重新编译MySQL源码

使用一个指定的存储引擎

你可以使用很多方法指定一个要使用的存储引擎 最简单的方法是 如果你喜欢一种能满足你的大多数数据库需求的存储引擎 你可以在MySQL设置文件中设置一个默认的引擎类型（使用storage_engine 选项）或者在启动数据库服务器时在命令行后面加上 default storage engine或 default table type选项

更灵活的方式是在随MySQL服务器发布同时提供的MySQL客户端时指定使用的存储引擎 最直接的方式是在创建表时指定存储引擎的类型 向下面这样:

CREATE TABLE mytable (id int title char( )) ENGINE = INNODB

你还可以改变现有的表使用的存储引擎 用以下语句:

ALTER TABLE mytable ENGINE = MyISAM

然而 你在以这种方式修改表格类型的时候需要非常仔细 因为对不支持同样的索引 字段类型或者表大小的一个类型进行修改可能使你丢失数据 如果你指定一个在你的当前的数据库中不存在的一个存储引擎 那么就会创建一个MyISAM(默认的)类型的表

各存储引擎之间的区别

为了做出选择哪一个存储引擎的决定 我们首先需要考虑每一个存储引擎提供了哪些不同的核心功能 这种功能使我们能够把不同的存储引擎区别开来 我们一般把这些核心功能分为四类:支持的字段和数据类型 锁定类型 索引和处理 一些引擎具有能过促使你做出决定的独特的功能 我们一会儿再仔细研究这些具体问题

字段和数据类型

虽然所有这些引擎都支持通用的数据类型 例如整型 实型和字符型等 但是 并不是所有的引擎都支持其它的字段类型 特别是BLOG（二进制大对象）或者TEXT文本类型 其它引擎也许仅支持有限的字符宽度和数据大小

这些局限性可能直接影响到你可以存储的数据 同时也可能会对你实施的搜索的类型或者你对那些信息创建的索引产生间接的影响 这些区别能够影响你的应用程序的性能和功能 因为你必须要根据你要存储的数据类型选择对需要的存储引擎的功能做出决策

锁定

数据库引擎中的锁定功能决定了如何管理信息的访问和更新 当数据库中的一个对象为信息更新锁定了 在更新完成之前 其它处理不能修改这个数据(在某些情况下还不允许读这种数据)

锁定不仅影响许多不同的应用程序如何更新数据库中的信息 而且还影响对那个数据的查询 这是因为查询可能要访问正在被修改或者更新的数据 总的来说 这种延迟是很小的 大多数锁定机制主要是为了防止多个处理更新同一个数据 由于向数据中插入信息和更新信息这两种情况都需要锁定 你可以想象 多个应用程序使用同一个数据库可能会有很大的影响

不同的存储引擎在不同的对象级别支持锁定 而且这些级别将影响可以同时访问的信息 得到支持的级别有三种:表锁定 块锁定和行锁定 支持最多的是表锁定 这种锁定是在MyISAM中提供的 在数据更新时 它锁定了整个表 这就防止了许多应用程序同时更新一个具体的表 这对应用很多的多用户数据库有很大的影响 因为它延迟了更新的过程

页级锁定使用Berkeley DB引擎 并且根据上载的信息页( KB)锁定数据 当在数据库的很多地方进行更新的时候 这种锁定不会出现什么问题 但是 由于增加几行信息就要锁定数据结构的最后 KB 当需要增加大量的行 也别是大量的小型数据 就会带来问题

行级锁定提供了最佳的并行访问功能 一个表中只有一行数据被锁定 这就意味着很多应用程序能够更新同一个表中的不同行的数据 而不会引起锁定的问题 只有InnoDB存储引擎支持行级锁定

建立索引

建立索引在搜索和恢复数据库中的数据的时候能够显著提高性能 不同的存储引擎提供不同的制作索引的技术 有些技术也许会更适合你存储的数据类型

有些存储引擎根本就不支持索引 其原因可能是它们使用基本表索引(如MERGE引擎)或者是因为数据存储的方式不允许索引(例如FEDERATED或者BLACKHOLE引擎)

事务处理

事务处理功能通过提供在向表中更新和插入信息期间的可靠性 这种可靠性是通过如下方法实现的 它允许你更新表中的数据 但仅当应用的应用程序的所有相关操作完全完成后才接受你对表的更改 例如 在会计处理中每一笔会计分录处理将包括对借方科目和贷方科目数据的更改 你需要要使用事务处理功能保证对借方科目和贷方科目的数据更改都顺利完成 才接受所做的修改 如果任一项操作失败了 你都可以取消这个事务处理 这些修改就不存在了 如果这个事务处理过程完成了 我们可以通过允许这个修改来确认这个操作

lishixinzhi/Article/program/MySQL/201311/29301