澳门金莎娱乐网站mysql数据库整理,mysql数据库相

作者: 数据库信息  发布:2019-08-15

7.MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义

(1)、varchar与char的区别
char是一种固定长度的类型,varchar则是一种可变长度的类型

(2)、varchar(50)中50的涵义
最多存放50个字符,varchar(50)和(200)存储hello所占空间一样,但后者在排序时会消耗更多内存,因为order by col采用fixed_length计算col长度(memory引擎也一样)

(3)、int(20)中20的涵义 是指显示字符的长度
但要加参数的,最大为255,比如它是记录行数的id,插入10笔资料,它就显示00000000001 ~~~00000000010,当字符的位数超过11,它也只显示11位,如果你没有加那个让它未满11位就前面加0的参数,它不会在前面加0 20表示最大显示宽度为20,但仍占4字节存储,存储范围不变;

(4)、mysql为什么这么设计
对大多数应用没有意义,只是规定一些工具用来显示字符的个数;int(1)和int(20)存储和计算均一样;

8.开放性问题:

一个6亿的表a,一个3亿的表b,通过外间tid关联,你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。
1、如果A表TID是自增长,并且是连续的,B表的ID为索引
select * from a,b where a.tid = b.id and a.tid>500000 limit 200;

2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。
select * from b , (select tid from a limit 50000,200) a where b.id = a .tid;

 

9.mysql数据库引擎MyISAM和InnoDB的区别

澳门金莎娱乐网站 1

 

10.MySql 表中允许有多少种 TRIGGERS?

在 MySql 表中允许有六种触发器,如下:
·BEFORE INSERT
·AFTER INSERT
·BEFORE UPDATE
·AFTER UPDATE
·BEFORE DELETE
·AFTER DELETE

 

数据库相关 1.InnoDB的日志 InnoDB有很多日志,日志中有2个概念需要分清楚,逻辑日志和物理日志. 1.1 逻辑...

2.3 一致性的实现

undo log 用来保证事务的一致性. undo 回滚行记录到某个特定版本,undo 是逻辑日志,根据每行记录进行记录.
undo 存放在数据库内部的undo段,undo段位于共享表空间内.
undo 只把数据库逻辑的恢复到原来的样子.

undo日志除了回滚作用之外, undo 实现MVCC(多版本并发控制),读取一行记录时,发现事务锁定,通过undo恢复到之前的版本,实现非锁定读取.

    myisam引擎不支持事务, innodb和BDB引擎支持

7.MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义

(1)、varchar与char的区别
char是一种固定长度的类型,varchar则是一种可变长度的类型

(2)、varchar(50)中50的涵义
最多存放50个字符,varchar(50)和(200)存储hello所占空间一样,但后者在排序时会消耗更多内存,因为order by col采用fixed_length计算col长度(memory引擎也一样)

(3)、int(20)中20的涵义 是指显示字符的长度
但要加参数的,最大为255,比如它是记录行数的id,插入10笔资料,它就显示00000000001 ~~~00000000010,当字符的位数超过11,它也只显示11位,如果你没有加那个让它未满11位就前面加0的参数,它不会在前面加0 20表示最大显示宽度为20,但仍占4字节存储,存储范围不变;

(4)、mysql为什么这么设计
对大多数应用没有意义,只是规定一些工具用来显示字符的个数;int(1)和int(20)存储和计算均一样;

4.MySQL中myisam与innodb的区别,至少5点

1>.InnoDB支持事物,而MyISAM不支持事物
2>.InnoDB支持行级锁,而MyISAM支持表级锁
3>.InnoDB支持MVCC, 而MyISAM不支持
4>.InnoDB支持外键,而MyISAM不支持
5>.InnoDB不支持全文索引,而MyISAM支持。

3. 索引有什么用

  • 作用:索引是与表或视图关联的磁盘上结构,可以加快从表或视图中检索行的速度。索引包含由表或视图中的一列或多列生成的键。这些键存储在一个结构(B树)中,使数据库可以快速有效地查找与键值关联的行。

  • 设计良好的索引可以减少磁盘 I/O 操作,并且消耗的系统资源也较少,从而可以提高查询性能。

  • 一般来说,应该在这些列 上创建索引,例如:
    在经常需要搜索的列上,可以加快搜索的速度;
    在作为主键的列上,强制该列的唯一性和组织表中数据的排列结构;
    在经常用在连接的列上,这 些列主要是一些外键,可以加快连接的速度;
    在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的; 
    在经常需要排序的列上创 建索引,因为索引已经排序,这样查询可以利用索引的排序,加快排序查询时间;
    在经常使用在WHERE子句中的列上面创建索引,加快条件的判断速度。

  • 索引的缺点:
    第一,创建索引和维护索引要耗费时间,这种时间随着数据 量的增加而增加。 
    第二,索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大。 
    第三,当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。

3. 索引有什么用

  • 作用:索引是与表或视图关联的磁盘上结构,可以加快从表或视图中检索行的速度。索引包含由表或视图中的一列或多列生成的键。这些键存储在一个结构(B树)中,使数据库可以快速有效地查找与键值关联的行。

  • 设计良好的索引可以减少磁盘 I/O 操作,并且消耗的系统资源也较少,从而可以提高查询性能。

  • 一般来说,应该在这些列 上创建索引,例如:
    在经常需要搜索的列上,可以加快搜索的速度;
    在作为主键的列上,强制该列的唯一性和组织表中数据的排列结构;
    在经常用在连接的列上,这 些列主要是一些外键,可以加快连接的速度;
    在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的; 
    在经常需要排序的列上创 建索引,因为索引已经排序,这样查询可以利用索引的排序,加快排序查询时间;
    在经常使用在WHERE子句中的列上面创建索引,加快条件的判断速度。

  • 索引的缺点:
    第一,创建索引和维护索引要耗费时间,这种时间随着数据 量的增加而增加。 
    第二,索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大。 
    第三,当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。

2.数据库范式

1 第一范式(1NF)

在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。

2 第二范式(2NF)

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。

3 第三范式(3NF)

满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。(我的理解是消除冗余)

2.数据库范式

1 第一范式(1NF)

在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。

2 第二范式(2NF)

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。

3 第三范式(3NF)

满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。(我的理解是消除冗余)

数据库相关面试题

3.MySQL的复制原理以及流程

基本原理流程,3个线程以及之间的关联;
1. 主:binlog线程——记录下所有改变了数据库数据的语句,放进master上的binlog中;

  1. 从:io线程——在使用start slave 之后,负责从master上拉取 binlog 内容,放进 自己的relay log中;
  2. 从:sql执行线程——执行relay log中的语句;

4.数据库优化相关

  • 临时表在如下几种情况被创建(临时表会消耗性能):
    1、如果group by 的列没有索引,必产生内部临时表。
    2、如果order by 与group by为不同列时,或多表联查时order by ,group by 包含的列不是第一张表的列,将会产生临时表 
    3、distinct 与order by 一起使用可能会产生临时表
    4、如果使用SQL_SMALL_RESULT,MySQL会使用内存临时表,除非查询中有一些必须要把临时表建立在磁盘上.
    5、union合并查询时会用到临时表
    6、某些视图会用到临时表,如使用temptable方式建立,或使用union或聚合查询的视图 想确定查询是否需要临时表,可以用EXPLAIN查询计划,并查看Extra列,看是否有Using temporary.

  • 建表: 表结构的拆分,如核心字段都用int,char,enum等定长结构
    非核心字段,或用到text,超长的varchar,拆出来单放一张表.
    建索引: 合理的索引可以减少内部临时表 
    写语句: 不合理的语句将导致大量数据传输以及内部临时表的使用

  • 表的优化与列类型选择
    表的优化:
    1: 定长与变长分离
    如 id int, 占4个字节, char(4) 占4个字符长度,也是定长, time 
    即每一单元值占的字节是固定的.
    核心且常用字段,宜建成定长,放在一张表.
    而varchar, text,blob,这种变长字段,适合单放一张表, 用主键与核心表关联起来.
    2:常用字段和不常用字段要分离.
    需要结合网站具体的业务来分析,分析字段的查询场景,查询频度低的字段,单拆出来.
    3:合理添加冗余字段.

  • 列选择原则:
    1:字段类型优先级 整型 > date,time > enum,char > varchar > blob

    列的特点分析:
    整型: 定长,没有国家/地区之分,没有字符集的差异
    time定长,运算快,节省空间. 考虑时区,写sql时不方便 where > ‘2005-10-12’;
    enum: 能起来约束值的目的, 内部用整型来存储,但与char联查时,内部要经历串与值的转化 Char 定长, 考虑字符集和(排序)校对集 varchar, 不定长 要考虑字符集的转换与排序时的校对集,速度慢.相比于char增加了一个长度标识,处理时需要多运算一次。 text/Blob 无法使用内存临时表

    附: 关于date/time的选择,明确意见

    2: 够用就行,不要慷慨 (如smallint,varchar(N))
    原因: 大的字段浪费内存,影响速度
    以年龄为例 tinyint unsigned not null ,可以存储255岁,足够. 用int浪费了3个字节 以varchar(10) ,varchar(300)存储的内容相同, 但在表联查时,varchar(300)要花更多内存

    3: 尽量避免用NULL()
    原因: NULL不利于索引,要用特殊的字节来标注. 每一行多了一个字节在磁盘上占据的空间其实更大.

    Enum列的说明
    1: enum列在内部是用整型来储存的
    2: enum列与enum列相关联速度最快
    3: enum列比(var)char 的弱势---在碰到与char关联时,要转化. 要花时间.
    4: 优势在于,当char非常长时,enum依然是整型固定长度.当查询的数据量越大时,enum的优势越明显.
    5: enum与char/varchar关联 ,因为要转化,速度要比enum->enum,char->char要慢,但有时也这样用-----就是在数据量特别大时,可以节省IO.

  • SQL语句优化
    1)应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
    2)应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
    select id from t where num is null
    可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
    select id from t where num=0
    3)很多时候用 exists 代替 in 是一个好的选择
    4)用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤

  • explain出来的各种item的意义;
    select_type 
    表示查询中每个select子句的类型
    type
    表示MySQL在表中找到所需行的方式,又称“访问类型”
    possible_keys 
    指出MySQL能使用哪个索引在表中找到行,查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询使用
    key
    显示MySQL在查询中实际使用的索引,若没有使用索引,显示为NULL
    key_len
    表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度
    ref
    表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值 
    Extra
    包含不适合在其他列中显示但十分重要的额外信息

  • profile的意义以及使用场景;
    查询到 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 Systemlock, Table lock 花多少时间等等


4.数据库优化相关

  • 临时表在如下几种情况被创建(临时表会消耗性能):
    1、如果group by 的列没有索引,必产生内部临时表。
    2、如果order by 与group by为不同列时,或多表联查时order by ,group by 包含的列不是第一张表的列,将会产生临时表 
    3、distinct 与order by 一起使用可能会产生临时表
    4、如果使用SQL_SMALL_RESULT,MySQL会使用内存临时表,除非查询中有一些必须要把临时表建立在磁盘上.
    5、union合并查询时会用到临时表
    6、某些视图会用到临时表,如使用temptable方式建立,或使用union或聚合查询的视图 想确定查询是否需要临时表,可以用EXPLAIN查询计划,并查看Extra列,看是否有Using temporary.

  • 建表: 表结构的拆分,如核心字段都用int,char,enum等定长结构
    非核心字段,或用到text,超长的varchar,拆出来单放一张表.
    建索引: 合理的索引可以减少内部临时表 
    写语句: 不合理的语句将导致大量数据传输以及内部临时表的使用

  • 表的优化与列类型选择
    表的优化:
    1: 定长与变长分离
    如 id int, 占4个字节, char(4) 占4个字符长度,也是定长, time 
    即每一单元值占的字节是固定的.
    核心且常用字段,宜建成定长,放在一张表.
    而varchar, text,blob,这种变长字段,适合单放一张表, 用主键与核心表关联起来.
    2:常用字段和不常用字段要分离.
    需要结合网站具体的业务来分析,分析字段的查询场景,查询频度低的字段,单拆出来.
    3:合理添加冗余字段.

  • 列选择原则:
    1:字段类型优先级 整型 > date,time > enum,char > varchar > blob

    列的特点分析:
    整型: 定长,没有国家/地区之分,没有字符集的差异
    time定长,运算快,节省空间. 考虑时区,写sql时不方便 where > ‘2005-10-12’;
    enum: 能起来约束值的目的, 内部用整型来存储,但与char联查时,内部要经历串与值的转化 Char 定长, 考虑字符集和(排序)校对集 varchar, 不定长 要考虑字符集的转换与排序时的校对集,速度慢.相比于char增加了一个长度标识,处理时需要多运算一次。 text/Blob 无法使用内存临时表

    附: 关于date/time的选择,明确意见

    2: 够用就行,不要慷慨 (如smallint,varchar(N))
    原因: 大的字段浪费内存,影响速度
    以年龄为例 tinyint unsigned not null ,可以存储255岁,足够. 用int浪费了3个字节 以varchar(10) ,varchar(300)存储的内容相同, 但在表联查时,varchar(300)要花更多内存

    3: 尽量避免用NULL()
    原因: NULL不利于索引,要用特殊的字节来标注. 每一行多了一个字节在磁盘上占据的空间其实更大.

    Enum列的说明
    1: enum列在内部是用整型来储存的
    2: enum列与enum列相关联速度最快
    3: enum列比(var)char 的弱势---在碰到与char关联时,要转化. 要花时间.
    4: 优势在于,当char非常长时,enum依然是整型固定长度.当查询的数据量越大时,enum的优势越明显.
    5: enum与char/varchar关联 ,因为要转化,速度要比enum->enum,char->char要慢,但有时也这样用-----就是在数据量特别大时,可以节省IO.

  • SQL语句优化
    1)应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
    2)应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
    select id from t where num is null
    可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
    select id from t where num=0
    3)很多时候用 exists 代替 in 是一个好的选择
    4)用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤

  • explain出来的各种item的意义;
    select_type 
    表示查询中每个select子句的类型
    type
    表示MySQL在表中找到所需行的方式,又称“访问类型”
    possible_keys 
    指出MySQL能使用哪个索引在表中找到行,查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询使用
    key
    显示MySQL在查询中实际使用的索引,若没有使用索引,显示为NULL
    key_len
    表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度
    ref
    表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值 
    Extra
    包含不适合在其他列中显示但十分重要的额外信息

  • profile的意义以及使用场景;
    查询到 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 Systemlock, Table lock 花多少时间等等


5.innodb引擎的4大特性

插入缓冲(insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)

2.1 事务的隔离性由存储引擎的锁来实现

  数据库事务会导致脏读、不可重复读和幻影读等问题。
  1)脏读:事务还没提交,他的修改已经被其他事务看到。
  2)不可重复读:同一事务中两个相同SQL读取的内容可能不同。两次读取之间其他事务提交了修改可能会造成读取数据不一致。
  3)幻影数据:同一个事务突然发现他以前没发现的数据。和不可重复读很类似,不过修改数据改成增加数据。

InnoDB提供了四种不同级别的机制保证数据隔离性。
不同于MyISAM使用表级别的锁,InnoDB采用更细粒度的行级别锁,提高了数据表的性能。InnoDB的锁通过锁定索引来实现,如果查询条件中有主键则锁定主键,如果有索引则先锁定对应索引然后再锁定对应的主键(可能造成死锁),如果连索引都没有则会锁定整个数据表。

4种隔离级别: 
1) READ UNCOMMITTED(未提交读)
事务中的修改,即使没有提交,对其它事务也是可见的. 脏读(Dirty Read).
2) READ COMMITTED(提交读)
一个事务开始时,只能"看见"已经提交的事务所做的修改. 这个级别有时候也叫不可重复读(nonrepeatable read).
3) REPEATABLE READ(可重复读)
该级别保证了同一事务中多次读取到的同样记录的结果是一致的. 但理论上,该事务级别还是无法解决另外一个幻读的问题(Phantom Read). 
幻读: 当某个事务读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录.当之前的事务再次读取该范围时,会产生幻行.(Phantom Row).
幻读的问题理应由更高的隔离级别来解决,但mysql和其它数据库不一样,它同样在可重复读的隔离级别解决了这个问题. 
mysql的可重复读的隔离级别解决了"不可重复读"和“幻读”2个问题. 
而oracle数据库,可能需要在“SERIALIZABLE”事务隔离级别下才能解决幻读问题.
mysql默认的隔离级别也是:REPEATABLE READ(可重复读)
4) SERIALIZABLE (可串行化)
强制事务串行执行,避免了上面说到的 脏读,不可重复读,幻读 三个的问题.

2.3 一致性的实现
undo log 用来保证事务的一致性. undo 回滚行记录到某个特定版本,undo 是逻辑日志,根据每行记录进行记录.
undo 存放在数据库内部的undo段,undo段位于共享表空间内.
undo 只把数据库逻辑的恢复到原来的样子.
undo日志除了回滚作用之外, undo 实现MVCC(多版本并发控制),读取一行记录时,发现事务锁定,通过undo恢复到之前的版本,实现非锁定读取.

    myisam引擎不支持事务, innodb和BDB引擎支持

2.事务的实现原理

事务的作用: 事务会把数据库从一种一致的状态转换为另一种一致状态。

事务的机制通常被概括为“ACID”原则即原子性(A)、一致性(C)、隔离性(I)和持久性(D)。

  1. 原子性:构成事务的的所有操作必须是一个逻辑单元,要么全部执行,要么全部不执行。
  2. 一致性:数据库在事务执行前后状态都必须是稳定的。
  3. 隔离性:事务之间不会相互影响。
  4. 持久性:事务执行成功后必须全部写入磁盘。

2.2 原子性和持久性的实现
redo log 称为重做日志(也叫事务日志),用来保证事务的原子性和持久性. 
redo恢复提交事务修改的页操作,redo是物理日志,页的物理修改操作.
当提交一个事务时,实际上它干了如下2件事:
一: InnoDB存储引擎把事务写入日志缓冲(log buffer),日志缓冲把事务刷新到事务日志.
二: InnoDB存储引擎把事务写入缓冲池(Buffer pool).
这里有个问题, 事务日志也是写磁盘日志,为什么不需要双写技术?
因为事务日志块的大小和磁盘扇区的大小一样,都是512字节,因此事务日志的写入可以保证原子性,不需要doublewrite技术
重做日志缓冲是由每个为512字节大小的日志块组成的. 日志块分为三部分: 日志头(12字节),日志内容(492字节),日志尾(8字节).

6.myisam和innodb 2者selectcount(*)哪个更快,为什么

myisam更快,因为myisam内部维护了一个计数器,可以直接调取。

4.MySQL中myisam与innodb的区别,至少5点

1>.InnoDB支持事物,而MyISAM不支持事物
2>.InnoDB支持行级锁,而MyISAM支持表级锁
3>.InnoDB支持MVCC, 而MyISAM不支持
4>.InnoDB支持外键,而MyISAM不支持
5>.InnoDB不支持全文索引,而MyISAM支持。

本文由金沙澳门官网发布于数据库信息,转载请注明出处:澳门金莎娱乐网站mysql数据库整理,mysql数据库相

关键词: 金沙澳门官网

上一篇:笔记分享,win7下MySQL的设置配置及卸载
下一篇:没有了