MySQL性能优化（一）-- 存储引擎和三范式

1、MySQL存储引擎

　　存储引擎说白了就是如何存储数据、如何为存储的数据创建索引和如何更新、查询数据等技术的实现方法。由于在关系数据库中数据的存储是以表的形式存储的，因此存储引擎也能够称为表类型（即存储和操做此表的类型）。MySQL5.5之后默认使用InnoDB存储引擎。

　　下图是MySQL中各类存储引擎的对比。

　　

1.MyISAM：

　　这种引擎是mysql最先提供的。它不支持事务，也不支持外键，尤为是访问速度快。这种引擎又能够分为静态MyISAM、动态MyISAM 和压缩MyISAM三种：

　　1) 静态MyISAM：若是数据表中的各数据列的长度都是预先固定好的，服务器将自动选择这种表类型。由于数据表中每一条记录所占用的空间都是同样的，因此这种表存取和更新的效率很是高。 当数据受损时，恢复工做也比较容易作。这种存储方式的优势是存储很是迅速，容易缓存，出现故障容易恢复；缺点是占用的空间一般比动态表多。

　　 2) 动态MyISAM：若是数据表中出现varchar、xxxtext或xxxBLOB字段时，服务器将自动选择这种表类型。相对于静态MyISAM，这种表存储空间比较小，但因为每条记录的长度不一，因此 屡次修改数据后，数据表中的数据就可能离散的存储在内存中，进而致使执行效率降低。同时，内存中也可能会出现不少碎片。所以，这种类型的表要常常用optimize table命令或者myisamchk -r命令 或 优化工具来整理碎片、改善性能，而且出现故障的时候恢复相对比较困难。

　　3) 压缩MyISAM：以上说到的两种类型的表均可以用myisamchk工具压缩。这种类型的表进一步减少了占用的存储，可是这种表压缩以后不能再被修改。另外，由于是压缩数据，因此这种表在读取的时候要先时行解压缩。可是，不论是何种MyISAM表，目前它都不支持事务，行级锁和外键约束的功能。

2.Merge：

　　这种类型是MyISAM类型的一种变种。合并表是将几个相同的MyISAM表合并为一个虚表。常应用于日志和数据仓库。

3.InnoDB：

　　InnoDB表类型能够看做是对MyISAM的进一步更新产品，它提供了事务、行级锁机制和外键约束的功能。对比MyISAM的存储引擎，InnoDB写的处理效率差一些，而且会占用更多 的磁盘空间以保留数据和索引。

4.memory：

　　这种类型的数据表只存在于内存中。它使用HASH索引，因此数据的存取速度很是快。由于是存在于内存中，因此这种类型常应用于临时表中，可是一旦服务器关闭，表中的数据就会丢失，但表还会继续存在。默认状况下，memory数据表使用散列索引，利用这种索引进行“相等比较”很是快，可是对“范围比较”的速度就慢多了。所以，散列索引值适合使用在"="和"<=>"的操做符中，不适合使用在"<"或">"操做符中，也一样不适合用在order by字句里。若是确实要使用"<"或">"或betwen操做符，可使用btree索引来加快速度。

　　存储在MEMORY数据表里的数据行使用的是长度不变的格式，所以加快处理速度，这意味着不能使用BLOB和TEXT这样的长度可变的数据类型。VARCHAR是一种长度可变的类型，但由于它在MySQL内部看成长度固定不变的CHAR类型，因此可使用。

　　使用USING HASH/BTREE来指定特定到索引：create index mem_hash using hash on tab_memory(city_id);

5.archive：

　　这种类型只支持select 和 insert语句，并且不支持索引。常应用于日志记录和聚合分析方面。

2、存储引擎如何选择

• 是否支持事务
• 检索和添加速度
• 锁机制
• 缓存
• 是否支持全文索引
• 是否支持外键

3、MyISAM和InnoDB对比

　　

4、何时使用MyISAM和InnoDB

　　MyISAM：读事务要求不高，以查询和插入为主，可使用这个引擎来建立表，例如各类统计表。

　　InnoDB：对事务要求高，保存的是重要的数据，例如交易数据，支付数据等，对用户重要的数据，建议使用InnoDB。

5、对存储引擎的操做

1.查看数据库默认的存储引擎：show engines;   或者  show variables like 'default_storage_engine';

　　 

　　　

2.查看表的存储引擎：

　　1) 显示表的建立语句：show create table tablename;

　　   

　　2) 显示表的当前状态值：show table status like ‘tablename’ \G

　　　

　　3) 设置或修改表的存储引擎

• 建立数据库表时设置存储存储引擎的基本语法是：

　　　　create table tableName(

　　　　　　columnName(列名1) type(数据类型) attri(属性设置),

　　　　　　columnName(列名2) type(数据类型) attri(属性设置)，

　　　　　　....) engine = engineName

• 修改存储引擎，能够用命令 Alter table tableName engine = engineName

5、配置和数据文件

　　1.配置文件默认位置

　　　　Linux: /etc/my.cnf

　　　　Windows: my.ini

　　2.数据文件位置

　　　1) 查看数据文件位置的命令： show variables like '%datadir%' ;

　　　2) 数据文件格式：

　　　　　　InnoDB：frm（存储的表结构）、ibd（存储的数据和索引）

　　　　　　MyISAM：frm（存储的表结构）、MYD（存储的数据）、MYI（存储的索引）

6、数据库表设计

1.第一范式

　　1) 概念：列不可分。每一列都是不可分割的基本数据项。

　　2) 例子：假设咱们有一个学生表，字段包括：id,name,age,contact，以下：

　　  

　　   当咱们须要根据QQ来查询学生的时候，就查询不出，因此以上的设计就不符合1NF。咱们能够将contact字段拆分为phone和QQ，以下：

 　　

　　这样就知足1NF了。

2.第二范式　　　

　　1) 概念：1NF的基础上面，非主属性彻底依赖于主关键字。

　　2) 例子：学生表：(学号, 姓名, 年龄, 课程名称, 成绩, 学分) ，从字段能够看出，此表联合主键是（学号，课程名称）。

　　　存在以下决定关系：

　　　　1：(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

　　　　2：(课程名称) → (学分)

　　　　3：(学号) → (姓名, 年龄)

　　其中，姓名、年龄、学分是部分依赖于主键的，而成绩是彻底依赖于主键的，存在部分依赖关系，因此不知足第二范式。

　　这会形成以下问题：

　　　　(1) 数据冗余：

　　　　　　同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。

　　　　(2) 更新异常：

　　　　　　若调整了某门课程的学分，数据表中全部行的"学分"值都要更新，不然会出现同一门课程学分不一样的状况。

　　　　(3) 插入异常：

　　　　　　假设要开设一门新的课程，暂时尚未人选修。这样，因为尚未"学号"关键字，课程名称和学分也没法记录入数据 库。

　　　　(4) 删除异常：

　　　　　　假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。可是，与此同时，课程名称和学分信息也被删除了。很显然，这也会致使插入异常。

　　问题就在于存在非主属性对主键的部分依赖。

　　解决办法：把原表(学号, 姓名, 年龄, 课程名称, 成绩, 学分)分红三个表：

　　　　　　　学生：Student(学号, 姓名, 年龄)；

　　　　　　　课程：Course(课程名称, 学分)；

　　　　　　  选课关系：SelectCourse(学号, 课程名称, 成绩)。

3.第三范式

　　1) 概念：2NF的基础上，属性不依赖于其它非主属性 , 消除传递依赖。第三范式又可描述为：表中不存在能够肯定其余非关键字的非关键字段。

　　2) 例子：学生表：(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，主键必然是学号。

　　　　     因为主键是单一属性，因此非主属性彻底依赖于主键，因此必然知足第二范式。可是存在以下传递依赖：

　　　　　　(学号) → (所在学院) → (学院地点, 学院电话)，

　　　　　 学院地点 和 学院电话传递依赖于学号，而学院地点和学院电话都是非关键字段，即表中出现了“某一非关键字段能够肯定出其它非关键字段”的状况，因而违反了第三范式。　　　　　　　　　　

　　   解决办法：

　　　　把原表分红两个表：

　　　　　　学生：(学号, 姓名, 年龄, 所在学院)；

　　　　　　学院：(学院, 地点, 电话)。

7、参考：

　　http://www.cnblogs.com/gbyukg/archive/2011/11/09/2242271.html

　　http://www.cnblogs.com/lina1006/archive/2011/04/29/2032894.html

　　http://www.cnblogs.com/ybwang/archive/2010/06/04/1751279.html