MyISAM

StackOverFlow 上关于 MyISAM versus InnoDB 的回答。 https://stackoverflow.com/questions/20148/myisam-versus-innodb 。 数据库的定义 很多开发者在最开始时其实都对数据库有一个比较模糊的认识，觉得数据库就是一堆数据的集合，但是实际却比这复杂的多，数据库领域中有两个词非常容易混淆，也就是 数据库 和 实例 ： 数据库：物理操作文件系统或其他形式文件类型的集合； 实例：MySQL 数据库由后台线程以及一个共享内存区组成； 数据库和实例 在 MySQL 中，实例和数据库往往都是一一对应的，而我们也无法直接操作数据库，而是要通过数据库实例来操作数据库文件，可以理解为数据库实例是数据库为上层提供的一个专门用于操作的接口。  在 Unix 上，启动一个 MySQL 实例往往会产生两个进程， mysqld 就是真正的数据库服务守护进程，而 mysqld_safe 是一个用于检查和设置 mysqld 启动的控制程序，它负责监控 MySQL 进程的执行，当 mysqld 发生错误时， mysqld_safe 会对其状态进行检查并在合适的条件下重启。 MySQL

一个事务的一致性，举例：银行转帐的过程 两个事务之间的隔离性,举例：你取钱时，有人给汇款（产品购买）！ 默认情况下，直接执行的一条语句自己就是一个独立的事务，一个事务不能回滚其他的事务。 并发事务中可能发生的各种问题：脏读、不可重复读、虚（幻）读。 事务隔离级别：Read Uncommitted、Read Committed、Repeatable Read、Serializable 做事务实验时要注意MyISAM与InnoDB的问题,MyISAM就是Access一样的桌面数据库，不支持事务和主外键关联，讲课时用MyISAM犯犯错误，再引出InnoDB有较好的教学效果。 要把一个表从一个类型转到另一个类型，可使用ALTER TABLE语句，这个语句指明新的类型： ALTER TABLE t ENGINE = MYISAM; ALTER TABLE t TYPE = BDB; 虽然TYPE仍然在MySQL 5.1中被支持，现在ENGINE是首选的术语。 select @@autocommit;set autocommit=0|1 begin,commit,rollback; 用begin，则不用设置autocommit；设置autocommit,则不用begin; 第一个实验（select @@tx_isolation,看show variables知道的

http://www.cnblogs.com/RunForLove/p/5693986.html 数据库设计的三大范式：为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 　　在实际开发中最为常见的设计范式有三个：第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式；第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中；第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。总结一下，就是： 第一范式(确保每列保持原子性)； 第二范式(确保表中的每列都和主键相关)； 第三范式(确保每列都和主键列直接相关,而不是间接相关)。 　　在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题

存储引擎： 早期的时候，存在如何选择MyISAM和Innodb？ 现在，Innodb不断地发展完善，成为了主流的存储引擎。 因此5.5之后的mysql，无脑选择Innodb即可。 MYSQL中的数据，索引以及其他的对象，是如何存储的，是一套文件系统的实现。 MYSQL支持很多的存储引擎，使用 SHOW ENGINES 即可查到全部的引擎 MyISAM和Innodb的比较： 1.存储文件的角度：MyISAM数据和索引分别存储，数据是.myd，索引是.myi；Innodb数据和索引集中存储为.ibd，不支持文件级别的移动 2.记录存储顺序的角度：MyISAM顺序存储，直接在表末尾插入记录；Innodb主键顺序存储，插入时需要排序操作，稍影响了效率 3.空间碎片的角度：MyISAM会产生；Innodb不会产生；空间碎片就删除了以前的记录，MyISAM将会空余下来一些空间 通俗来讲，就说原来存储文件100K，我删除了一部分记录后还是100K 优化MyISAM的空间碎片： OPTIMIZE TABLE XXX; 4.外键和事务的角度：MyISAM不支持；Innodb支持，保证数据的完整性 5.全文索引的角度：MyISAM不支持；Innodb新版本支持，但是不支持中文，所以很鸡肋 6.锁的角度：MyISAM表级锁定；Innodb行级锁定，表级锁定，处理并发能力更强 总结：没有特殊需求

数据库使用过程当中索引的时候必不可少，合理创建索引可以极大地提升数据查询效率，但是如何索引创建不当也会影响我们的查询效率，如果想使用好索引我们就要来关注一下索引的原理。本文主要讲的mysql索引，且以InnoDB引擎为主，顺带与MyISAM引擎做对比。 1.Mysql表空间、段、区、页 在讲索引的概念之前我们先说一下mysql中段区页的概念。 表空间是Mysql数据库存储的最高层，默认情况下InnoDB引擎只有一个表空间，所有的数据都是存放在这个表空间内。 在表空间下数据是以段区页的形式进行存储的。一张Mysql表存储在数据库当中不是以行为单位存储数据读取的，mysql数据库读取的最小单位是页。 段：一个段是由多个区构成的， 常见的段有数据段、索引段、回滚段等，在InnoDB存储引擎中，对段的管理都是由引擎自身所完成的。 区：一个区是由多个 连续的页组成的空间 ，无论页的大小怎么变动，一个区的默认大小是1M，默认情况下一个区包含64个连续的页，为保证区中的页是连续的 InnoDB会一次从磁盘中申请4~5个区。 页：页也叫做块，默认情况下一个页大小为16K(可以通过 innodb_page_size 参数来设置一个页的大小)， 常见的页类型有：数据页，索引页， undo页 ，系统页，事务数据页等。 每页存储最多的行记录也是有硬性规定的最多16KB/2-200,即7992行 。

摘要 本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。 文章主要内容分为三个部分。 第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。 第二部分结合MySQL数据库中MyISAM和InnoDB数据存储引擎中索引的架构实现讨论聚集索引、非聚集索引及覆盖索引等话题。 第三部分根据上面的理论基础，讨论MySQL中高性能使用索引的策略。 数据结构及算法基础 索引的本质 MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。 我们知道，数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法当然是 顺序查找 （linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了很多更优秀的查找算法，例如 二分查找 （binary search）、 二叉树查找

mysql中锁的概念有很多，乐观锁、悲观锁、共享锁、排他锁、表锁、行锁等，他们之间有什么关系呢 乐观锁 乐观锁大多是基于数据版本记录机制实现，一般是给数据库表增加一个"version"字段。读取数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 悲观锁 悲观锁依靠数据库提供的锁机制实现。MySQL中的共享锁和排它锁都是悲观锁。数据库的增删改操作默认都会加排他锁，而查询不会加任何锁。 共享锁（读锁） 共享锁指的就是对于多个不同的事务，对于一个资源共享同一个锁。对某一资源加共享锁，自身可可读该资源，其他人也可以读该资源（也可以再加共享锁，即共享锁共享多个内存），但无法修改。要想修改就必须等所有共享锁都释放完之后。语法：select * from table lock in share mode; 排它锁（写锁） 排它锁指的就是对于多个不同的事务，对同一个资源只能有一把锁。对某一资源加排它锁，自身可以进行增删改查，其他人无法进行加锁操作，更无法进行增删改操作。语法：select * from table for update。 行锁 行锁就是给一行数据进行加锁，操作对象是数据表中的一行（共享锁和排他锁可能是行锁也可能是表锁

1 MyISAM和InnoDB的区别 　　 a 是否支持行级锁 : 　　MyISAM 只有表级锁 (table-level locking)， 　　而 InnoDB 支持行级锁 (row-level locking)和表级锁,默认为行级锁。 　　 b 是否支持事务和崩溃后的安全恢复： 　　 MyISAM 强调的是性能 ，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。 　　但是 InnoDB 提供事务支持事务 ，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。 　　 c 是否支持外键： 　　MyISAM不支持，而InnoDB支持。 　　 d 是否支持MVCC ： 　　仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。 2 索引 　　MySQL索引使用的数据结构主要有 BTree索引 和 哈希索 引 。 　　对于 哈希索引 来说

看了很多讲B树和B+树的文章，大多都是围绕各自的特性讲的，第一，树中每个结点最多含有m个孩子（m>=2）；第二，……我也是从这些文章里弄懂了各种树的联系与区别，要真写，我可能还不如人家写得好。所以就在这里简明扼要的用几张图记录一下主要区别吧。 为了便于说明，我们先定义一条数据记录为一个二元组[key,data]，key为记录的键值，key唯一；data为数据记录除key外的数据。 B树 每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。 B+树 只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。 后来，在B+树上增加了顺序访问指针，也就是每个叶子节点增加一个指向相邻叶子节点的指针，这样一棵树成了数据库系统实现索引的首选数据结构。 原因有很多，最主要的是这棵树矮胖，呵呵。一般来说，索引很大，往往以索引文件的形式存储的磁盘上，索引查找时产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的时间复杂度。树高度越小，I/O次数越少。 那为什么是B+树而不是B树呢，因为它内节点不存储data，这样一个节点就可以存储更多的key。 在MySQL中，最常用的两个存储引擎是MyISAM和InnoDB，它们对索引的实现方式是不同的。 MyISAM

MySQL体系结构如下： 下面介绍一下MySQL的存储引擎： MyISAM： MyISAM是MySQL5.5之前版本的默认存储引擎，在之后的版本中，系统表和临时表会使用到这个存储引擎； 由MYD和MYI组成（数据文件和索引文件），是MyISAM特有的，frm文件用来记录表结构，所用存储引擎都有这个文件； 表级锁，并发性不好； 不支持事务； 支持数据压缩； InnoDB: MySQL是MySQL5.5之后版本的默认存储引擎， 支持事务； 行级锁； 建议使用独立表空间： Redo log（已经提交的事务日志） 和Undo log（未提交的事务日志）； 来源： https://www.cnblogs.com/gaoquanquan/p/12433681.html