mysql5.6支持的存储引擎包括 InnoDB、MyISAM、MEMORY、CSV、BLACKHOLE、FEDERATED、MRG_MYISAM、 ARCHIVE、PERFORMANCE_SCHEMA。其中NDB和InnoDB提供事务安全表,其他存储引擎都是非事务安全表。
并发性:某些应用程序比其他应用程序具有很多的颗粒级锁定要求(如行级锁定)。 事务支持:并非所有的应用程序都需要事务,但对的确需要事务的应用程序来说,有着定义良好的需求,如ACID兼容等。 引用完整性:通过DDL定义的外键,服务器需要强制保持关联数据库的引用完整性。 物理存储:它包括各种各样的事项,从表和索引的总的页大小,到存储数据所需的格式,到物理磁盘。 索引支持:不同的应用程序倾向于采用不同的索引策略,每种存储引擎通常有自己的编制索引方法, 但某些索引方法(如B-tree索引)对几乎所有的存储引擎来说是共同的。 内存高速缓冲:与其他应用程序相比,不同的应用程序对某些内存高速缓冲策略的响应更好,因此, 尽管某些内存高速缓冲对所有存储引擎来说是共同的(如用于用户连接的高速缓冲,MySQL的高速查询高速缓冲等), 其他高速缓冲策略仅当使用特殊的存储引擎时才唯一定义。 性能帮助:包括针对并行操作的多I/O线程,线程并发性,数据库检查点,成批插入处理等。 其他目标特性:可能包括对地理空间操作的支持,对特定数据处理操作的安全限制等。
InnoDB 用于事务处理应用程序,支持外键和行级锁。如果应用对事物的完整性有比较高的要求,在并发条件下要求数据的一致性, 数据操作除了插入和查询之外,还包括很多更新和删除操作,那么InnoDB存储引擎是比较合适的。 InnoDB除了有效的降低由删除和更新导致的锁定,还可以确保事务的完整提交和回滚, 对于类似计费系统或者财务系统等对数据准确要求性比较高的系统都是合适的选择。 #InnoDB 5.6以上 默认存储方式 # 存储的文件个数:表结构、表中的数据 # 支持行级锁、支持表锁 ,修改数据多,#行级锁效率很低 # 支持事务 #开启事务不能再分,执行不成功回滚 # 支持外键 #外键 主要做数据关联 由于外键的约束,删除的时候要先删除关联 MyI SAM 如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性、并发性要求不高,那么可以选择这个存储引擎。 #MyI SAM 5.5以下 默认存储方式 # 存储的文件个数:表结构、表中的数据、索引 # 支持表级锁 # 不支持行级锁 不支持事务 不支持外键 Memory ['mɛməri] 将所有的数据保存在内存中,在需要快速定位记录和其他类似数据的环境下,可以提供极快的访问。 Memory的缺陷是对表的大小有限制,虽然数据库因为异常终止的话数据可以正常恢复,但是一旦数据库关闭,存储在内存中的数据都会丢失。 # MEMORY 内存 # 存储的文件个数:表结构 # 优势 :增删改查都很快 # 劣势 :重启数据消失、容量有限 # 用的不多 有别的替代品 ARCHIVE引擎 (了解) 拥有很好的压缩机制,它使用zlib压缩库,在记录被请求时会实时压缩。 支持最基本的插入和查询两种功能。在MySQL 5.5开始支持索引。 不支持事务。支持行级锁和专用的缓存区,所以可以实现高并发的插入。 适合存储大量日志、历史数据。 BLACKHOLE引擎 (了解) 接受但不存储数据,但是如果MySQL启用了二进制日志,SQL语句被写入日志(并被复制到从服务器)。 用于做日志记录或同步归档的中继存储。但这种应用方式会碰到很多问题,因此并不推荐。 支持事务,而且支持mvcc的行级锁。 CSV引擎 (了解) 每个表会生成一个.CSV文件,将CSV类型的文件当做表进行处理。 把数据以逗号分隔的格式存储在文本文件中,这种文件是一种普通文本文件,每个数据行占用一个文本行。 不支持索引,即使用该种类型的表没有主键列,也不允许表中的字段为null。
#你们上家公司用什么数据库 : mysql # 哪个版本是什么 :5.6.2.1 # 都用这个版本么 :不是都用这个版本 或 有部分用的不是这个版本 # 存储引擎 :innodb # 为什么要用这个存储引擎: # 支持事务 支持外键 支持行级锁 #事务,考虑以后的支付功能的扩展 #行级锁,能够更好的处理并发的修改问题
转载至:https://cloud.tencent.com/developer/article/1514588