2007/08/12 23:18
一、什么是索引？
索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
假设我们创建了一个名为people的表：
然后，我们完全随机把1000个不同name值插入到people表。下图显示了people表所在数据文件的一小部分：
可以看到，在数据文件中name列没有任何明确的次序。如果我们创建了name列的索引，MySQL将在索引中排序name列：
对于索引中的每一项，MySQL在内部为它保存一个数据文件中实际记录所在位置的“指针”。因此，如果我们要查找name等于“Mike”记录的peopleid（SQL命令为“SELECT peopleid FROM people WHERE name=\'Mike\';”），MySQL能够在name的索引中查找“Mike”值，然后直接转到数据文件中相应的行，准确地返回该行的peopleid（999）。在这个过程中，MySQL只需处理一个行就可以返回结果。如果没有“name”列的索引，MySQL要扫描数据文件中的所有记录，即1000个记录！显然，需要MySQL处理的记录数量越少，则它完成任务的速度就越快。
二、索引的类型
MySQL提供多种索引类型供选择：
索引可以是单列索引，也可以是多列索引。下面我们通过具体的例子来说明这两种索引的区别。假设有这样一个people表：
由于索引文件以B-树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录！
那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。
四、最左前缀
多列索引还有另外一个优点，它通过称为最左前缀（Leftmost Prefixing）的概念体现出来。继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。当搜索条件是以下各种列的组合时，MySQL将使用fname_lname_age索引：
下面我们就来看看这个EXPLAIN分析结果的含义。
到目前为止，我们讨论的都是索引的优点。事实上，索引也是有缺点的。
首先，索引要占用磁盘空间。通常情况下，这个问题不是很突出。但是，如果你创建每一种可能列组合的索引，索引文件体积的增长速度将远远超过数据文件。如果你有一个很大的表，索引文件的大小可能达到操作系统允许的最大文件限制。
第二，对于需要写入数据的操作，比如DELETE、UPDATE以及INSERT操作，索引会降低它们的速度。这是因为MySQL不仅要把改动数据写入数据文件，而且它还要把这些改动写入索引文件。
【结束语】
在大型数据库中，索引是提高速度的一个关键因素。不管表的结构是多么简单，一次500000行的表扫描操作无论如何不会快。如果你的网站上也有这种大规模的表，那么你确实应该花些时间去分析可以采用哪些索引，并考虑是否可以改写查询以优化应用。另外注意，本文假定你所使用的MySQL是3.23版，部分查询不能在3.22版MySQL上执行。
索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
假设我们创建了一个名为people的表：
| CREATE TABLE people ( peopleid SMALLINT NOT NULL, name CHAR(50) NOT NULL ); |
然后，我们完全随机把1000个不同name值插入到people表。下图显示了people表所在数据文件的一小部分：
可以看到，在数据文件中name列没有任何明确的次序。如果我们创建了name列的索引，MySQL将在索引中排序name列：
对于索引中的每一项，MySQL在内部为它保存一个数据文件中实际记录所在位置的“指针”。因此，如果我们要查找name等于“Mike”记录的peopleid（SQL命令为“SELECT peopleid FROM people WHERE name=\'Mike\';”），MySQL能够在name的索引中查找“Mike”值，然后直接转到数据文件中相应的行，准确地返回该行的peopleid（999）。在这个过程中，MySQL只需处理一个行就可以返回结果。如果没有“name”列的索引，MySQL要扫描数据文件中的所有记录，即1000个记录！显然，需要MySQL处理的记录数量越少，则它完成任务的速度就越快。
二、索引的类型
MySQL提供多种索引类型供选择：
- 普通索引
这是最基本的索引类型，而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建：- 创建索引，例如CREATE INDEX <索引的名字> ON tablename (列的列表);
- 修改表，例如ALTER TABLE tablename ADD INDEX [索引的名字] (列的列表);
- 创建表的时候指定索引，例如CREATE TABLE tablename ( [...], INDEX [索引的名字] (列的列表) );
- 唯一性索引
这种索引和前面的“普通索引”基本相同，但有一个区别：索引列的所有值都只能出现一次，即必须唯一。唯一性索引可以用以下几种方式创建：- 创建索引，例如CREATE UNIQUE INDEX <索引的名字> ON tablename (列的列表);
- 修改表，例如ALTER TABLE tablename ADD UNIQUE [索引的名字] (列的列表);
- 创建表的时候指定索引，例如CREATE TABLE tablename ( [...], UNIQUE [索引的名字] (列的列表) );
- 主键
主键是一种唯一性索引，但它必须指定为“PRIMARY KEY”。如果你曾经用过AUTO_INCREMENT类型的列，你可能已经熟悉主键之类的概念了。主键一般在创建表的时候指定，例如“CREATE TABLE tablename ( [...], PRIMARY KEY (列的列表) ); ”。但是，我们也可以通过修改表的方式加入主键，例如“ALTER TABLE tablename ADD PRIMARY KEY (列的列表); ”。每个表只能有一个主键。 - 全文索引
MySQL从3.23.23版开始支持全文索引和全文检索。在MySQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。它可以通过CREATE TABLE命令创建，也可以通过ALTER TABLE或CREATE INDEX命令创建。对于大规模的数据集，通过ALTER TABLE（或者CREATE INDEX）命令创建全文索引要比把记录插入带有全文索引的空表更快。
索引可以是单列索引，也可以是多列索引。下面我们通过具体的例子来说明这两种索引的区别。假设有这样一个people表：
| ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age); |
由于索引文件以B-树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录！
那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。
四、最左前缀
多列索引还有另外一个优点，它通过称为最左前缀（Leftmost Prefixing）的概念体现出来。继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。当搜索条件是以下各种列的组合时，MySQL将使用fname_lname_age索引：
- firstname，lastname，age
- firstname，lastname
- firstname
| table | type | possible_keys | key | key_len | ref | rows | Extra |
| people | ref | fname_lname_age | fname_lname_age | 102 | const,const,const | 1 | Where used |
下面我们就来看看这个EXPLAIN分析结果的含义。
- table：这是表的名字。
- type：连接操作的类型。下面是MySQL文档关于ref连接类型的说明：
“对于每一种与另一个表中记录的组合，MySQL将从当前的表读取所有带有匹配索引值的记录。如果连接操作只使用键的最左前缀，或者如果键不是UNIQUE或PRIMARY KEY类型（换句话说，如果连接操作不能根据键值选择出唯一行），则MySQL使用ref连接类型。如果连接操作所用的键只匹配少量的记录，则ref是一种好的连接类型。”
在本例中，由于索引不是UNIQUE类型，ref是我们能够得到的最好连接类型。
如果EXPLAIN显示连接类型是“ALL”，而且你并不想从表里面选择出大多数记录，那么MySQL的操作效率将非常低，因为它要扫描整个表。你可以加入更多的索引来解决这个问题。预知更多信息，请参见MySQL的手册说明。 - possible_keys：
可能可以利用的索引的名字。这里的索引名字是创建索引时指定的索引昵称；如果索引没有昵称，则默认显示的是索引中第一个列的名字（在本例中，它是“firstname”）。默认索引名字的含义往往不是很明显。 - Key：
它显示了MySQL实际使用的索引的名字。如果它为空（或NULL），则MySQL不使用索引。 - key_len：
索引中被使用部分的长度，以字节计。在本例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节。如果MySQL只使用索引中的firstname部分，则key_len将是50。 - ref：
它显示的是列的名字（或单词“const”），MySQL将根据这些列来选择行。在本例中，MySQL根据三个常量选择行。 - rows：
MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然，这里最理想的数字就是1。 - Extra：
这里可能出现许多不同的选项，其中大多数将对查询产生负面影响。在本例中，MySQL只是提醒我们它将用WHERE子句限制搜索结果集。
到目前为止，我们讨论的都是索引的优点。事实上，索引也是有缺点的。
首先，索引要占用磁盘空间。通常情况下，这个问题不是很突出。但是，如果你创建每一种可能列组合的索引，索引文件体积的增长速度将远远超过数据文件。如果你有一个很大的表，索引文件的大小可能达到操作系统允许的最大文件限制。
第二，对于需要写入数据的操作，比如DELETE、UPDATE以及INSERT操作，索引会降低它们的速度。这是因为MySQL不仅要把改动数据写入数据文件，而且它还要把这些改动写入索引文件。
【结束语】
在大型数据库中，索引是提高速度的一个关键因素。不管表的结构是多么简单，一次500000行的表扫描操作无论如何不会快。如果你的网站上也有这种大规模的表，那么你确实应该花些时间去分析可以采用哪些索引，并考虑是否可以改写查询以优化应用。另外注意，本文假定你所使用的MySQL是3.23版，部分查询不能在3.22版MySQL上执行。
MySQL对于成为一个非常快速的数据库服务器有着当之无愧的名声，它也非常容易设置和使用。随着它作为网站后端数据库得声望日增，其效果在去年开始有明显提高。但是很多MySQL用户更多地知道如何创建一个数据库并编写对它的查询。就像成千上万的人通过载闲暇时用Linux做实验来学习Unix那样，很多人通过玩MySQL学习关系数据库。这些MySQL新手的大多数既没有关系数据库理论的背景，又没有时间阅读MySQL手册全文。
因此，我们决定研究某些方法，你可以用针对优化性能来调节MySQL。在读完本文后，你将理解一些帮助你设计你的MySQL数据库和查询的技术，值得你的应用很有效率。我们将假定你熟悉MySQL和SQL基础，但不假定你有这两方面的广博知识。
只存储你需要的信息
这听上去是常识，但人们常常采取“厨房下水道”的方式进行数据库设计。他们认为可能项要得每样东西都要存储并设计数据库保存所有者这些数据。你需要对你的需求现实些，并确定取确实需要什么信息。你常常能随意产生一些数据而不把它存在数据库表中。在这种情况下，从一个应用开发者的角度看也有道理这样做。
例如，在线目录的产品表可能包含各种产品的名称、介绍、尺寸、重量和价格。除了价格，你可能想存储每个项目相关的税和运输成本。但实际上不必这样做。首先税和运输成本可以方便地（由你的应用或MySQL）计算出来。其次，如果税和运输成本改变了，你可能必须编写必要的查询更新每个产品记录中的税和运输的费率。
有时人们认为这太难不能在以后往数据库表中加入字段，所以他们感觉不得不定义尽可能多的列。这是明显的概念错误。在MySQL中，你可以用ALTER TABLE命令方便地修改表定义以适应你改变的需求。
例如，如果你突然认识到你需要给你的产品表增加一个级别列（可能你想允许用户在你的目录中给产品评级），你可以这样做：
ALTER TABLE products ADD rank INTEGER
这给你的产品表增加了一个整数类型的级别列，你能用ALTER TABLE做什么的完整介绍参见MySQL手册。
只要求你需要的东西--要清晰
就像说“只存储你需要的东西”那样，这可能看来是常识，但这一点常常被忽视，为什么呢？因为在一个应用开发时，需求经常改变，所以很多查询最终看来是这样：
SELECT * FROM sometable
当你不能肯定你将需要哪一列时，要求所有列明显是最省力的事情，然而随着你的表不断增大和修改，这可能变成一个性能问题。最好是在你的最初开发完成后再花些时间并确定你真正从你的查询中需要什么：
SELECT name, rank, description FROM products
这带来了一个相关的观点，即代码维护比性能更重要。大多数变成语言（Perl、Python、PHP、Java等）允许通过字段名和数字编号访问一条查询的结果，这意味着你可以访问命名字段或字段０都可以得到相同的数据。
长期看，最好使用列名而不是其编号位置，为什么？因为一个表中或一条查询中地列的相对位置可以改变。它们在表中可能因为重复使用ALTER TABLE而改变，它们在查询中将因重写了查询而忘记更新应用逻辑来匹配而改变。
当然，你仍然需要小心改变列名！但如果你使用列名而非标号位置，如列名改变，你可以用grep搜索源代码或使用编辑器的搜索能力查找你需要修改的代码。
规范化你的表结构
如果你以前从未听说过“数据规范化”，不要害怕。规范化可能是一个复杂的专题，你可以从只理解最基本的规范化概念中正真正获益。
理解它的最容易的方法是认为你的表是一个电子报表。如果你想以一个报表跟踪你的CD收藏，你可以如图１种那样进行设计：
图１
album track1 track2 track10
----- ------ ------ -------
Billboard Top Hits - 1984 Loverboy Shout St. Elmo's Fire
(Billy Ocean) (Tears for Fears) (John Parr)
这看上去很合理。大多数CD只有10首曲子，对否？不尽然。如果你拥有一张有100首曲子的CD且几张超过20首改怎么办。这意味着用这种方法，在极端的情况下，你将需要一个非常宽的表格（或一个超过100个字段的表）来保存所有的数据。
规范化表结构的目标是使“空单元”的数量最少，在上述CD表的情况下，如果你允许CD可能包含100首曲子，你会有很多这样的空单元。不管你何时处理可能扩展到类似该CD表那样数量的字段列表，它是你需要将你的数据分割成2个或更多表的标志，然后你一起访问并获得你需要的数据。
很多关系数据库的新手不真正知道关系数据库管理系统中关系是什么。简单地说，就像一组信息存在可以基于共性数据联结（JOIN）在一起的不同表中，很不幸，这听上去更学术化和含糊，但CD数据库提出了一个具体情况，我们可以研究如何规范数据。
每个CD列表有一个固定的属性（标题、艺术家、年份、分类）集和一个不定的属性（曲目表）集的理解给了我们一些如何分成成能相互关联的表的思路。
你可以创建一个所有专辑及其固定属性的表，另一个包含这些专辑的所有曲目的表。这样不是水平思考（像表格），你垂直思考--就好像你创建列表而不是行--并建立一个如图2的表结构：
点击查看大图
专辑的编号（MySQL镜自动为你生成，因为我们在列上使用了AUTO_INCREMENT属性）关联不同曲目到一给定专辑，tracks表中的album_id字段匹配专辑表中的一个id。这样要获得给定专辑的所有曲目，你应该用如下查询：
SELECT tracks.num, tracks.name
FROM albums, tracks
WHERE albums.title = 'Billboard Top Hits - 1984'
AND albums.id = tracks.album_id
该结构即灵活又有效。灵活性来自你可以在以后将数据加入系统而不必重新你已完整的工作的事实。例如，如果你想增加每一张专辑的艺术家信息，你可以床架一个artists表，关联到albums表，就像tracks那样。你无需修改现有的结构--只是增加它。
有效性来自于在你的数据中没有明显的数据重复且没有大量的空洞（空单元）的实施。这样MySQL在你的数据库表中既不存储多余的数据，也不比花额外的精力搜索大量空区域。
如果你对关系数据库是新手，规范化你的数据看起来有点奇怪，但在存储和检索数据时，它使MySQL非常有效，并给予你扩展和伸缩你的应用却不必多次重构你的数据库的灵活性。尽可能早的花时间想清楚数据库设计，并考虑你的需求怎样随时间增长，前期花的时间永远是值得的。
复合索引
复合索引（有时称组合索引）是急于多个列的单一索引。MySQL在处理一条查询时每个表只使用一个索引，这意味着如果你有多个经常出现在WHERE子句中的列，你可能要通过创建一个复合索引来加快这些查询。
考虑下列表结构片断：
CREATE TABLE people (
last_name VARCHAR(50) NOT NULL,
first_name VARCHAR(50) NOT NULL,
favorite_color VARCHAR(10) NOT NULL,
.
.
.
);
如果你常常基于last_name和first_name查询表，你可以从last_name和first_name的复合索引中获益：
INDEX last_first (last_name, first_name)
由于MySQL构建复合索引的方式，它可以使用last_first索引来回答基于last_name本身或last_name与first_name两者的索引。这是因为如果列涉及复合索引的“最左前缀”的形式，MySQL将只使用一个复合索引。
所以如果一个复合索引有多个列合成：
INDEX big_index (a, b, c, d, e, f, g, h, i)
MySQL可以用它来回答基于a、或a和b、或a和b和c、或a和b和c和d的查询。但它不能使用big_index处理基于e、或c和f、或g和i的查询，因为这些序列没有一个是从索引的最左边开始的。
复合索引尝被用于加快某些复杂查询，但你需要理解起局限，而且你永远应该进行一些测试，而不是简单地假设这样一个索引将会有帮助。
使用索引加快查询
当MySQL试图回达一条查询时，它查看有关你的数据的各种统计，并决定如何以最快的速度找出你想要的数据。对于前小节的查询，MySQL将读取albums表的所有titles并把它们与“Billboard Top Hits --1984”进行比较看是否匹配。它一旦找到一个匹配还不能停止，因为有相同曲目的专辑不止一个（如你可以有12张CD标有“Greatest Hits”），结果MySQL必须读取表中的每一行。这常称为“全表扫描”且可以避免。
你应该避免全表扫描，因为：
在这里索引可以帮助你，简单地放一个，一个索引允许MySQL很快地确定任何给定值如“Billboard Top Hits -- 1984”是否将匹配表中的任何行。
怎样做到的呢？当你告诉MySQL索引一个特定列时，它在幕后创建另一个数据结构（索引）并用它存储关于被索引列中的值的某些额外信息（被索引的值常称为健码）。这是一种简化，MySQL将所有键码存储在一个树状数据结构中。该数据结构允许MySQL非常快速地找到特定键码。
当MySQL发现列上有一个索引，它将使用索引而不是执行一个全表扫描。这节省了CPU时间（不必读取所有可能的值）和磁盘I/O，而且它改善了并发性，因为MySQL只锁定表足够长的时间来获得所需的行（基于它在索引中找什么）。当你在表中有大量的数据，最终的改善可能非常明显。
对图3的albums表的CREATE TABLE语句的改进：
图3
CREATE TABLE albums (
id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
title VARCHAR(80)NOT NULL,
INDEX title_idx (title)
);
正如你所见的，语句只是简单地在定义后增加了一个INDEX行告诉MySQL在albums表中的title列上创建名为title_idx的索引。你可以给一个表增加多个索引，就像你可在表中有多个列一样。单个索引也可以有多个列合成。
要给现有的表加上一个索引而不是重建表，你可以用ALTER TABLE命令：
ALTER TABLE albums ADD INDEX title_idx (title)
查询处理
如果你的查询复杂，MySQL用于精确确定如何获取数据的原则可能变得难于理解。幸运的是，有几个一般原则和一条命令允许你获得正在做什么的更好的理解。首先，原则是：
如果你怀疑已经发生或只是想理解MySQL怎样处理一条查询，你可以使用EXPLAIN命令。简单地在你的查询前面加上EXPLAIN这个字，并要求MySQL执行它，MySQL不执行查询，相反将报告有助于查询的候选索引列表和所知道的有关它们的一切。
EXPLAIN输出的完整讨论参见MySQL参考手册。
不要过分使用索引
已经知道索引使查询更快，你可能倾向于索引你表中的每个列。但是得益于索引的性能提高是有代价的，在表中每次执行INSERT、UPDATE、REPLACE或DELETE，MySQL不得不更新表上的每个索引以反映变化。
那么你如何确定何时食用它们呢？最常见的答案是“看情况”。它依赖你运行的查询类型和你运行它们的频度，它依赖于你的数据，它依赖于你的期望和需求。你得到了答案 -- 它依赖于很多事情。
在列上有索引的理由是MySQL缩窄其搜索范围以便尽可能会的匹配行（且避免全表扫描）。你可以认为索引是对列中的每个唯一值只包含一项。在索引中，MySQL必须考虑任何重复值，这些重复值稍微降低效率和索引的用途。
所以在索引一个列之前，考虑数据重复的百分比，如果该百分比太高，你可能觉察不到用索引带来的任何性能改善。
要以更简明的术语描述，它清楚地知道在albums表中索引曲目字段，因为有可能有大量不同的值，而且重复非常少。但如果在albums表中有一个分类列，索引它则可能价值不大，一般的CD收集包含多少不同的类型呢？将会有很多重复的类型值。
另一件要考虑的事情是你的查询可能使用的频度。MySQL只能对出现在一条查询种的WHERE子句中的特定列使用索引，试图回答查询：
SELECT * FROM albums WHERE id = 500
MySQL不能使用在title上的查询，该查询要求MySQL基于其id查找记录而不是其title。
如果你很少使用查询中WHERE子句中的一个列，它可能不值得索引该列。可能在极少的情况下容人全表扫描比要求MySQL在每次修改时保持索引更新总体上更有效些。.
有疑问时，进行测试。你总能运行某些到索引或不带索引的基准测试看哪一个更快，只要试图让你的基准测试逼真些。如果你的查询有20%是UPDATE，80%是SLEECT，肯定你的基准测试能发映出来，详见MySQL参考手册。
使用REPLACE查询
有可能你想往表中插入一条记录，除非它已经存在。如果记录已经存在，你想UPDATE它。不是重写代码中做这件事的逻辑，并需运行多个查询，而是MySQL使用REPLACE来做此项工作。
如果id是6的专辑假定有曲目“Shaking the Tree”，你可以这样写查询：
REPLACE INTO albums VALUES (6, 'Shaking the Tree')
重要的是理解REPLACE如何确定一条记录是否在表中存在。MySQL将在表上使用PRIMARY KEY或UNIQUE KEY来执行检查，如果都不存在，REPLACE效果上变成了INSERT。
使用临时表
当工作在非常大的表上时，你可能偶尔需要运行很多查询获得一个大量数据的小的子集，不是对整个表运行这些查询，而是让MySQL每次找出所需的少数记录，将记录选择到一个临时表可能更快些，然后多这些表运行查询。
创建临时表很容易，给正常的CREATE TABLE语句加上TEMPORARY关键字：
CREATE TEMPORARY TABLE tmp_table (
name VARCHAR(10) NOT NULL,
value INTEGER NOT NULL
)
临时表将在你连接MySQL期间存在。当你断开时，MySQL将自动删除表并释放所用的空间。当然你可以在仍然连接的时候删除表并释放空间。
DROP TABLE tmp_table
如果在你创建名为tmp_table临时表时名为tmp_table的表在数据库中已经存在，临时表将有必要屏蔽（隐藏）非临时表tmp_table。
如果你声明临时表是一个HEAP表，MySQL也允许你指定在内存中创建它：
CREATE TEMPORARY TABLE tmp_table (
name VARCHAR(10) NOT NULL,
value INTEGER NOT NULL
) TYPE = HEAP
因为HEAP表存储在内存中，你对它运行的查询可能比磁盘上的临时表快些。然而，HEAP表与一般的表有些不同，且有自身的限制。详见MySQL参考手册。
正如前面的建议，你应该测试临时表看看它们是否真的比对大量数据库运行查询快。如果数据很好地索引，临时表可能一点不快。
临时表在MySQL 3.23.0和更新版才有。
因此，我们决定研究某些方法，你可以用针对优化性能来调节MySQL。在读完本文后，你将理解一些帮助你设计你的MySQL数据库和查询的技术，值得你的应用很有效率。我们将假定你熟悉MySQL和SQL基础，但不假定你有这两方面的广博知识。
只存储你需要的信息
这听上去是常识，但人们常常采取“厨房下水道”的方式进行数据库设计。他们认为可能项要得每样东西都要存储并设计数据库保存所有者这些数据。你需要对你的需求现实些，并确定取确实需要什么信息。你常常能随意产生一些数据而不把它存在数据库表中。在这种情况下，从一个应用开发者的角度看也有道理这样做。
例如，在线目录的产品表可能包含各种产品的名称、介绍、尺寸、重量和价格。除了价格，你可能想存储每个项目相关的税和运输成本。但实际上不必这样做。首先税和运输成本可以方便地（由你的应用或MySQL）计算出来。其次，如果税和运输成本改变了，你可能必须编写必要的查询更新每个产品记录中的税和运输的费率。
有时人们认为这太难不能在以后往数据库表中加入字段，所以他们感觉不得不定义尽可能多的列。这是明显的概念错误。在MySQL中，你可以用ALTER TABLE命令方便地修改表定义以适应你改变的需求。
例如，如果你突然认识到你需要给你的产品表增加一个级别列（可能你想允许用户在你的目录中给产品评级），你可以这样做：
ALTER TABLE products ADD rank INTEGER
这给你的产品表增加了一个整数类型的级别列，你能用ALTER TABLE做什么的完整介绍参见MySQL手册。
只要求你需要的东西--要清晰
就像说“只存储你需要的东西”那样，这可能看来是常识，但这一点常常被忽视，为什么呢？因为在一个应用开发时，需求经常改变，所以很多查询最终看来是这样：
SELECT * FROM sometable
当你不能肯定你将需要哪一列时，要求所有列明显是最省力的事情，然而随着你的表不断增大和修改，这可能变成一个性能问题。最好是在你的最初开发完成后再花些时间并确定你真正从你的查询中需要什么：
SELECT name, rank, description FROM products
这带来了一个相关的观点，即代码维护比性能更重要。大多数变成语言（Perl、Python、PHP、Java等）允许通过字段名和数字编号访问一条查询的结果，这意味着你可以访问命名字段或字段０都可以得到相同的数据。
长期看，最好使用列名而不是其编号位置，为什么？因为一个表中或一条查询中地列的相对位置可以改变。它们在表中可能因为重复使用ALTER TABLE而改变，它们在查询中将因重写了查询而忘记更新应用逻辑来匹配而改变。
当然，你仍然需要小心改变列名！但如果你使用列名而非标号位置，如列名改变，你可以用grep搜索源代码或使用编辑器的搜索能力查找你需要修改的代码。
规范化你的表结构
如果你以前从未听说过“数据规范化”，不要害怕。规范化可能是一个复杂的专题，你可以从只理解最基本的规范化概念中正真正获益。
理解它的最容易的方法是认为你的表是一个电子报表。如果你想以一个报表跟踪你的CD收藏，你可以如图１种那样进行设计：
图１
引用
album track1 track2 track10
----- ------ ------ -------
Billboard Top Hits - 1984 Loverboy Shout St. Elmo's Fire
(Billy Ocean) (Tears for Fears) (John Parr)
这看上去很合理。大多数CD只有10首曲子，对否？不尽然。如果你拥有一张有100首曲子的CD且几张超过20首改怎么办。这意味着用这种方法，在极端的情况下，你将需要一个非常宽的表格（或一个超过100个字段的表）来保存所有的数据。
规范化表结构的目标是使“空单元”的数量最少，在上述CD表的情况下，如果你允许CD可能包含100首曲子，你会有很多这样的空单元。不管你何时处理可能扩展到类似该CD表那样数量的字段列表，它是你需要将你的数据分割成2个或更多表的标志，然后你一起访问并获得你需要的数据。
很多关系数据库的新手不真正知道关系数据库管理系统中关系是什么。简单地说，就像一组信息存在可以基于共性数据联结（JOIN）在一起的不同表中，很不幸，这听上去更学术化和含糊，但CD数据库提出了一个具体情况，我们可以研究如何规范数据。
每个CD列表有一个固定的属性（标题、艺术家、年份、分类）集和一个不定的属性（曲目表）集的理解给了我们一些如何分成成能相互关联的表的思路。
你可以创建一个所有专辑及其固定属性的表，另一个包含这些专辑的所有曲目的表。这样不是水平思考（像表格），你垂直思考--就好像你创建列表而不是行--并建立一个如图2的表结构：
点击查看大图
专辑的编号（MySQL镜自动为你生成，因为我们在列上使用了AUTO_INCREMENT属性）关联不同曲目到一给定专辑，tracks表中的album_id字段匹配专辑表中的一个id。这样要获得给定专辑的所有曲目，你应该用如下查询：
SELECT tracks.num, tracks.name
FROM albums, tracks
WHERE albums.title = 'Billboard Top Hits - 1984'
AND albums.id = tracks.album_id
该结构即灵活又有效。灵活性来自你可以在以后将数据加入系统而不必重新你已完整的工作的事实。例如，如果你想增加每一张专辑的艺术家信息，你可以床架一个artists表，关联到albums表，就像tracks那样。你无需修改现有的结构--只是增加它。
有效性来自于在你的数据中没有明显的数据重复且没有大量的空洞（空单元）的实施。这样MySQL在你的数据库表中既不存储多余的数据，也不比花额外的精力搜索大量空区域。
如果你对关系数据库是新手，规范化你的数据看起来有点奇怪，但在存储和检索数据时，它使MySQL非常有效，并给予你扩展和伸缩你的应用却不必多次重构你的数据库的灵活性。尽可能早的花时间想清楚数据库设计，并考虑你的需求怎样随时间增长，前期花的时间永远是值得的。
复合索引
复合索引（有时称组合索引）是急于多个列的单一索引。MySQL在处理一条查询时每个表只使用一个索引，这意味着如果你有多个经常出现在WHERE子句中的列，你可能要通过创建一个复合索引来加快这些查询。
考虑下列表结构片断：
CREATE TABLE people (
last_name VARCHAR(50) NOT NULL,
first_name VARCHAR(50) NOT NULL,
favorite_color VARCHAR(10) NOT NULL,
.
.
.
);
如果你常常基于last_name和first_name查询表，你可以从last_name和first_name的复合索引中获益：
INDEX last_first (last_name, first_name)
由于MySQL构建复合索引的方式，它可以使用last_first索引来回答基于last_name本身或last_name与first_name两者的索引。这是因为如果列涉及复合索引的“最左前缀”的形式，MySQL将只使用一个复合索引。
所以如果一个复合索引有多个列合成：
INDEX big_index (a, b, c, d, e, f, g, h, i)
MySQL可以用它来回答基于a、或a和b、或a和b和c、或a和b和c和d的查询。但它不能使用big_index处理基于e、或c和f、或g和i的查询，因为这些序列没有一个是从索引的最左边开始的。
复合索引尝被用于加快某些复杂查询，但你需要理解起局限，而且你永远应该进行一些测试，而不是简单地假设这样一个索引将会有帮助。
使用索引加快查询
当MySQL试图回达一条查询时，它查看有关你的数据的各种统计，并决定如何以最快的速度找出你想要的数据。对于前小节的查询，MySQL将读取albums表的所有titles并把它们与“Billboard Top Hits --1984”进行比较看是否匹配。它一旦找到一个匹配还不能停止，因为有相同曲目的专辑不止一个（如你可以有12张CD标有“Greatest Hits”），结果MySQL必须读取表中的每一行。这常称为“全表扫描”且可以避免。
你应该避免全表扫描，因为：
引用
CPU开销：如果你没有很多专辑，检查所有这些标题的处理相对快些。但如果你需要在你的数据库中存储很多专辑呢？你有的专辑越多，花的时间越长。在专辑数量或检查它们所花的时间时间存在一种线性关系。
并发性：在MySQL正在从表中读取数据时，它锁定表使得没有其他人可以写入，但可以读取。当MySQL更新或删除表中的行时，它锁定表使得没有其他人可以从它读取。
磁盘开销：在一个大数据表上，一次全表扫描将消耗大量磁盘I/O。这可能明显地减慢你的数据库服务器 -- 特别是如果你的服务器是较慢的IDE驱动器。
最好是让全表扫描将到最少 -- 特别是你的应用需要以规模或用户数伸缩。MySQL最新版确实有几个并发性方面的改善（BDB、InnoDB和Gemini表类型）。
并发性：在MySQL正在从表中读取数据时，它锁定表使得没有其他人可以写入，但可以读取。当MySQL更新或删除表中的行时，它锁定表使得没有其他人可以从它读取。
磁盘开销：在一个大数据表上，一次全表扫描将消耗大量磁盘I/O。这可能明显地减慢你的数据库服务器 -- 特别是如果你的服务器是较慢的IDE驱动器。
最好是让全表扫描将到最少 -- 特别是你的应用需要以规模或用户数伸缩。MySQL最新版确实有几个并发性方面的改善（BDB、InnoDB和Gemini表类型）。
在这里索引可以帮助你，简单地放一个，一个索引允许MySQL很快地确定任何给定值如“Billboard Top Hits -- 1984”是否将匹配表中的任何行。
怎样做到的呢？当你告诉MySQL索引一个特定列时，它在幕后创建另一个数据结构（索引）并用它存储关于被索引列中的值的某些额外信息（被索引的值常称为健码）。这是一种简化，MySQL将所有键码存储在一个树状数据结构中。该数据结构允许MySQL非常快速地找到特定键码。
当MySQL发现列上有一个索引，它将使用索引而不是执行一个全表扫描。这节省了CPU时间（不必读取所有可能的值）和磁盘I/O，而且它改善了并发性，因为MySQL只锁定表足够长的时间来获得所需的行（基于它在索引中找什么）。当你在表中有大量的数据，最终的改善可能非常明显。
对图3的albums表的CREATE TABLE语句的改进：
图3
CREATE TABLE albums (
id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
title VARCHAR(80)NOT NULL,
INDEX title_idx (title)
);
正如你所见的，语句只是简单地在定义后增加了一个INDEX行告诉MySQL在albums表中的title列上创建名为title_idx的索引。你可以给一个表增加多个索引，就像你可在表中有多个列一样。单个索引也可以有多个列合成。
要给现有的表加上一个索引而不是重建表，你可以用ALTER TABLE命令：
ALTER TABLE albums ADD INDEX title_idx (title)
查询处理
如果你的查询复杂，MySQL用于精确确定如何获取数据的原则可能变得难于理解。幸运的是，有几个一般原则和一条命令允许你获得正在做什么的更好的理解。首先，原则是：
引用
如果MySQL确定了简单地扫描全表更快些，则它L将不使用索引。一般地，如果一个索引告诉MySQL访问表中大概30%的行，它放弃索引并简单地执行全表扫描。
如果多索引可以用来满足查询，MySQL将使用最严格的一个 -- 即导致最少的行被提取的那个。
如果你正在选择的列是一个索引的所有部分，MySQL可以直接从索引中读取锁需的数据，绝不接触（或锁定）表本身。
当联结几个表时，MySQL将首先从可能返回最少行的表中读取数据。你指定表的次序可能与MySQL使用它们的次序不同，这也影响到最终返回给你的行的次序，所以如果你需要行以特定的次序出现，要保证在你的查询中使用一个ORDER子句。
已经说了很多了，重要的是认识到MySQL所做的一些决策实际上是基于猜测，就像人类进行大量猜测一样，偶尔也会出错。
如果多索引可以用来满足查询，MySQL将使用最严格的一个 -- 即导致最少的行被提取的那个。
如果你正在选择的列是一个索引的所有部分，MySQL可以直接从索引中读取锁需的数据，绝不接触（或锁定）表本身。
当联结几个表时，MySQL将首先从可能返回最少行的表中读取数据。你指定表的次序可能与MySQL使用它们的次序不同，这也影响到最终返回给你的行的次序，所以如果你需要行以特定的次序出现，要保证在你的查询中使用一个ORDER子句。
已经说了很多了，重要的是认识到MySQL所做的一些决策实际上是基于猜测，就像人类进行大量猜测一样，偶尔也会出错。
如果你怀疑已经发生或只是想理解MySQL怎样处理一条查询，你可以使用EXPLAIN命令。简单地在你的查询前面加上EXPLAIN这个字，并要求MySQL执行它，MySQL不执行查询，相反将报告有助于查询的候选索引列表和所知道的有关它们的一切。
EXPLAIN输出的完整讨论参见MySQL参考手册。
不要过分使用索引
已经知道索引使查询更快，你可能倾向于索引你表中的每个列。但是得益于索引的性能提高是有代价的，在表中每次执行INSERT、UPDATE、REPLACE或DELETE，MySQL不得不更新表上的每个索引以反映变化。
那么你如何确定何时食用它们呢？最常见的答案是“看情况”。它依赖你运行的查询类型和你运行它们的频度，它依赖于你的数据，它依赖于你的期望和需求。你得到了答案 -- 它依赖于很多事情。
在列上有索引的理由是MySQL缩窄其搜索范围以便尽可能会的匹配行（且避免全表扫描）。你可以认为索引是对列中的每个唯一值只包含一项。在索引中，MySQL必须考虑任何重复值，这些重复值稍微降低效率和索引的用途。
所以在索引一个列之前，考虑数据重复的百分比，如果该百分比太高，你可能觉察不到用索引带来的任何性能改善。
要以更简明的术语描述，它清楚地知道在albums表中索引曲目字段，因为有可能有大量不同的值，而且重复非常少。但如果在albums表中有一个分类列，索引它则可能价值不大，一般的CD收集包含多少不同的类型呢？将会有很多重复的类型值。
另一件要考虑的事情是你的查询可能使用的频度。MySQL只能对出现在一条查询种的WHERE子句中的特定列使用索引，试图回答查询：
SELECT * FROM albums WHERE id = 500
MySQL不能使用在title上的查询，该查询要求MySQL基于其id查找记录而不是其title。
如果你很少使用查询中WHERE子句中的一个列，它可能不值得索引该列。可能在极少的情况下容人全表扫描比要求MySQL在每次修改时保持索引更新总体上更有效些。.
有疑问时，进行测试。你总能运行某些到索引或不带索引的基准测试看哪一个更快，只要试图让你的基准测试逼真些。如果你的查询有20%是UPDATE，80%是SLEECT，肯定你的基准测试能发映出来，详见MySQL参考手册。
使用REPLACE查询
有可能你想往表中插入一条记录，除非它已经存在。如果记录已经存在，你想UPDATE它。不是重写代码中做这件事的逻辑，并需运行多个查询，而是MySQL使用REPLACE来做此项工作。
如果id是6的专辑假定有曲目“Shaking the Tree”，你可以这样写查询：
REPLACE INTO albums VALUES (6, 'Shaking the Tree')
重要的是理解REPLACE如何确定一条记录是否在表中存在。MySQL将在表上使用PRIMARY KEY或UNIQUE KEY来执行检查，如果都不存在，REPLACE效果上变成了INSERT。
使用临时表
当工作在非常大的表上时，你可能偶尔需要运行很多查询获得一个大量数据的小的子集，不是对整个表运行这些查询，而是让MySQL每次找出所需的少数记录，将记录选择到一个临时表可能更快些，然后多这些表运行查询。
创建临时表很容易，给正常的CREATE TABLE语句加上TEMPORARY关键字：
CREATE TEMPORARY TABLE tmp_table (
name VARCHAR(10) NOT NULL,
value INTEGER NOT NULL
)
临时表将在你连接MySQL期间存在。当你断开时，MySQL将自动删除表并释放所用的空间。当然你可以在仍然连接的时候删除表并释放空间。
DROP TABLE tmp_table
如果在你创建名为tmp_table临时表时名为tmp_table的表在数据库中已经存在，临时表将有必要屏蔽（隐藏）非临时表tmp_table。
如果你声明临时表是一个HEAP表，MySQL也允许你指定在内存中创建它：
CREATE TEMPORARY TABLE tmp_table (
name VARCHAR(10) NOT NULL,
value INTEGER NOT NULL
) TYPE = HEAP
因为HEAP表存储在内存中，你对它运行的查询可能比磁盘上的临时表快些。然而，HEAP表与一般的表有些不同，且有自身的限制。详见MySQL参考手册。
正如前面的建议，你应该测试临时表看看它们是否真的比对大量数据库运行查询快。如果数据很好地索引，临时表可能一点不快。
临时表在MySQL 3.23.0和更新版才有。
存储引擎是什么？
MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。
通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。
例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)。
这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型)。MySQL默认配置了许多不同的存储引擎，可以预先设置或者在MySQL服务器中启用。你可以选择适用于服务器、数据库和表格的存储引擎，以便在选择如何存储你的信息、如何检索这些信息以及你需要你的数据结合什么性能和功能的时候为你提供最大的灵活性。
选择如何存储和检索你的数据的这种灵活性是MySQL为什么如此受欢迎的主要原因。其它数据库系统(包括大多数商业选择)仅支持一种类型的数据存储。遗憾的是，其它类型的数据库解决方案采取的“一个尺码满足一切需求”的方式意味着你要么就牺牲一些性能，要么你就用几个小时甚至几天的时间详细调整你的数据库。使用MySQL，我们仅需要修改我们使用的存储引擎就可以了。
在这篇文章中，我们不准备集中讨论不同的存储引擎的技术方面的问题(尽管我们不可避免地要研究这些因素的某些方面)，相反，我们将集中介绍这些不同的引擎分别最适应哪种需求和如何启用不同的存储引擎。为了实现这个目的，在介绍每一个存储引擎的具体情况之前，我们必须要了解一些基本的问题。
如何确定有哪些存储引擎可用
你可以在MySQL(假设是MySQL服务器4.1.2以上版本)中使用显示引擎的命令得到一个可用引擎的列表。
mysql> show engines;
+------------+---------+------------------------------------------------------------+
| Engine | Support | Comment |
+------------+---------+------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| HEAP | YES | Alias for MEMORY |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| MRG_MYISAM | YES | Alias for MERGE |
| ISAM | NO | Obsolete storage engine, now replaced by MyISAM |
| MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| INNOBASE | YES | Alias for INNODB |
| BDB | NO | Supports transactions and page-level locking |
| BERKELEYDB | NO | Alias for BDB |
| NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables |
| NDB | NO | Alias for NDBCLUSTER |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | NO | Archive storage engine |
| CSV | NO | CSV storage engine |
+------------+---------+------------------------------------------------------------+
16 rows in set (0.01 sec)这个表格显示了可用的数据库引擎的全部名单以及在当前的数据库服务器中是否支持这些引擎。
对于MySQL 4.1.2以前版本，可以使用mysql> show variables like "have_%"(显示类似“have_%”的变量):
mysql> show variables like "have_%";
+------------------+----------+
| Variable_name | Value |
+------------------+----------+
| have_bdb | YES |
| have_crypt | YES |
| have_innodb | DISABLED |
| have_isam | YES |
| have_raid | YES |
| have_symlink | YES |
| have_openssl | YES |
| have_query_cache | YES |
+------------------+----------+
8 rows in set (0.01 sec)
你可以通过修改设置脚本中的选项来设置在MySQL安装软件中可用的引擎。如果你在使用一个预先包装好的MySQL二进制发布版软件，那么，这个软件就包含了常用的引擎。然而，需要指出的是，如果你要使用某些不常用的引擎，特别是CSV、RCHIVE(存档)和BLACKHOLE(黑洞)引擎，你就需要手工重新编译MySQL源码 。
使用一个指定的存储引擎
你可以使用很多方法指定一个要使用的存储引擎。最简单的方法是，如果你喜欢一种能满足你的大多数数据库需求的存储引擎，你可以在MySQL设置文件中设置一个默认的引擎类型（使用storage_engine 选项）或者在启动数据库服务器时在命令行后面加上--default-storage -engine或--default-table-type选项 。
更灵活的方式是在随MySQL服务器发布同时提供的MySQL客户端时指定使用的存储引擎。最直接的方式是在创建表时指定存储引擎的类型，向下面这样:
CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB
你还可以改变现有的表使用的存储引擎，用以下语句:
ALTER TABLE mytable ENGINE = MyISAM
然而，你在以这种方式修改表格类型的时候需要非常仔细，因为对不支持同样的索引、字段类型或者表大小的一个类型进行修改可能使你丢失数据。如果你指定一个在你的当前的数据库中不存在的一个存储引擎，那么就会创建一个MyISAM(默认的)类型的表。
各存储引擎之间的区别
为了做出选择哪一个存储引擎的决定，我们首先需要考虑每一个存储引擎提供了哪些不同的核心功能。这种功能使我们能够把不同的存储引擎区别开来。我们一般把这些核心功能分为四类:支持的字段和数据类型、锁定类型、索引和处理。一些引擎具有能过促使你做出决定的独特的功能，我们一会儿再仔细研究这些具体问题。
字段和数据类型
虽然所有这些引擎都支持通用的数据类型，例如整型、实型和字符型等，但是，并不是所有的引擎都支持其它的字段类型，特别是blog（二进制大对象）或者text文本类型。其它引擎也许仅支持有限的字符宽度和数据大小。
这些局限性可能直接影响到你可以存储的数据，同时也可能会对你实施的搜索的类型或者你对那些信息创建的索引产生间接的影响。这些区别能够影响你的应用程序的性能和功能，因为你必须要根据你要存储的数据类型选择对需要的存储引擎的功能做出决策。
锁定
数据库引擎中的锁定功能决定了如何管理信息的访问和更新。当数据库中的一个对象为信息更新锁定了，在更新完成之前，其它处理不能修改这个数据(在某些情况下还不允许读这种数据)。
锁定不仅影响许多不同的应用程序如何更新数据库中的信息，而且还影响对那个数据的查询。这是因为查询可能要访问正在被修改或者更新的数据。总的来说，这种延迟是很小的。大多数锁定机制主要是为了防止多个处理更新同一个数据。由于向数据中插入信息和更新信息这两种情况都需要锁定，你可以想象，多个应用程序使用同一个数据库可能会有很大的影响。
不同的存储引擎在不同的对象级别支持锁定，而且这些级别将影响可以同时访问的信息。得到支持的级别有三种:表锁定、块锁定和行锁定。支持最多的是表锁定，这种锁定是在myisam中提供的。在数据更新时，它锁定了整个表。这就防止了许多应用程序同时更新一个具体的表。这对应用很多的多用户数据库有很大的影响，因为它延迟了更新的过程。
页级锁定使用berkeleydb引擎，并且根据上载的信息页(8kb)锁定数据。当在数据库的很多地方进行更新的时候，这种锁定不会出现什么问题。但是，由于增加几行信息就要锁定数据结构的最后8kb，当需要增加大量的行，也别是大量的小型数据，就会带来问题。
行级锁定提供了最佳的并行访问功能，一个表中只有一行数据被锁定。这就意味着很多应用程序能够更新同一个表中的不同行的数据，而不会引起锁定的问题。只有innodb存储引擎支持行级锁定。
建立索引
建立索引在搜索和恢复数据库中的数据的时候能够显著提高性能。不同的存储引擎提供不同的制作索引的技术。有些技术也许会更适合你存储的数据类型。
有些存储引擎根本就不支持索引，其原因可能是它们使用基本表索引(如merge引擎)或者是因为数据存储的方式不允许索引(例如federated或者blackhole引擎)。
事务处理
事务处理功能通过提供在向表中更新和插入信息期间的可靠性。这种可靠性是通过如下方法实现的，它允许你更新表中的数据，但仅当应用的应用程序的所有相关操作完全完成后才接受你对表的更改。例如，在会计处理中每一笔会计分录处理将包括对借方科目和贷方科目数据的更改，你需要要使用事务处理功能保证对借方科目和贷方科目的数据更改都顺利完成，才接受所做的修改。如果任一项操作失败了，你都可以取消这个事务处理，这些修改就不存在了。如果这个事务处理过程完成了，我们可以通过允许这个修改来确认这个操作。
MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。
通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。
例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)。
这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型)。MySQL默认配置了许多不同的存储引擎，可以预先设置或者在MySQL服务器中启用。你可以选择适用于服务器、数据库和表格的存储引擎，以便在选择如何存储你的信息、如何检索这些信息以及你需要你的数据结合什么性能和功能的时候为你提供最大的灵活性。
选择如何存储和检索你的数据的这种灵活性是MySQL为什么如此受欢迎的主要原因。其它数据库系统(包括大多数商业选择)仅支持一种类型的数据存储。遗憾的是，其它类型的数据库解决方案采取的“一个尺码满足一切需求”的方式意味着你要么就牺牲一些性能，要么你就用几个小时甚至几天的时间详细调整你的数据库。使用MySQL，我们仅需要修改我们使用的存储引擎就可以了。
在这篇文章中，我们不准备集中讨论不同的存储引擎的技术方面的问题(尽管我们不可避免地要研究这些因素的某些方面)，相反，我们将集中介绍这些不同的引擎分别最适应哪种需求和如何启用不同的存储引擎。为了实现这个目的，在介绍每一个存储引擎的具体情况之前，我们必须要了解一些基本的问题。
如何确定有哪些存储引擎可用
你可以在MySQL(假设是MySQL服务器4.1.2以上版本)中使用显示引擎的命令得到一个可用引擎的列表。
mysql> show engines;
+------------+---------+------------------------------------------------------------+
| Engine | Support | Comment |
+------------+---------+------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| HEAP | YES | Alias for MEMORY |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| MRG_MYISAM | YES | Alias for MERGE |
| ISAM | NO | Obsolete storage engine, now replaced by MyISAM |
| MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| INNOBASE | YES | Alias for INNODB |
| BDB | NO | Supports transactions and page-level locking |
| BERKELEYDB | NO | Alias for BDB |
| NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables |
| NDB | NO | Alias for NDBCLUSTER |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | NO | Archive storage engine |
| CSV | NO | CSV storage engine |
+------------+---------+------------------------------------------------------------+
16 rows in set (0.01 sec)这个表格显示了可用的数据库引擎的全部名单以及在当前的数据库服务器中是否支持这些引擎。
对于MySQL 4.1.2以前版本，可以使用mysql> show variables like "have_%"(显示类似“have_%”的变量):
mysql> show variables like "have_%";
+------------------+----------+
| Variable_name | Value |
+------------------+----------+
| have_bdb | YES |
| have_crypt | YES |
| have_innodb | DISABLED |
| have_isam | YES |
| have_raid | YES |
| have_symlink | YES |
| have_openssl | YES |
| have_query_cache | YES |
+------------------+----------+
8 rows in set (0.01 sec)
你可以通过修改设置脚本中的选项来设置在MySQL安装软件中可用的引擎。如果你在使用一个预先包装好的MySQL二进制发布版软件，那么，这个软件就包含了常用的引擎。然而，需要指出的是，如果你要使用某些不常用的引擎，特别是CSV、RCHIVE(存档)和BLACKHOLE(黑洞)引擎，你就需要手工重新编译MySQL源码 。
使用一个指定的存储引擎
你可以使用很多方法指定一个要使用的存储引擎。最简单的方法是，如果你喜欢一种能满足你的大多数数据库需求的存储引擎，你可以在MySQL设置文件中设置一个默认的引擎类型（使用storage_engine 选项）或者在启动数据库服务器时在命令行后面加上--default-storage -engine或--default-table-type选项 。
更灵活的方式是在随MySQL服务器发布同时提供的MySQL客户端时指定使用的存储引擎。最直接的方式是在创建表时指定存储引擎的类型，向下面这样:
CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB
你还可以改变现有的表使用的存储引擎，用以下语句:
ALTER TABLE mytable ENGINE = MyISAM
然而，你在以这种方式修改表格类型的时候需要非常仔细，因为对不支持同样的索引、字段类型或者表大小的一个类型进行修改可能使你丢失数据。如果你指定一个在你的当前的数据库中不存在的一个存储引擎，那么就会创建一个MyISAM(默认的)类型的表。
各存储引擎之间的区别
为了做出选择哪一个存储引擎的决定，我们首先需要考虑每一个存储引擎提供了哪些不同的核心功能。这种功能使我们能够把不同的存储引擎区别开来。我们一般把这些核心功能分为四类:支持的字段和数据类型、锁定类型、索引和处理。一些引擎具有能过促使你做出决定的独特的功能，我们一会儿再仔细研究这些具体问题。
字段和数据类型
虽然所有这些引擎都支持通用的数据类型，例如整型、实型和字符型等，但是，并不是所有的引擎都支持其它的字段类型，特别是blog（二进制大对象）或者text文本类型。其它引擎也许仅支持有限的字符宽度和数据大小。
这些局限性可能直接影响到你可以存储的数据，同时也可能会对你实施的搜索的类型或者你对那些信息创建的索引产生间接的影响。这些区别能够影响你的应用程序的性能和功能，因为你必须要根据你要存储的数据类型选择对需要的存储引擎的功能做出决策。
锁定
数据库引擎中的锁定功能决定了如何管理信息的访问和更新。当数据库中的一个对象为信息更新锁定了，在更新完成之前，其它处理不能修改这个数据(在某些情况下还不允许读这种数据)。
锁定不仅影响许多不同的应用程序如何更新数据库中的信息，而且还影响对那个数据的查询。这是因为查询可能要访问正在被修改或者更新的数据。总的来说，这种延迟是很小的。大多数锁定机制主要是为了防止多个处理更新同一个数据。由于向数据中插入信息和更新信息这两种情况都需要锁定，你可以想象，多个应用程序使用同一个数据库可能会有很大的影响。
不同的存储引擎在不同的对象级别支持锁定，而且这些级别将影响可以同时访问的信息。得到支持的级别有三种:表锁定、块锁定和行锁定。支持最多的是表锁定，这种锁定是在myisam中提供的。在数据更新时，它锁定了整个表。这就防止了许多应用程序同时更新一个具体的表。这对应用很多的多用户数据库有很大的影响，因为它延迟了更新的过程。
页级锁定使用berkeleydb引擎，并且根据上载的信息页(8kb)锁定数据。当在数据库的很多地方进行更新的时候，这种锁定不会出现什么问题。但是，由于增加几行信息就要锁定数据结构的最后8kb，当需要增加大量的行，也别是大量的小型数据，就会带来问题。
行级锁定提供了最佳的并行访问功能，一个表中只有一行数据被锁定。这就意味着很多应用程序能够更新同一个表中的不同行的数据，而不会引起锁定的问题。只有innodb存储引擎支持行级锁定。
建立索引
建立索引在搜索和恢复数据库中的数据的时候能够显著提高性能。不同的存储引擎提供不同的制作索引的技术。有些技术也许会更适合你存储的数据类型。
有些存储引擎根本就不支持索引，其原因可能是它们使用基本表索引(如merge引擎)或者是因为数据存储的方式不允许索引(例如federated或者blackhole引擎)。
事务处理
事务处理功能通过提供在向表中更新和插入信息期间的可靠性。这种可靠性是通过如下方法实现的，它允许你更新表中的数据，但仅当应用的应用程序的所有相关操作完全完成后才接受你对表的更改。例如，在会计处理中每一笔会计分录处理将包括对借方科目和贷方科目数据的更改，你需要要使用事务处理功能保证对借方科目和贷方科目的数据更改都顺利完成，才接受所做的修改。如果任一项操作失败了，你都可以取消这个事务处理，这些修改就不存在了。如果这个事务处理过程完成了，我们可以通过允许这个修改来确认这个操作。
1、Pixelgirl
提供免费的图标，PC壁纸以及iPhone的壁纸。
2、Dual Screen Wallpapers
这个网站的壁纸都非常虚幻，而且大多数为宽屏壁纸。使用宽屏的朋友不妨一试。
3、Veer's collection of desktop wallpapers
提供一些具有艺术气味的壁纸下载。像素囊括800*600到1920*1200。
4、collection of photos taken for Windows Vista's default wallpaper selection
很漂亮的风景照，用来当壁纸最好不过。
5、InterfaceLIFT
这是一个十分值得推荐的壁纸资源，因为它的壁纸几乎囊括了所有的像素，从iPhone或PSP到超大宽屏（2560*1600）。
6、exljbris
精选一些漂亮的字体供免费下载。
7、TypeNow.net's collection of free themed fonts
超过300种字体供下载了。
8、Fonts 500
看名字可能都已经能猜到，提供500种字体下载。
9、free-icons.jonasjohn.de
将一些日常生活种的物品制作成背景透明的图标，相当不错。（似乎连不上）
10、Crystal Clear icon set
wiki下属站点，提供超多图标下载。看下图：
提供免费的图标，PC壁纸以及iPhone的壁纸。
2、Dual Screen Wallpapers
这个网站的壁纸都非常虚幻，而且大多数为宽屏壁纸。使用宽屏的朋友不妨一试。
3、Veer's collection of desktop wallpapers
提供一些具有艺术气味的壁纸下载。像素囊括800*600到1920*1200。
4、collection of photos taken for Windows Vista's default wallpaper selection
很漂亮的风景照，用来当壁纸最好不过。
5、InterfaceLIFT
这是一个十分值得推荐的壁纸资源，因为它的壁纸几乎囊括了所有的像素，从iPhone或PSP到超大宽屏（2560*1600）。
6、exljbris
精选一些漂亮的字体供免费下载。
7、TypeNow.net's collection of free themed fonts
超过300种字体供下载了。
8、Fonts 500
看名字可能都已经能猜到，提供500种字体下载。
9、free-icons.jonasjohn.de
将一些日常生活种的物品制作成背景透明的图标，相当不错。（似乎连不上）
10、Crystal Clear icon set
wiki下属站点，提供超多图标下载。看下图：
MySQL数据库的表是一个二维表，由一个或多个数据列构成。
每个数据列都有它的特定类型，该类型决定了MySQL如何看待该列数据，我们可以把整型数值存放到字符类型的列中，MySQL则会把它看成字符串来处理。
MySQL中的列类型有三种：数值类、字符串类和日期/时间类。
从大类来看列类型和数值类型一样，都是只有三种。但每种列类型都还可细分。
下面对各种列类型进行详细介绍。
数值类的数据列类型
数值型的列类型包括整型和浮点型两大类。
TINYINT：1字节 非常小的正整数，带符号：-128~127，不带符号：0~255
SMALLINT：2字节 小整数，带符号：-32768~32767，不带符号：0~65535
MEDIUMINT：3字节 中等大小的整数，带符号：-8388608~8388607，不带符号：0~16777215
INT：4字节 标准整数，带符号：-2147483648~2147483647，不带符号：0~4294967295
BIGINT：8字节 大整数，带符号：-9223372036854775808~9233372036854775807，不带符号：0~18446744073709551615
FLOAT：4字节 单精度浮点数，最小非零值：+-1.175494351E-38，最大非零值：+-3.402823466E+38
DOUBLE：8字节 双精度浮点数，最小非零值：+-2.2250738585072014E-308，最大非零值：+-1.7976931348623157E+308
DECIMAL：M+2字节 以字符串形式表示的浮点数，它的取值范围可变，由M和D的值决定。
整型数据列类型
MySQL有五种整型数据列类型，即TINYINT，SMALLINT，MEDIUMINT，INT和BIGINT。它们之间的区别是取值范围不同，存储空间也各不相同。
在整型数据列后加上UNSIGNED属性可以禁止负数，取值从0开始。
声明整型数据列时，我们可以为它指定个显示宽度M(1~255)，如INT(5)，指定显示宽度为5个字符,如果没有给它指定显示宽度，MySQL会为它指定一个默认值。显示宽度只用于显示，并不能限制取值范围和占用空间，如：INT(3)会占用4个字节的存储空间，并且允许的最大值也不会是999,而是INT整型所允许的最大值。
浮点型数据列类型
MySQL有三种浮点型数据列类型，分别是：FLOAT，DOUBLE和DECIMAL。
浮点类数据类型有一个最大可表示值和一个最小非零可表示值，最小非零可表示值决定了该类型的精确度。
MySQL 4.0.2版之后，FLOAT和DOUBLE都可以指定UNSIGNED属性。当指定该属性时，取值范围不平移到正数区间，而只是简单地把浮点类型的负数部份去掉。
浮点类型也有M(1~255)和D(1~30，且不能大于M-2)。分别表示显示宽度和小数位数。M和D在FLOAT和DOUBLE中是可选的，默认，当MySQL版本大于3.23.6时，FLOAT和DOUBLE类型将被保存为硬件所支持的最大精度。DECIMAL的M和D值在MySQL3.23.6后可选，默认D值为0,M值为10。
如何选择数值类数据列类型？
为了节省存储空间和提高数据库处理效率，我们应根据应用数据的取值范围来选择一个最适合的数据列类型。如果把一个超出数据列取值范围的数存入该列，则MySQL就会截短该值，如：我们把99999存入SMALLINT(3)数据列里，因为SMALLINT(3)的取值范围是-32768~32767，所以就会被截短成32767存储。显示宽度3不会影响数值的存储。只影响显示。
对于浮点数据列，存入的数值会被该列定义的小数位进行四舍五入。如把一个1.234存入FLOAT(6.1)数据列中，结果是1.2。
DECIMAL与FLOAT和DOUBLE的区别是：DECIMAL类型的值是以字符串的形式被储存起来的，它的小数位数是固定的。它的优点是，不会象FLOAT和DOUBLE类型数据列那样进行四舍五入而产生误差，所以很适合用于财务计算；而它的缺点是：由于它的存储格式不同，CPU不能对它进行直接运算，从而影响运算效率。DECIMAL(M，D)总共要占用M+2个字节。
数值类数据列的属性
ZEROFILL属性适用于所有数值类数据列类型，作用是，如果数值的宽度小于定义的显示宽度，则在数值前填充0。
UNSIGNED属性不允许数据列出现负数。
AUTO_INCREMENT属性可生成独一无二的数字序列。只对整数类的数据列有效。
NULL和NOT NULL属性设置数据列是否可为空。
DEFAULT属性可为数据列指定默认值。
//////////////////////////////////////////////////////
字符串类数据列类型
字符串可以用来表示任何一种值，所以它是最基本的类型之一。
我们可以用字符串类型来存储图象或声音之类的二进制数据，也可存储用gzip压缩的数据。
下表介绍了各种字符串类型：
CHAR[(M)] M字节 M字节
VARCHAR[(M)] M字节 L+1字节
TINYBLOD，TINYTEXT 2^8-1字节 L+1字节
BLOB，TEXT 2^16-1字节 L+2
MEDIUMBLOB，MEDIUMTEXT 2^24-1字节 L+3
LONGBLOB，LONGTEXT 2^32-1字节 L+4
ENUM('value1','value2',...) 65535个成员 1或2字节
SET('value1','value2',...) 64个成员 1,2,3,4或8字节
L+1、L+2是表示数据列是可变长度的，它占用的空间会根据数据行的增减面则改变。数据行的总长度取决于存放在这些数据列里的数据值的长度。L+1或L+2里多出来的字节是用来保存数据值的长度的。在对长度可变的数据进行处理时，MySQL要把数据内容和数据长度都保存起来。
如果把超出字符串最大长度的数据放到字符类数据列中，MySQL会自动进行截短处理。
ENUM和SET类型的数据列定义里有一个列表，列表里的元素就是该数据列的合法取值。如果试图把一个没有在列表里的值放到数据列里，它会被转换为空字符串(“”)。
字符串类型的值被保存为一组连续的字节序列，并会根据它们容纳的是二进制字符串还是非二进制字符而被区别对待为字节或者字符：
二进制字符串被视为一个连续的字节序列，与字符集无关。MySQL把BLOB数据列和带BINARY属性的CHAR和VARCHAR数据列里的数据当作二进制值。
非二进制字符串被视为一个连续排列的字符序列。与字符集有关。MySQL把TEXT列与不带BINARY属性的CHAR和VARCHAR数据列里的数据当作二进制值对待。
在MySQL4.1以后的版本中，不同的数据列可以使用不同的字符集。在MySQL4.1版本以前，MySQL用服务器的字符集作为默认字符集。
非二进制字符串，即我们通常所说的字符串，是按字符在字符集中先后次序进行比较和排序的。而二进制字符串因为与字符集无关，所以不以字符顺序排序，而是以字节的二进制值作为比较和排序的依据。下面介绍两种字符串的比较方式：
二进制字符串的比较方式是一个字节一个字节进行的，比较的依据是两个字节的二进制值。也就是说它是区分大小写的，因为同一个字母的大小写的数值编码是不一样的。
非二进制字符串的比较方式是一个字符一个字符进行的，比较的依据是两个字符在字符集中的先后顺序。在大多数字符集中，同一个字母的大小写往往有着相同的先后顺序，所以它不区分大小写。
二进制字符串与字符集无关，所以无论按字符计算还是按字节计算，二进制字符串的长度都是一样的。所以VARCHAR(20)并不表示它最多能容纳20个字符，而是表示它最多只能容纳可以用20个字节表示出来的字符。对于单字节字符集，每个字符只占用一个字节，所以这两者的长度是一样的，但对于多字节字符集，它能容纳的字符个数肯定少于20个。
CHAR和VARCHAR
CHAR和VARCHAR是最常用的两种字符串类型，它们之间的区别是：
CHAR是固定长度的，每个值占用相同的字节，不够的位数MySQL会在它的右边用空格字符补足。
VARCHAR是一种可变长度的类型，每个值占用其刚好的字节数再加上一个用来记录其长度的字节即L+1字节。
CHAR(0)和VARCHAR(0)都是合法的。VARCHAR(0)是从MySQL4.0.2版开始的。它们的作用是作为占位符或用来表示各种on/off开关值。
如何选择CHAR和VARCHAR，这里给出两个原则：
如果数据都有相同的长度，选用VARCHAR会多占用空间，因为有一位用来存储其长度。如果数据长短不一，选用VARCHAR能节省存储空间。而CHAR不论字符长短都需占用相同的空间，即使是空值也不例外。
如果长度出入不大，而且是使用MyISAM或ISAM类型的表，则用CHAR会比VARCHAR好，因为MyISAM和ISAM类型的表对处理固定长度的行的效率高。
在一个数据表里，只要有一个数据列的长度是可变的，则所有数据列的长度将是可变的。MySQL会进行自动地转换。一个例外，CHAR长度小于4的不会进行自动转换，因为MySQL会认为这样做没必要，节省不了多少空间。反而MySQL会把大量长度小的VARCHAR转换成CHAR，以减少空间占用量。
BLOB和TEXT
BLOB是二进制字符串，TEXT是非二进制字符串。两者都可存放大容量的信息。
有关BLOB和TEXT索引的建立：
BDB表类型和MySQL3.23.2以上版本的MyISAM表类型允许在BLOB和TEXT数据列上建立索引。
ISAM、HEAP和InnoDB表不支持大对象列的索引。
使用BLOB和TEXT应注意的问题：
由于这两个列类型所存储的数据量大，所以删除和修改操作容易在数据表里产生大量的碎片，需定期运行OPTIMIZE TABLE以减少碎片和提高性能。
如果使用的值非常巨大，就需对服务器进行相应的优化调整，增加max_allowed_packet参数的值。对那些可会用到变些巨大数据的客户程序，也需加大它们的数据包大小。
ENUM和SET
ENUM和SET都是比较特殊的字符串数据列类型，它们的取值范围是一个预先定义好的列表。ENUM或SET数据列的取值只能从这个列表中进行选择。ENUM和SET的主要区别是：
ENUM只能取单值，它的数据列表是一个枚举集合。它的合法取值列表最多允许有65535个成员。例如：ENUM("N","Y")表示，该数据列的取值要么是"Y"，要么就是"N"。
SET可取多值。它的合法取值列表最多允许有64个成员。空字符串也是一个合法的SET值。
ENUM和SET的值是以字符串形式出现的，但在内部，MySQL以数值的形式存储它们。
ENUM的合法取值列表中的字符串被按声明定义的顺序被编号，从1开始。
SET的编号不是按顺序进行编号的，SET中每一个合法取值都对应着SET值里的一个位。第一个合法取值对应0位，第二个合法取值对应1位，以此类推，如果数值形式的SET值等于0,则说明它是一个空字符串，如果某个合法的取值出现在SET数据列里，与之对应的位就会被置位；如果某个合法的取值没有出现在SET数据列里，与之对应的位就会被清零。正因为SET值与位有这样的对应关系，所以SET数据列的多个合法取值才能同时出现并构成SET值。
字符串类型数据列的字符集属性
在MySQL 4.1以前的版本，字符串数据列的字符集由服务器的字符决定，MySQL 4.1版以后的版本可对每个字符串数据列指定不同的字符串。如果按默认方式设置，可按数据列、数据表、数据库、服务器的顺序关联字符串的字符集，直到找一个明确定义的字符集。
/////////////////////////////////////////////////////////
日期,时间型数据列类型
DATE 1000-01-01~9999-12-31 3字节(MySQL3.23版以前是4字节 ) 0000-00-00
TIME -838:59:59~838:59:59 3字节 00:00:00
DATETIME 1000-01-01 00:00:00~9999-12-31 23:59:59 8字节 0000-00-00 00:00:00
TIMESTAMP 19700101000000~2037年的某个时刻 4字节 00000000000000
YEAR YEAR(4)：1901~2155 YEAR(2)：1970~2069 1字节 0000
MySQL总是把日期和日期里的年份放在最前面，按年月日的顺序显示。
DATE、TIME、DATATIME数据列类型
DATE、TIME和DATATIME类型分别存放日期值、时间值、日期和时间值的组合。它们的格式分别是“CCYY-MM-DD”、“hh:mm:ss”、“CCYY-MM-DD hh:mm:ss”。
DATATIME里的时间值和TIME值是有区别的，DATATIME里的时间值代表的是几点几分，TIME值代表的是所花费的时间。当向TIME数据列插值时，需用时间的完整写法，如12分30秒要写成“00:12:30”。
TIMESTAMP数据列类型
TIMESTAMP数据列的格式是CCYYMMDDhhmmss，取值范围从19700101000000开始，即1970年1月1号，最大到2037年。它的特点是能把数据行的创建或修改时间记录下来：
如果把一个NULL值插入TIMESTAMP列，这个数据列就将自动取值为当前的日期和时间。
在创建和修改数据行时，如果没有明确对TIMESTAMP数据列进行赋值，则它就会自动取值为当前的日期和时间。如果行中有多个TIMESTAMP列，只有第一个会自动取值。
如果对TIMESTAMP设置一个确定的日期和时间值，则会使TIMESTAMP的自动取值功能失效。
TIMESTAMP默认的列宽是14,可指定列宽，以改变显示效果。但不论你指定的列宽如何，MySQL都是以4字节来存储TIMESTAMP值，也总是以14位精度来计算。
如果需要把创建时间和最近一次修改时间同时记录下来，可以用两个时间戳来记录，一个记录创建时间，一个记录修改时间。不过需记住两件事，一是要把记录修改时间的TIMESTAMP数据列放在最前面，这样才会自动取值；二是创建一条新记录时，要用now()函数来初始化创建时间TIMESTAMP数据列，这样，该TIMESTAMP数据列就不会再变化。
YEAR
YEAR是一种单字节的数据列类型，YEAR(4)的取值范围是1901~2155,YEAR(2)的取值范围是1970~2069,但只显示最后两位数。MySQL能自动把两位数字年份转换成四位数字的年份，如97和14分被转换成1997和2014。转换规则是这样的：
年份值00~69将被转换成2000~2069；
年份值70~99将被转换成1970~1999。
00被转换成0000,而不是2000。因为数值00也就是0,而0值是YEAR的一个合法取值。
每个数据列都有它的特定类型，该类型决定了MySQL如何看待该列数据，我们可以把整型数值存放到字符类型的列中，MySQL则会把它看成字符串来处理。
MySQL中的列类型有三种：数值类、字符串类和日期/时间类。
从大类来看列类型和数值类型一样，都是只有三种。但每种列类型都还可细分。
下面对各种列类型进行详细介绍。
数值类的数据列类型
数值型的列类型包括整型和浮点型两大类。
TINYINT：1字节 非常小的正整数，带符号：-128~127，不带符号：0~255
SMALLINT：2字节 小整数，带符号：-32768~32767，不带符号：0~65535
MEDIUMINT：3字节 中等大小的整数，带符号：-8388608~8388607，不带符号：0~16777215
INT：4字节 标准整数，带符号：-2147483648~2147483647，不带符号：0~4294967295
BIGINT：8字节 大整数，带符号：-9223372036854775808~9233372036854775807，不带符号：0~18446744073709551615
FLOAT：4字节 单精度浮点数，最小非零值：+-1.175494351E-38，最大非零值：+-3.402823466E+38
DOUBLE：8字节 双精度浮点数，最小非零值：+-2.2250738585072014E-308，最大非零值：+-1.7976931348623157E+308
DECIMAL：M+2字节 以字符串形式表示的浮点数，它的取值范围可变，由M和D的值决定。
整型数据列类型
MySQL有五种整型数据列类型，即TINYINT，SMALLINT，MEDIUMINT，INT和BIGINT。它们之间的区别是取值范围不同，存储空间也各不相同。
在整型数据列后加上UNSIGNED属性可以禁止负数，取值从0开始。
声明整型数据列时，我们可以为它指定个显示宽度M(1~255)，如INT(5)，指定显示宽度为5个字符,如果没有给它指定显示宽度，MySQL会为它指定一个默认值。显示宽度只用于显示，并不能限制取值范围和占用空间，如：INT(3)会占用4个字节的存储空间，并且允许的最大值也不会是999,而是INT整型所允许的最大值。
浮点型数据列类型
MySQL有三种浮点型数据列类型，分别是：FLOAT，DOUBLE和DECIMAL。
浮点类数据类型有一个最大可表示值和一个最小非零可表示值，最小非零可表示值决定了该类型的精确度。
MySQL 4.0.2版之后，FLOAT和DOUBLE都可以指定UNSIGNED属性。当指定该属性时，取值范围不平移到正数区间，而只是简单地把浮点类型的负数部份去掉。
浮点类型也有M(1~255)和D(1~30，且不能大于M-2)。分别表示显示宽度和小数位数。M和D在FLOAT和DOUBLE中是可选的，默认，当MySQL版本大于3.23.6时，FLOAT和DOUBLE类型将被保存为硬件所支持的最大精度。DECIMAL的M和D值在MySQL3.23.6后可选，默认D值为0,M值为10。
如何选择数值类数据列类型？
为了节省存储空间和提高数据库处理效率，我们应根据应用数据的取值范围来选择一个最适合的数据列类型。如果把一个超出数据列取值范围的数存入该列，则MySQL就会截短该值，如：我们把99999存入SMALLINT(3)数据列里，因为SMALLINT(3)的取值范围是-32768~32767，所以就会被截短成32767存储。显示宽度3不会影响数值的存储。只影响显示。
对于浮点数据列，存入的数值会被该列定义的小数位进行四舍五入。如把一个1.234存入FLOAT(6.1)数据列中，结果是1.2。
DECIMAL与FLOAT和DOUBLE的区别是：DECIMAL类型的值是以字符串的形式被储存起来的，它的小数位数是固定的。它的优点是，不会象FLOAT和DOUBLE类型数据列那样进行四舍五入而产生误差，所以很适合用于财务计算；而它的缺点是：由于它的存储格式不同，CPU不能对它进行直接运算，从而影响运算效率。DECIMAL(M，D)总共要占用M+2个字节。
数值类数据列的属性
ZEROFILL属性适用于所有数值类数据列类型，作用是，如果数值的宽度小于定义的显示宽度，则在数值前填充0。
UNSIGNED属性不允许数据列出现负数。
AUTO_INCREMENT属性可生成独一无二的数字序列。只对整数类的数据列有效。
NULL和NOT NULL属性设置数据列是否可为空。
DEFAULT属性可为数据列指定默认值。
//////////////////////////////////////////////////////
字符串类数据列类型
字符串可以用来表示任何一种值，所以它是最基本的类型之一。
我们可以用字符串类型来存储图象或声音之类的二进制数据，也可存储用gzip压缩的数据。
下表介绍了各种字符串类型：
CHAR[(M)] M字节 M字节
VARCHAR[(M)] M字节 L+1字节
TINYBLOD，TINYTEXT 2^8-1字节 L+1字节
BLOB，TEXT 2^16-1字节 L+2
MEDIUMBLOB，MEDIUMTEXT 2^24-1字节 L+3
LONGBLOB，LONGTEXT 2^32-1字节 L+4
ENUM('value1','value2',...) 65535个成员 1或2字节
SET('value1','value2',...) 64个成员 1,2,3,4或8字节
L+1、L+2是表示数据列是可变长度的，它占用的空间会根据数据行的增减面则改变。数据行的总长度取决于存放在这些数据列里的数据值的长度。L+1或L+2里多出来的字节是用来保存数据值的长度的。在对长度可变的数据进行处理时，MySQL要把数据内容和数据长度都保存起来。
如果把超出字符串最大长度的数据放到字符类数据列中，MySQL会自动进行截短处理。
ENUM和SET类型的数据列定义里有一个列表，列表里的元素就是该数据列的合法取值。如果试图把一个没有在列表里的值放到数据列里，它会被转换为空字符串(“”)。
字符串类型的值被保存为一组连续的字节序列，并会根据它们容纳的是二进制字符串还是非二进制字符而被区别对待为字节或者字符：
二进制字符串被视为一个连续的字节序列，与字符集无关。MySQL把BLOB数据列和带BINARY属性的CHAR和VARCHAR数据列里的数据当作二进制值。
非二进制字符串被视为一个连续排列的字符序列。与字符集有关。MySQL把TEXT列与不带BINARY属性的CHAR和VARCHAR数据列里的数据当作二进制值对待。
在MySQL4.1以后的版本中，不同的数据列可以使用不同的字符集。在MySQL4.1版本以前，MySQL用服务器的字符集作为默认字符集。
非二进制字符串，即我们通常所说的字符串，是按字符在字符集中先后次序进行比较和排序的。而二进制字符串因为与字符集无关，所以不以字符顺序排序，而是以字节的二进制值作为比较和排序的依据。下面介绍两种字符串的比较方式：
二进制字符串的比较方式是一个字节一个字节进行的，比较的依据是两个字节的二进制值。也就是说它是区分大小写的，因为同一个字母的大小写的数值编码是不一样的。
非二进制字符串的比较方式是一个字符一个字符进行的，比较的依据是两个字符在字符集中的先后顺序。在大多数字符集中，同一个字母的大小写往往有着相同的先后顺序，所以它不区分大小写。
二进制字符串与字符集无关，所以无论按字符计算还是按字节计算，二进制字符串的长度都是一样的。所以VARCHAR(20)并不表示它最多能容纳20个字符，而是表示它最多只能容纳可以用20个字节表示出来的字符。对于单字节字符集，每个字符只占用一个字节，所以这两者的长度是一样的，但对于多字节字符集，它能容纳的字符个数肯定少于20个。
CHAR和VARCHAR
CHAR和VARCHAR是最常用的两种字符串类型，它们之间的区别是：
CHAR是固定长度的，每个值占用相同的字节，不够的位数MySQL会在它的右边用空格字符补足。
VARCHAR是一种可变长度的类型，每个值占用其刚好的字节数再加上一个用来记录其长度的字节即L+1字节。
CHAR(0)和VARCHAR(0)都是合法的。VARCHAR(0)是从MySQL4.0.2版开始的。它们的作用是作为占位符或用来表示各种on/off开关值。
如何选择CHAR和VARCHAR，这里给出两个原则：
如果数据都有相同的长度，选用VARCHAR会多占用空间，因为有一位用来存储其长度。如果数据长短不一，选用VARCHAR能节省存储空间。而CHAR不论字符长短都需占用相同的空间，即使是空值也不例外。
如果长度出入不大，而且是使用MyISAM或ISAM类型的表，则用CHAR会比VARCHAR好，因为MyISAM和ISAM类型的表对处理固定长度的行的效率高。
在一个数据表里，只要有一个数据列的长度是可变的，则所有数据列的长度将是可变的。MySQL会进行自动地转换。一个例外，CHAR长度小于4的不会进行自动转换，因为MySQL会认为这样做没必要，节省不了多少空间。反而MySQL会把大量长度小的VARCHAR转换成CHAR，以减少空间占用量。
BLOB和TEXT
BLOB是二进制字符串，TEXT是非二进制字符串。两者都可存放大容量的信息。
有关BLOB和TEXT索引的建立：
BDB表类型和MySQL3.23.2以上版本的MyISAM表类型允许在BLOB和TEXT数据列上建立索引。
ISAM、HEAP和InnoDB表不支持大对象列的索引。
使用BLOB和TEXT应注意的问题：
由于这两个列类型所存储的数据量大，所以删除和修改操作容易在数据表里产生大量的碎片，需定期运行OPTIMIZE TABLE以减少碎片和提高性能。
如果使用的值非常巨大，就需对服务器进行相应的优化调整，增加max_allowed_packet参数的值。对那些可会用到变些巨大数据的客户程序，也需加大它们的数据包大小。
ENUM和SET
ENUM和SET都是比较特殊的字符串数据列类型，它们的取值范围是一个预先定义好的列表。ENUM或SET数据列的取值只能从这个列表中进行选择。ENUM和SET的主要区别是：
ENUM只能取单值，它的数据列表是一个枚举集合。它的合法取值列表最多允许有65535个成员。例如：ENUM("N","Y")表示，该数据列的取值要么是"Y"，要么就是"N"。
SET可取多值。它的合法取值列表最多允许有64个成员。空字符串也是一个合法的SET值。
ENUM和SET的值是以字符串形式出现的，但在内部，MySQL以数值的形式存储它们。
ENUM的合法取值列表中的字符串被按声明定义的顺序被编号，从1开始。
SET的编号不是按顺序进行编号的，SET中每一个合法取值都对应着SET值里的一个位。第一个合法取值对应0位，第二个合法取值对应1位，以此类推，如果数值形式的SET值等于0,则说明它是一个空字符串，如果某个合法的取值出现在SET数据列里，与之对应的位就会被置位；如果某个合法的取值没有出现在SET数据列里，与之对应的位就会被清零。正因为SET值与位有这样的对应关系，所以SET数据列的多个合法取值才能同时出现并构成SET值。
字符串类型数据列的字符集属性
在MySQL 4.1以前的版本，字符串数据列的字符集由服务器的字符决定，MySQL 4.1版以后的版本可对每个字符串数据列指定不同的字符串。如果按默认方式设置，可按数据列、数据表、数据库、服务器的顺序关联字符串的字符集，直到找一个明确定义的字符集。
/////////////////////////////////////////////////////////
日期,时间型数据列类型
DATE 1000-01-01~9999-12-31 3字节(MySQL3.23版以前是4字节 ) 0000-00-00
TIME -838:59:59~838:59:59 3字节 00:00:00
DATETIME 1000-01-01 00:00:00~9999-12-31 23:59:59 8字节 0000-00-00 00:00:00
TIMESTAMP 19700101000000~2037年的某个时刻 4字节 00000000000000
YEAR YEAR(4)：1901~2155 YEAR(2)：1970~2069 1字节 0000
MySQL总是把日期和日期里的年份放在最前面，按年月日的顺序显示。
DATE、TIME、DATATIME数据列类型
DATE、TIME和DATATIME类型分别存放日期值、时间值、日期和时间值的组合。它们的格式分别是“CCYY-MM-DD”、“hh:mm:ss”、“CCYY-MM-DD hh:mm:ss”。
DATATIME里的时间值和TIME值是有区别的，DATATIME里的时间值代表的是几点几分，TIME值代表的是所花费的时间。当向TIME数据列插值时，需用时间的完整写法，如12分30秒要写成“00:12:30”。
TIMESTAMP数据列类型
TIMESTAMP数据列的格式是CCYYMMDDhhmmss，取值范围从19700101000000开始，即1970年1月1号，最大到2037年。它的特点是能把数据行的创建或修改时间记录下来：
如果把一个NULL值插入TIMESTAMP列，这个数据列就将自动取值为当前的日期和时间。
在创建和修改数据行时，如果没有明确对TIMESTAMP数据列进行赋值，则它就会自动取值为当前的日期和时间。如果行中有多个TIMESTAMP列，只有第一个会自动取值。
如果对TIMESTAMP设置一个确定的日期和时间值，则会使TIMESTAMP的自动取值功能失效。
TIMESTAMP默认的列宽是14,可指定列宽，以改变显示效果。但不论你指定的列宽如何，MySQL都是以4字节来存储TIMESTAMP值，也总是以14位精度来计算。
如果需要把创建时间和最近一次修改时间同时记录下来，可以用两个时间戳来记录，一个记录创建时间，一个记录修改时间。不过需记住两件事，一是要把记录修改时间的TIMESTAMP数据列放在最前面，这样才会自动取值；二是创建一条新记录时，要用now()函数来初始化创建时间TIMESTAMP数据列，这样，该TIMESTAMP数据列就不会再变化。
YEAR
YEAR是一种单字节的数据列类型，YEAR(4)的取值范围是1901~2155,YEAR(2)的取值范围是1970~2069,但只显示最后两位数。MySQL能自动把两位数字年份转换成四位数字的年份，如97和14分被转换成1997和2014。转换规则是这样的：
年份值00~69将被转换成2000~2069；
年份值70~99将被转换成1970~1999。
00被转换成0000,而不是2000。因为数值00也就是0,而0值是YEAR的一个合法取值。
