一、存储引擎
MySQL里的存储引擎，“存储”指的是存储数据，“引擎”是发动机的核心部分,习惯上常用引擎来代指发动机，这里指数据库的核心。
简单来说，存储引擎就是数据的存储结构，由实际业务决定。
MySQL常见的四种存储引擎：
1.MyISAM
不支持事务，支持全文索引，不支持外键，B+树，表锁，对于一些在线分析处理操作速度快。数据和索引分离。
文件组成由 myd 存放数据的 myi存放索引的
2.InnoDB
支持事务，不支持全文索引，支持外键，B+树，行锁，主要是面向在线事务处理方面的应用，特点是行锁设计，并支持外键。Innodb采用聚集索引的方式。没有主键，没有唯一键，为每一行生产一个6字节的行id,作为主键。索引当作数据的一部分存储。
3.Memory
将数据放在内存中，如果数据库重启或者宕机，表数据就会丢失。非常适合存储一些临时表，默认的是哈希索引，不是B+树索引，varchar()默认是按照char()存储的，浪费内存。
不支持text和BLOB类型。varchar当成char类型处理。如果数据中有text和BLOB类型，数据库会把这些数字转换到磁盘上。
4.Archive
只支持INSERT和SELECT操作，一般用于日志处理，使用压缩算法将数据进行压缩后存储，压缩比例一般是1:10，主要提供插入和压缩功能。
二、索引
关于MySQL索引的好处，如果把正确合理设计并且使用索引的MySQL比作是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。对于没有索引的表，单表查询可能几十万数据就是瓶颈，而通常大型网站单日就可能会产生几十万甚至几百万的数据，没有索引查询会变的非常缓慢。其多个数据表都会对经常被查询的字段添加索引
索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。更通俗的说，数据库索引好比是一本书前面的目录，能加快数据库的查询速度。在没有索引的情况下，数据库会遍历全部200条数据后选择符合条件的；而有了相应的索引之后，数据库会直接在索引中查找符合条件的选项。如果我们把SQL语句换成“SELECT * FROM article WHERE id=2000000”，那么你是希望数据库按照顺序读取完200万行数据以后给你结果还是直接在索引中定位呢？（一般数据库默认都会为主键生成索引）。
索引分为聚簇索引和非聚簇索引两种，聚簇索引是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。
MySQL索引的类型
1. 普通索引
这是最基本的索引，它没有任何限制， MyIASM中默认的BTREE类型的索引，也是我们大多数情况下用到的索引。
|
01 |
–直接创建索引 |
|
|
02 |
CREATE INDEX index_name ON table(column(length)) |
|
|
03 |
–修改表结构的方式添加索引 |
|
|
04 |
ALTER TABLE table_name ADD INDEX index_name ON (column(length)) |
|
|
05 |
–创建表的时候同时创建索引 |
|
|
06 |
CREATE TABLE `table` ( |
|
|
07 |
`id` int(11) NOT NULL AUTO_INCREMENT , |
|
|
|
08 |
`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL , |
||
|
09 |
`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL , |
|
|
10 |
`time` int(10) NULL DEFAULT NULL , |
|
|
11 |
PRIMARY KEY (`id`), |
|
|
12 |
INDEX index_name (title(length)) |
|
|
13 |
) |
|
|
14 |
–删除索引 |
|
|
15 |
DROP INDEX index_name ON table |
2. 唯一索引
与普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值（注意和主键不同）。如果是组合索引，则列值的组合必须唯一，创建方法和普通索引类似。
|
01 |
–创建唯一索引 |
|
|
02 |
CREATE UNIQUE INDEX indexName ON table(column(length)) |
|
|
03 |
–修改表结构 |
|
|
04 |
ALTER TABLE table_name ADD UNIQUE indexName ON (column(length)) |
|
|
05 |
–创建表的时候直接指定 |
|
|
06 |
CREATE TABLE `table` ( |
|
|
07 |
`id` int(11) NOT NULL AUTO_INCREMENT , |
|
|
|
08 |
`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL , |
||
|
09 |
`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL , |
|
|
10 |
`time` int(10) NULL DEFAULT NULL , |
|
|
11 |
PRIMARY KEY (`id`), |
|
|
12 |
UNIQUE indexName (title(length)) |
|
|
13 |
); |
3. 全文索引（FULLTEXT）
MySQL从3.23.23版开始支持全文索引和全文检索，FULLTEXT索引仅可用于 MyISAM 表；他们可以从CHAR、VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或CREATE INDEX被添加。////对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引，其速度比把资料输入现有FULLTEXT索引的速度更为快。不过切记对于大容量的数据表，生成全文索引是一个非常消耗时间非常消耗硬盘空间的做法。
|
01 |
–创建表的适合添加全文索引 |
|
|
02 |
CREATE TABLE `table` ( |
|
|
03 |
`id` int(11) NOT NULL AUTO_INCREMENT , |
|
|
|
04 |
`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL , |
||
|
05 |
`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL , |
|
|
06 |
`time` int(10) NULL DEFAULT NULL , |
|
|
07 |
PRIMARY KEY (`id`), |
|
|
08 |
FULLTEXT (content) |
|
|
09 |
); |
|
|
10 |
–修改表结构添加全文索引 |
|
|
11 |
ALTER TABLE article ADD FULLTEXT index_content(content) |
|
|
12 |
–直接创建索引 |
|
|
13 |
CREATE FULLTEXT INDEX index_content ON article(content) |
4. 单列索引、多列索引
多个单列索引与单个多列索引的查询效果不同，因为执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引。
5. 组合索引（最左前缀）
平时用的SQL查询语句一般都有比较多的限制条件，所以为了进一步榨取MySQL的效率，就要考虑建立组合索引。例如上表中针对title和time建立一个组合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。建立这样的组合索引，其实是相当于分别建立了下面两组组合索引：
–title,time
–title
为什么没有time这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这两列的查询都会用到该组合索引，如下面的几个SQL所示：
|
1 |
–使用到上面的索引 |
|
|
2 |
SELECT * FROM article WHREE title='测试' AND time=1234567890; |
|
|
3 |
SELECT * FROM article WHREE utitle='测试'; |
|
|
4 |
–不使用上面的索引 |
|
|
5 |
SELECT * FROM article WHREE time=1234567890; |
上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。下面是一些总结以及收藏的MySQL索引的注意事项和优化方法。
1. 何时使用聚集索引或非聚集索引？
|
动作描述 |
使用聚集索引 |
使用非聚集索引 |
|
列经常被分组排序 |
使用 |
使用 |
|
返回某范围内的数据 |
使用 |
不使用 |
|
一个或极少不同值 |
不使用 |
不使用 |
|
小数目的不同值 |
使用 |
不使用 |
|
大数目的不同值 |
不使用 |
使用 |
|
频繁更新的列 |
不使用 |
使用 |
|
外键列 |
使用 |
使用 |
|
主键列 |
使用 |
使用 |
|
频繁修改索引列 |
不使用 |
使用 |
事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。其实这个具体用法我还不是很理解，只能等待后期的项目开发中慢慢学学了。
2. 索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
3. 使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
4. 索引列排序
MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
5. like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
6. 不要在列上进行运算
例如：select * from users where YEAR(adddate)<2007，将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成：select * from users where adddate<’2007-01-01′。
三. 事务
事务由单独单元的一个或多个SQL语句组成，在这个单元中，每个MySQL语句是相互依赖的。而整个单独单元作为一个不可分割的整体，如果单元中某条SQL语句一旦执行失败或产生错误，整个单元将会回滚。所有受到影响的数据将返回到事物开始以前的状态；如果单元中的所有SQL语句均执行成功，则事物被顺利执行。
InnoDB的事务
严格上来说，事务必须同时满足4个特性，即通常所说事务的ACID特性。虽然理论上定义了严格的事务要求，但是数据库厂商出于各种目的并没有严格满足事务的ACID标准。例如，对于MYSQL的NDB Cluster引擎，虽然支持事务，但是不满足D的要求，即持久性的要求。对于Oracle数据库来说，其默认的事务隔离级别为READ COMMITTED，不满足I的要求，即隔离性的要求。对于InnoDB存储引擎而言，默认的事务隔离级别是READ REPRATABLE，完全遵循和满足事务的ACID特性。
事务的ACID
1. A(atomicity) 原子性。一个事务的执行被视为一个不可分割的最小单元。事务里面的操作，要么全部成功执行，要么全部失败回滚，不可以只执行其中的一部分。
2. C(consistency) 一致性。一个事务的执行不应该破坏数据库的完整性约束。如果上述例子中第2个操作执行后系统崩溃，保证A和B的金钱总计是不会变的。
3. I(isolation) 隔离性。通常来说，事务之间的行为不应该互相影响。然而实际情况中，事务相互影响的程度受到隔离级别的影响。
4. D(durability) 持久性。事务提交之后，需要将提交的事务持久化到磁盘。即使系统崩溃，提交的数据也不应该丢失。