但是我可能是比较幸运的，最后成功的实现了读写分离，目前在开发环境运行的比较稳定，所以有必要做个笔记分享一下。

读写分离脚本的问题

刚启动mysql proxy的时候，经常报错 -- "Mysql server has gone away"。我进一步缩小了可能出问题的范围(把环境简化是很重要的查错手段)，比如只连接一个mysql，或者只连接本机的mysql，没有太大帮助，最后是在mysql proxy的日志文件中看到些蛛丝马迹：

(critical) proxy-plugin.c:1367: (connect_server) [string "/usr/local/share/mysql-proxy/r..."]:69: .address is deprecated. Use .src.name or .dst.name instead
(critical) (read_query) [string "/usr/local/share/mysql-proxy/r..."]:179: .address is deprecated. Use .src.name or .dst.name instead
(critical) proxy-plugin.c.1115: I have no server backend, closing connection

在mysql proxy的论坛上看到有人碰到类似的问题，很简单，读写分离的lua脚本还是旧的，0.6.1时代的产物了，更糟糕的是，即便是即将发布的0.7.0，rw-splitting.lua也是旧版本的。lua脚本中的.address需要替换成.src.name或者.dst.name。

解决办法 —— 下载更新之后的rw-splitting.lua，情况会好转。

使用prepare方法无法获得结果

我在测试代码中采用php的pdo_mysql，单独连接mysql是毫无问题的，然而配合mysql proxy使用则是屡屡受挫，查询经常没有结果返回，比较随机，从日志中也找不到有帮助的内容。这次没有找到解决办法，所以我绕了过去，在连接mysql 的时候使用伪prepare的方式：

据称emulate方式的性能比prepare要好，所以这也算安慰奖了。

专门的lua脚本分支

lua脚本开发滞后，是一个比较严重的问题，所以在邮件组上看到有个新的lua脚本分支出来 —— https://launchpad.net/mysql-proxy-lua-scripts。希望开发速度能跟上来。

keepalive参数

mysql proxy还不算太稳定，偶尔crash我也不觉得惊讶，所以新增的keepalive参数很有用。在proxy启动的时候，加上--keepalive参数，它便会努力保持proxy的运行状态，停止了也会自动重启。

   +-------+------+---------------+------+---------+------+------+-------------+
   | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
   +-------+------+---------------+------+---------+------+------+-------------+
   | tblA  | ALL  | NULL          | NULL |    NULL | NULL | 1000 |             |
   | tblB  | ALL  | NULL          | NULL |    NULL | NULL | 1000 | Using where |
   | tblC  | ALL  | NULL          | NULL |    NULL | NULL | 1000 | Using where |
   +-------+------+---------------+------+---------+------+------+-------------+

+-------+------+---------------+----------+---------+-----------+------+-------------+
| table | type | possible_keys | key      | key_len | ref       | rows | Extra       |
+-------+------+---------------+----------+---------+-----------+------+-------------+
| tblA  | ALL  | NULL          | NULL     |    NULL | NULL      | 1000 |             |
| tblB  | ref  | ndx_col1      | ndx_col1 |       5 | tblA.col1 |    1 | Using where |
| tblC  | ALL  | NULL          | NULL     |    NULL | NULL      | 1000 | Using where |
+-------+------+---------------+----------+---------+-----------+------+-------------+

+-------+------+---------------+----------+---------+-----------+------+-------------+
| table | type | possible_keys | key      | key_len | ref       | rows | Extra       |
+-------+------+---------------+----------+---------+-----------+------+-------------+
| tblA  | ALL  | NULL          | NULL     |    NULL | NULL      | 1000 |             |
| tblB  | ref  | ndx_col1      | ndx_col1 |       5 | tblA.col1 |    1 | Using where |
| tblC  | ref  | ndx_col1      | ndx_col1 |       5 | tblA.col2 |    1 | Using where |
+-------+------+---------------+----------+---------+-----------+------+-------------+

+-------+--------+---------------+---------+---------+---------------+-------+----------------------------------------------+
| table | type   | possible_keys | key     | key_len | ref           | rows  | Extra                                        |
+-------+--------+---------------+---------+---------+---------------+-------+----------------------------------------------+
| tblA  | ALL    | NULL          | NULL    |    NULL | NULL          |  1080 | Using where; Using temporary; Usingfilesort |
| tblB  | ALL    | NULL          | NULL    |    NULL | NULL          | 87189 | Using where                                  |
| tblC  | eq_ref | PRIMARY       | PRIMARY |       4 | tblB.st_ex_id |     1 | Using where                                  |
| tblD  | eq_ref | PRIMARY       | PRIMARY |       4 | tblA.ex_id    |     1 | Using where                                  |
+-------+--------+---------------+---------+---------+---------------+-------+----------------------------------------------+

+-------+--------+---------------+-------------+---------+------------------------+------+----------------------------------------------+
| table | type   | possible_keys | key         | key_len | ref                    | rows | Extra                                        |
+-------+--------+---------------+-------------+---------+------------------------+------+----------------------------------------------+
| tblA  | ALL    | NULL          | NULL        |    NULL | NULL                   | 1080 | Using where; Using temporary; Usingfilesort |
| tblB  | ref    | ndx_secn_qn   | ndx_secn_qn |       2 | tblA.se_num,tblA.q_num |  641 | Using where                                  |
| tblC  | eq_ref | PRIMARY       | PRIMARY     |       4 | tblB.st_ex_id          |    1 | Using where                                  |
| tblD  | eq_ref | PRIMARY       | PRIMARY     |       4 | tblA.ex_id             |    1 | Using where                                  |
+-------+--------+---------------+-------------+---------+------------------------+------+----------------------------------------------+

+-------+--------+---------------+-------------+---------+------------------------+------+----------------------------------------------+
| table | type   | possible_keys | key         | key_len | ref                    | rows | Extra                                        |
+-------+--------+---------------+-------------+---------+------------------------+------+----------------------------------------------+
| tblA  | ref    | ndx_ex_id     | ndx_ex_id   |       4 | const                  |    1 | Using where; Using temporary; Usingfilesort |
| tblB  | ref    | ndx_secn_qn   | ndx_secn_qn |       2 | tblA.se_num,tblA.q_num |  641 | Using where                                  |
| tblC  | eq_ref | PRIMARY       | PRIMARY     |       4 | tblB.st_ex_id          |    1 | Using where                                  |
| tblD  | eq_ref | PRIMARY       | PRIMARY     |       4 | tblA.ex_id             |    1 | Using where                                  |
+-------+--------+---------------+-------------+---------+------------------------+------+----------------------------------------------+

千百亿

存储引擎的选择

一、什么是索引？

索 引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的 所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即 可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。

假设我们创建了一个名为people的表：

　 

　
CREATE TABLE people ( peopleid SMALLINT NOT NULL, 
name CHAR(50) NOT NULL );

然 后，我们完全随机把1000个不同name值插入到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）命令创建全文索引要比把记录插入带有全文索引的空表更快。本文下面的讨论不再涉及全文索引，要了解更多信息，请参见MySQL documentation。

三、单列索引与多列索引

索引可以是单列索引，也可以是多列索引。下面我们通过具体的例子来说明这两种索引的区别。假设有这样一个people表：

CREATE TABLE people ( peopleid 
SMALLINT NOT NULL AUTO_INCREMENT,
firstname CHAR(50) NOT NULL, lastname CHAR(50) NOT NULL, 
age SMALLINT NOT NULL,
townid SMALLINT NOT NULL, PRIMARY KEY (peopleid) );

下面是我们插入到这个people表的数据：

这个数据片段中有四个名字为“Mikes”的人（其中两个姓Sullivans，两个姓McConnells），有两个年龄为17岁的人，还有一个名字与众不同的Joe Smith。

这 个表的主要用途是根据指定的用户姓、名以及年龄返回相应的peopleid。例如，我们可能需要查找姓名为Mike Sullivan、年龄17岁用户的peopleid（SQL命令为SELECT peopleid FROM people WHERE firstname='Mike' AND lastname='Sullivan' AND age=17；）。由于我们不想让MySQL每次执行查询就去扫描整个表，这里需要考虑运用索引。

首 先，我们可以考虑在单个列上创建索引，比如firstname、lastname或者age列。如果我们创建firstname列的索引（ALTER TABLE people ADD INDEX firstname (firstname)；），MySQL将通过这个索引迅速把搜索范围限制到那些firstname='Mike'的记录，然后再在这个“中间结果集”上 进行其他条件的搜索：它首先排除那些lastname不等于“Sullivan”的记录，然后排除那些age不等于17的记录。当记录满足所有搜索条件之 后，MySQL就返回最终的搜索结果。

由 于建立了firstname列的索引，与执行表的完全扫描相比，MySQL的效率提高了很多，但我们要求MySQL扫描的记录数量仍旧远远超过了实际所需 要的。虽然我们可以删除firstname列上的索引，再创建lastname或者age列的索引，但总地看来，不论在哪个列上创建索引搜索效率仍旧相 似。

为了提高搜索效率，我们需要考虑运用多列索引(复合索引)。如果为firstname、lastname和age这三个列创建一个多列索引，MySQL只需一次检索就能够找出正确的结果！下面是创建这个多列索引的SQL命令：

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

从另一方面理解，它相当于我们创建了(firstname，lastname，age)、(firstname，lastname)以及(firstname)这些列组合上的索引。下面这些查询都能够使用这个fname_lname_age索引：

　 　
SELECT peopleid FROM people 
WHERE firstname='Mike' AND lastname='Sullivan' AND age='17'; 
SELECT peopleid FROM people WHERE firstname='Mike' AND lastname='Sullivan'; 
SELECT peopleid FROM people WHERE firstname='Mike'; 

The following queries cannot use the index at all: 

SELECT peopleid FROM people WHERE lastname='Sullivan'; 
SELECT peopleid FROM people WHERE age='17'; 
SELECT peopleid FROM people WHERE lastname='Sullivan' AND age='17';

五、选择索引列

在性能优化过程中，选择在哪些列上创建索引是最重要的步骤之一。可以考虑使用索引的主要有两种类型的列：在WHERE子句中出现的列，在join子句中出现的列。请看下面这个查询：

SELECT age ## 不使用索引
FROM people WHERE firstname='Mike' ## 考虑使用索引
AND lastname='Sullivan' ## 考虑使用索引

这个查询与前面的查询略有不同，但仍属于简单查询。由于age是在SELECT部分被引用，MySQL不会用它来限制列选择操作。因此，对于这个查询来说，创建age列的索引没有什么必要。下面是一个更复杂的例子：

　 

　
SELECT people.age, ##不使用索引
town.name ##不使用索引
FROM people LEFT JOIN town ON
people.townid=town.townid ##考虑使用索引
WHERE firstname='Mike' ##考虑使用索引
AND lastname='Sullivan' ##考虑使用索引

与 前面的例子一样，由于firstname和lastname出现在WHERE子句中，因此这两个列仍旧有创建索引的必要。除此之外，由于town表的 townid列出现在join子句中，因此我们需要考虑创建该列的索引。那么，我们是否可以简单地认为应该索引WHERE子句和join子句中出现的每一 个列呢？差不多如此，但并不完全。我们还必须考虑到对列进行比较的操作符类型。MySQL只有对以下操作符才使用索引：<，<=，=，& gt;，>=，BETWEEN，IN，以及某些时候的LIKE。可以在LIKE操作中使用索引的情形是指另一个操作数不是以通配符（%或者_）开头 的情形。例如，“SELECT peopleid FROM people WHERE firstname LIKE 'Mich%';”这个查询将使用索引，但“SELECT peopleid FROM people WHERE firstname LIKE '%ike';”这个查询不会使用索引。

SELECT * FROM tb1_name WHERE 1= 0 

    在此情形中，MySQL考察WHERE 子句，如果认识到不可能有满足该查询的行，就不会对该表进行搜索。可利用EXPLAIN 语句知道这一点，EXPLAIN 语句要求MySQL显示某些有关它应该执行一条SELECT 查询，而实际没有执行的信息。为了使用E X P L A I N，只需要SELECT 语句前放置EXPLAIN 即可，如下所示：

EXPLAIN SELECT * FROM tb1_name WHERE 1= 0 

    通常，EXPLAIN 返回的信息比这个多，包括将用来扫描表的索引、将要使用的连接类型以及需要在每个表中扫描的行数估计等等。

    优化程序怎样工作

    MySQL查询优化程序有几个目标，但其主要目标是尽量利用索引，而且尽量使用最具有限制性的索引以排除尽可能多的行。这样做可能会适得其反，因为发布一 条SELECT 语句的目的是寻找行，而不是拒绝它们。优化程序这样工作的原因是从要考虑的行中排除行越快，那么找到确实符合给出标准的行就越快。如果能够首先进行最具限 制性的测试，则查询可以进行得更快。假如有一个测试两列的查询，每列上都有一个索引：

WHERE coll = "some value" AND col2 = "some other value" 

    还假定，与col1上的测试相符的有900 行，与col2 上的测试相符的有300 行，而两个测试都通过的有30 行。如果首先测试c o l 1，必须检查900 行以找到也与col2 值相符的30 行。那么测试中有870 将失败。如果首先测试c o l 2，要找到也与col1值相符的30 行，只需检查300 行。测试中有失败270 次，这样所涉及的计算较少，磁盘I/O 也较少。遵循下列准则，有助于优化程序利用索引：

    1 ,比较具有相同类型的列。在比较中利用索引列时，应该使用那些类型相同的列。例如，CHAR(10) 被视为与CHAR(10) 或VARCHAR(10) 相同，但不同于CHAR(12) 和VARCHAR( 12 )。INT 与BIGINT 不同。在MySQL3.23 版以前，要求使用相同类型的列，否则列上的索引将不起作用。自3.23 版后，不严格要求这样做，但相同的列类型比不同类型提供更好的性能。如果所比较的两列类型不同，可使用ALTER TABLE语句修改其中之一使它们的类型相配。

    2, 比较中应尽量使索引列独立。如果在函数调用或算术表达式中使用一个列，则MySQL不能使用这样的索引，因为它必须对每行计算表达式的值。有时，这是不可 避免的，但很多时候，可以重新编写只取索引列本身的查询。下面的WHERE 子句说明了怎样进行这项工作。第一行中，优化程序将简化表达式4/2 为值2，然后使用my_col 上的索引快速地找到小于2 的值。而在第二个表达式中，MySQL必须检索出每行的my_col 值，乘以2，然后将结果与4 比较。没索引可用，因为列中的每个值都要检索，以便能对左边的表达式求值：

WHERE my_col < 4/2
WHERE my_col * 2 < 4 

    让我们考虑另一个例子。假如有一个索引列date _ c o l。如果发布如下的查询，相应的索引未被使用：

SELECT * FROM my_tb1WHERE YEAR(date_col) < 1990 

    其中表达式并不将索引列与1990 比较，而是将从列值计算出的值用于比较，而且必须计算每行的这个值。结果是， date_col 上的索引不可能得到使用。怎样解决？使用一个文字日期即可，这时将会使用date_col 上的索引：

WHERE date_col < "1990-01-01" 

    但是假如没有特定的日期值，那么可能会对找到具有出现在距今一定天数内的日期的记录感兴趣。有几种方法来编写这样的查询，但并非所有方法都很好。三种可能的方法如下: 

where TO_DAYS(date_col) -TO_DAYS(cunnent_date)<cutoff.
 where TO_DAYS(date_col) <cutoff+TO_DAYS(cunnent_date)
 where date_col<DATE_ADD(cunnent_date,INTERVL cutoff DAY)

    其中第一行不能利用索引， 因为必须为每行检索列， 以便能够计算TO _ DAYS(date_col) 的值。第二行要好一些。c ut o ff 和TO _ DAY S ( CURRENT _ DATE) 两者都是常量，因此比较表达式的右边可在查询处理前由优化程序一次计算出来，而不是每行计算一次。但date_col 列仍然出现在一个函数调用中，因此，没有使用索引。第三行是最好的方法。比较表达式的右边可在执行查询前作为常量一次计算出来，但现在其值是一个日期。这 个值可直接与date_col 的值进行比较，不再需要转换为天数，可以利用索引。

    ■ 在LIKE 模式的起始处不要使用通配符。有时，有的人会用下列形式的WHERE 子句来搜索串：

WHERE col_name LIKE "%string%" 

    如果希望找到s t r i n g，不管它出现在列中任何位置，那么这样做是对的。但不要出于习惯在串的两边加“ %”。如果实际要查找的只是出现在列的开始处的串，则不应该要第一个“%”号。例如，如果在一个包含姓的列中查找“ M a c”起始的姓，应该编写如下的WHERE 子句：

WHERE last_name LIKE "Mac%" 

    优化程序考虑模式中的开始的文字部分，然后利用索引找到相符合的行。不过宁可写成如下的表达式，它允许使用last_name 上的索引：

WHERE last_name >= "Mac" AND last_name < "Mad"

(这个写法比上面还好些)

DELETE FROM tb1_name 

DELETE FROM tb1_name WHERE 1> 0 

    这迫使MySQL进行逐行的删除。相应的查询执行要慢得多，但将返回真正删除的行数。它还将保持当前的AUTO_INCREMENT 序列的编号，不过只对MyISAM 表（MySQL3.23 以上的版本可用）有效。而对于ISAM 表，序列仍将重置。   

    ■ 避免更新循环不终止。如果更新一个索引列，如果该列用于WHERE 子句且更新将索引值移入至今尚未出超的取值范围内时，有可能对所更新的行进行不终止的更新。假如表my_tbl 有一个索引了的整数列key _ c o l。下列的查询会产生问题：

update my_tbl  set  key_col=key_col+1 where key_col>0

     这个问题的解决方法是在WHERE 子句中将key_col 用于一个表达式，使MySQL不能使用索引：

update my_tbl  set  key_col=key_col+1 where key_col+0>0

    实际上，还有另外的方法，即升级到MySQL3.23.2 或更高的版本，它们已经解决了这样的问题。

    以随机次序检索结果。自MySQL3.23.3 以来，可使用ORDER BY RAND( ) 随机地对结果进行排序。另一技术对MySQL更旧的版本很有用处，那就是选择一个随机数列，然后在该列上进行排序。但是，如果按如下编写查询，优化程序将 会让您的愿望落空：

 select ...,RAND( )  as rand_col from ... order by  rand_col

    这里的问题是MySQL认为该列是一个函数调用，将认为相应的列值是一个常数，而对ORDER BY 子句进行优化，使此查询失效。可在表达式中引用某个表列来蒙骗优化程序。例如，如果表中有一个名为age 的列，可编写如下查询：

select ...,age*0+RAND( )  as rand_col from ... order by  rand_col

　　MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更 好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空 间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不 是BIGIN来定义整型字段。

　　另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。

　　对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

　　 2、使用连接（JOIN）来代替子查询(Sub-Queries)

　　MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一 个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递 给主查询，如下所示：

　　DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

　　使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况 下，子查询可以被更有效率的连接（JOIN）.. 替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：

　　SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

　　如果使用连接（JOIN）.. 来完成这个查询工作，速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：

　　SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL

　　连接（JOIN）.. 之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

　　 3、使用联合(UNION)来代替手动创建的临时表

　　MySQL 从 4.0 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用 UNION 来创建查询的时候，我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。下面的例子就演示了一个使用 UNION的查询。

　　SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author
　　UNION
　　SELECT Name, Supplier FROM product

　　 4、事务

　　尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可 以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错 的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突 然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是： 要么语句块中每条语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN 关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。

　　BEGIN;

　　INSERT INTO salesinfo SET CustomerID=14;

　　UPDATE inventory SET Quantity=11

　　WHERE item='book';

　　COMMIT;

　　事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。

5、锁定表

　　尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户

　　来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

　　其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

　　LOCK TABLE inventory WRITE
　　SELECT Quantity FROM inventory
　　WHERE Item='book';
　　...

　　UPDATE inventory SET Quantity=11
　　WHERE Item='book';
　　UNLOCK TABLES

　　这里，我们用一个 SELECT 语句取出初始数据，通过一些计算，用 UPDATE 语句将新值更新到表中。包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前，不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。

　　 6、使用外键

　　锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。例如，外键可以保证每一条销售记录都指向某一 个存在的客户。在这里，外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到 salesinfo中。

　　CREATE TABLE customerinfo
　　(
　　　CustomerID INT NOT NULL ,
　　　PRIMARY KEY ( CustomerID )
　　) TYPE = INNODB;
　　CREATE TABLE salesinfo
　　(
　　　SalesID INT NOT NULL,
　　　CustomerID INT NOT NULL,
　　　PRIMARY KEY(CustomerID, SalesID),
　　　FOREIGN KEY (CustomerID) REFERENCES customerinfo
　　　(CustomerID) ON DELETECASCADE
　　) TYPE = INNODB;

　　注意例子中的参数“ON DELETE CASCADE”。该参数保证当 customerinfo 表中的一条客户记录被删除的时候，salesinfo 表中所有与该客户相关的记录也会被自动删除。如果要在 MySQL 中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。该类型不是 MySQL 表的默认类型。定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。如例中所示。

　　 7、使用索引

　　索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候，性能提高更为明显。那该对哪些字段建立索引呢？一般说来，索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况，例如 customerinfo中的“province”.. 字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。此外，MySQL

　　从版本3.23.23开始支持全文索引和搜索。全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。

　　 8、优化的查询语句

　　绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。下面是应该注意的几个方面。首 先，最好是在相同类型的字段间进行比较的操作。在MySQL 3.23版之前，这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和 VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。其次，在建有索引的字段上尽量不要使用函数进行操作。

　　例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。

　　SELECT * FROM order WHERE YEAR(OrderDate)<2001;
　　SELECT * FROM order WHERE OrderDate<"2001-01-01";

　　同样的情形也会发生在对数值型字段进行计算的时候：

　　SELECT * FROM inventory WHERE Amount/7<24;
　　SELECT * FROM inventory WHERE Amount<24*7;

　　上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。第三，在搜索字符型字段时，我们有时会使用 LIKE 关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。例如下面的查询将会比较表中的每一条记录。

　　SELECT * FROM books
　　WHERE name like "MySQL%"

　　但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：

　　SELECT * FROM books
　　WHERE name>="MySQL"and name<"MySQM"

　　最后，应该注意避免在查询中让MySQL进行自动类型转换，因为转换过程也会使索引变得不起作用。

我们现在回到函数上。记得我们用
SUM
这个指令来算出所有的 Sales (营业额)吧！如果我们的需求变成是要算出每一间店 (store_name) 的营业额 (sales)，那怎么办呢？在这个情况下，我们要做到两件事：第一，我们对于 store_name 及 Sales 这两个栏位都要选出。第二，我们需要确认所有的 sales 都要依照各个 store_name 来分开算。这个语法为：
SELECT "栏位1", SUM("栏位2") FROM "表格名" GROUP BY "栏位1"
在我们的示范上
Store_Information 表格

那我们如何对函数产生的值来设定条件呢？举例来说，我们可能只需要知道哪些店的营业额有超过 $1,500。在这个情况下，我们不能使用
WHERE
的指令。那要怎么办呢？很幸运地，SQL 有提供一个
HAVING
的指令，而我们就可以用这个指令来达到这个目标。
HAVING
子句通常是在一个 SQL 句子的最后。一个含有 HAVING 子句的 SQL 并不一定要包含
GROUP BY
子句。HAVING
的语法如下：
SELECT "栏位1", SUM("栏位2") FROM "表格名" GROUP BY "栏位1" HAVING (函数条件)
请读者注意： GROUP BY 子句并不是一定需要的。
在我们Store_Information 表格这个例子中
Store_Information 表格

Food

|

|---Fruit

|     |

|     |---Red

|     |     |

|     |     |--Cherry

|     |

|     |---Yellow

|           |

|           |--Banana

|

|---Meat

      |

      |--Beef

      |

      |--Pork

为了照顾那些英文一塌糊涂的PHP爱好者  
Food:食物  
Fruit:水果  
Red:红色  
Cherry:樱桃  
Yellow:黄色  
Banana:香蕉  
Meat:肉类  
Beef:牛肉  
Pork:猪肉  


毗邻目录模式(adjacency list model)  
这种模式我们经常用到，很多的教程和书中也介绍过。我们通过给每个节点增加一个属性 parent 来表示这个节点的父节点从而将整个树状结构通过平面的表描述出来。根据这个原则，例子中的数据可以转化成如下的表：  

以下是代码：  

+-----------------------+

|    parent |     name     |

+-----------------------+

|           |     Food     |

|    Food    |    Fruit     |

|    Fruit   |     Green    |

|    Green   |     Pear     |

|    Fruit   |     Red      |

|    Red     |     Cherry   |

|    Fruit   |     Yellow   |

|    Yellow |     Banana   |

|    Food    |     Meat     |

|    Meat    |     Beef     |

|    Meat    |     Pork     |

+-----------------------+

我们看到 Pear 是Green的一个子节点，Green是Fruit的一个子节点。而根节点'Food'没有父节点。 为了简单地描述这个问题， 这个例子中只用了name来表示一个记录。 在实际的数据库中，你需要用数字的id来标示每个节点，数据库的表结构大概应该像这样：id, parent_id, name, descrīption。  
有了这样的表我们就可以通过数据库保存整个多级树状结构了。  

显示多级树  
如果我们需要显示这样的一个多级结构需要一个递归函数。  

以下是代码：  

<?php

// $parent is the parent of the children we want to see

// $level is increased when we go deeper into the tree,

//         used to display a nice indented tree



function display_children($parent, $level) 

{

    // 获得一个 父节点 $parent 的所有子节点

    $result = mysql_query('SELECT name FROM tree '.

                           'WHERE parent="'.$parent.'";');



    // 显示每个子节点

    while ($row = mysql_fetch_array($result)) 

    {

        // 缩进显示节点名称

        echo str_repeat('   ',$level).$row['name']."n";



        //再次调用这个函数显示子节点的子节点

       

        display_children($row['name'], $level+1);

    }

}

?>;

对整个结构的根节点（Food）使用这个函数就可以打印出整个多级树结构，由于Food是根节点它的父节点是空的，所以这样调用: display_children('',0)。将显示整个树的内容：  

Food 

Fruit 

 Red 

   Cherry 

 Yellow 

   Banana 

Meat 

 Beef 

 Pork 

如果你只想显示整个结构中的一部分，比如说水果部分，就可以这样调用：display_children('Fruit',0);  

几乎使用同样的方法我们可以知道从根节点到任意节点的路径。比如 Cherry 的路径是　"Food >; Fruit >; Red"。 为了得到这样的一个路径我们需要从最深的一级"Cherry"开始， 查询得到它的父节点"Red"把它添加到路径中， 然后我们再查询Red的父节点并把它也添加到路径中，以此类推直到最高层的"Food"  

以下是代码：  

<?php

// $node 是那个最深的节点

function get_path($node) 

{

    // 查询这个节点的父节点

    $result = mysql_query('SELECT parent FROM tree '.

                           'WHERE name="'.$node.'";');

    $row = mysql_fetch_array($result);



    // 用一个数组保存路径

    $path = array();



    // 如果不是根节点则继续向上查询

    // (根节点没有父节点)

    if ($row['parent']!='') 

    {

        // the last part of the path to $node, is the name

        // of the parent of $node

        $path[] = $row['parent'];



        // we should add the path to the parent of this node

        // to the path

        $path = array_merge(get_path($row['parent']), $path);

    }



    // return the path

    return $path;

}

?>;

如果对"Cherry"使用这个函数：print_r(get_path('Cherry'))，就会得到这样的一个数组了：  

Array 

( 

   [0] =>; Food 

   [1] =>; Fruit 

   [2] =>; Red 

) 

接下来如何把它打印成你希望的格式，就是你的事情了。  

缺点：  
这种方法很简单，容易理解，好上手。但是也有一些缺点。主要是因为运行速度很慢，由于得到每个节点都需要进行数据库查询，数据量大的时候要进行很多查询才能完成一个树。另外由于要进行递归运算，递归的每一级都需要占用一些内存所以在空间利用上效率也比较低。  

现在让我们看一看另外一种不使用递归计算，更加快速的方法，这就是预排序遍历树算法(modified preorder tree traversal algorithm)  
这种方法大家可能接触的比较少，初次使用也不像上面的方法容易理解，但是由于这种方法不使用递归查询算法，有更高的查询效率。  

我们首先将多级数据按照下面的方式画在纸上，在根节点Food的左侧写上 1 然后沿着这个树继续向下 在 Fruit 的左侧写上 2 然后继续前进，沿着整个树的边缘给每一个节点都标上左侧和右侧的数字。最后一个数字是标在Food 右侧的 18。 在下面的这张图中你可以看到整个标好了数字的多级结构。（没有看懂？用你的手指指着数字从1数到18就明白怎么回事了。还不明白，再数一遍，注意移动你的 手指）。  
这些数字标明了各个节点之间的关系，"Red"的号是3和6，它是 "Food" 1-18 的子孙节点。 同样，我们可以看到 所有左值大于2和右值小于11的节点 都是"Fruit" 2-11 的子孙节点  

以下是代码：  

                                 1 Food 18

                                     |

                 +-------------------------------------------+

                 |                                                        |

             2 Fruit 11                                     12 Meat 17

                 |                                                        |

     +------------------------+                    +-----------------------+

     |                                 |                    |                               |

 3 Red 6                7 Yellow 10          13 Beef 14             15 Pork 16

     |                                 |

4 Cherry 5                8 Banana 9

这样整个树状结构可以通过左右值来存储到数据库中。继续之前，我们看一看下面整理过的数据表。  

以下是代码：  

+-----------------------+-----+-----+

|    parent |     name   | lft    | rgt |

+-----------------------+-----+-----+

|               |     Food     | 1    | 18   |

|    Food    |    Fruit       | 2    | 11   |

|    Fruit     |     Red       | 3    |   6   |

|    Red      |     Cherry   | 4    |   5   |

|    Fruit     |     Yellow   | 7    | 10   |

|    Yellow |     Banana | 8    |   9   |

|    Food    |     Meat      | 12   | 17   |

|    Meat    |     Beef      | 13   | 14   |

|    Meat    |     Pork      | 15   | 16   |

+-----------------------+-----+-----+

注意：由于"left"和"right"在 SQL中有特殊的意义，所以我们需要用"lft"和"rgt"来表示左右字段。 另外这种结构中不再需要"parent"字段来表示树状结构。也就是 说下面这样的表结构就足够了。  

以下是代码：  

+------------+-----+-----+

|     name     | lft | rgt |

+------------+-----+-----+

|     Food     | 1    | 18   |

|    Fruit     | 2    | 11   |

|     Red      | 3    |   6   |

|     Cherry   | 4    |   5   |

|     Yellow   | 7    | 10   |

|     Banana   | 8    |   9   |

|     Meat     | 12   | 17   |

|     Beef     | 13   | 14   |

|     Pork     | 15   | 16   |

+------------+-----+-----+

好了我们现在可以从数据库中获取数据了，例如我们需要得到"Fruit"项下的所有所有节点就可以这样写查询语句：  
SELECT * FROM tree WHERE lft BETWEEN 2 AND 11;  
这个查询得到了以下的结果。  

以下是代码：  

+------------+-----+-----+

|     name     | lft | rgt |

+------------+-----+-----+

|    Fruit     | 2    | 11   |

|     Red      | 3    |   6   |

|     Cherry   | 4    |   5   |

|     Yellow   | 7    | 10   |

|     Banana   | 8    |   9   |

+------------+-----+-----+

看到了吧，只要一个查询就可以得到所有这些节点。为了能够像上面的递归函数那样显示整个树状结构，我们还需要对这样的查询进行排序。用节点的左值进行排序：  

SELECT * FROM tree WHERE lft BETWEEN 2 AND 11 ORDER BY lft ASC;  


剩下的问题如何显示层级的缩进了。  

以下是代码：  

<?php

function display_tree($root) 

{

    // 得到根节点的左右值

    $result = mysql_query('SELECT lft, rgt FROM tree '.'WHERE name="'.$root.'";');

    $row = mysql_fetch_array($result);



    // 准备一个空的右值堆栈

    $right = array();



    // 获得根基点的所有子孙节点

    $result = mysql_query('SELECT name, lft, rgt FROM tree '.

                           'WHERE lft BETWEEN '.$row['lft'].' AND '.

                           $row['rgt'].' ORDER BY lft ASC;');



    // 显示每一行

    while ($row = mysql_fetch_array($result)) 

    {

        // only check stack if there is one

        if (count($right)>;0) 

    {

            // 检查我们是否应该将节点移出堆栈

            while ($right[count($right)-1]<$row['rgt']) 

    {

                array_pop($right);

            }

        }



        // 缩进显示节点的名称

        echo str_repeat('   ',count($right)).$row['name']."n";



        // 将这个节点加入到堆栈中

        $right[] = $row['rgt'];

    }

}

?>;

如果你运行一下以上的函数就会得到和递归函数一样的结果。只是我们的这个新的函数可能会更快一些，因为只有2次数据库查询。  

要获知一个节点的路径就更简单了，如果我们想知道Cherry 的路径就利用它的左右值4和5来做一个查询。  

SELECT name FROM tree WHERE lft < 4 AND rgt >; 5 ORDER BY lft ASC;  

这样就会得到以下的结果：  

以下是代码：  

+------------+

|     name     |

+------------+

|    Food      |

|    Fruit     |

|     Red      |

+------------+

那么某个节点到底有多少子孙节点呢？很简单，子孙总数=(右值-左值-1)/2  
descendants = (right – left - 1) / 2  
不相信？自己算一算啦。  
用这个简单的公式，我们可以很快的算出"Fruit 2-11"节点有4个子孙节点，而"Banana 8-9"节点没有子孙节点，也就是说它不是一个父节点了。  

很神奇吧？虽然我已经多次用过这个方法，但是每次这样做的时候还是感到很神奇。  

这的确是个很好的办法，但是有什么办法能够帮我们建立这样有左右值的数据表呢？这里再介绍一个函数给大家，这个函数可以将name和parent结构的表自动转换成带有左右值的数据表。  

以下是代码：  

<?php

function rebuild_tree($parent, $left) {

    // the right value of this node is the left value + 1

    $right = $left+1;



    // get all children of this node

    $result = mysql_query('SELECT name FROM tree '.

                           'WHERE parent="'.$parent.'";');

    while ($row = mysql_fetch_array($result)) {

        // recursive execution of this function for each

        // child of this node

        // $right is the current right value, which is

        // incremented by the rebuild_tree function

        $right = rebuild_tree($row['name'], $right);

    }



    // we've got the left value, and now that we've processed

    // the children of this node we also know the right value

    mysql_query('UPDATE tree SET lft='.$left.', rgt='.

                 $right.' WHERE name="'.$parent.'";');



    // return the right value of this node + 1

    return $right+1;

}

?>;

第 1 部分 - 设计数据库之前
这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。 php程序员站

第 2 部分 - 设计数据库表
总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。

第 3 部分 - 选择键
怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等。 www~phperz~com

第 4 部分 - 保证数据完整性
讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 phperz.com

第 5 部分 - 各种小技巧
不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。

第 1 部分 - 设计数据库之前

考察现有环境

　　在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。


定义标准的对象命名规范

　　一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。还有，日期列[字段]最好以 D_ 作为名字打头。

phperz~com

www.phperz.com

获取数据模式资源手册

　　正在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。其他的你还可以参考相关书籍。


畅想未来，但不可忘了过去的教训

　　我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。

　　一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”。


在物理实践之前进行逻辑设计

　　在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。

phperz.com

phperz.com

　　其余四部分

总的来说，要想使一个较慢速SELECT ... WHERE更快，应首先检查是否能增加一个索引。不同表之间的引用通常通过索引来完成。你可以使用EXPLAIN语句来确定SELECT语句使用哪些索引。参见7.4.5节，“MySQL如何使用索引”和7.2.1节，“EXPLAIN语法（获取关于SELECT的信息）”。

下面是一些加速对MyISAM表的查询的一般建议：

·         为了帮助MySQL更好地优化查询，在一个装载数据后的表上运行ANALYZE TABLE或myisamchk --analyze。这样为每一个索引更新指出有相同值的行的平均行数的值（当然，如果只有一个索引，这总是1。）MySQL使用该方法来决定当你联接两个基于非常量表达式的表时选择哪个索引。你可以使用SHOW INDEX FROM tbl_name并检查Cardinality值来检查表分析结果。myisamchk --description --verbose可以显示索引分布信息。

·         要想根据一个索引排序一个索引和数据，使用myisamchk --sort-index --sort-records=1（如果你想要在索引1上排序）。如果只有一个索引，想要根据该索引的次序读取所有的记录，这是使查询更快的一个好方法。但是请注意，第一次对一个大表按照这种方法排序时将花很长时间！

·                        ((a AND b) AND c OR (((a AND b) AND (c AND d))))

·                -> (a AND b AND c) OR (a AND b AND c AND d)

·                   (a<b AND b=c) AND a=5

·                -> b>5 AND b=c AND a=5

·                   (B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)

·                -> B=5 OR B=6

mysql> SELECT * FROM t WHERE primary_key=1;

mysql> SELECT * FROM t1,t2

           WHERE t1.primary_key=1 AND t2.primary_key=t1.id;

创建一个空表后，需要填入内容。通过LOAD DATA和INSERT语句可以完成该任务。

假定你的宠物纪录描述如下。（假定在 MySQL 中期望的日期格式是YYYY-MM-DD；这可能与你习惯的不同。）

因为你是从一个空表开始的，填充它的一个简易方法是创建一个文本文件，每个动物各一行，然后用一个语句将文件的内容装载到表中。

你可以创建一个文本文件 “pet.txt”，每行包含一个记录，用定位符(tab)把值分开，并且以CREATE TABLE语句中列出的列次序给出。对于丢失的值(例如未知的性别，或仍然活着的动物的死亡日期)，你可以使用NULL值。为了在你的文本文件中表示这些内容，使用\N（反斜线，字母N）。例如，Whistler鸟的记录应为(这里值之间的空白是一个定位符)：

要想将文本文件 “pet.txt”装载到pet表中，使用这个命令：

mysql> LOAD DATA LOCAL INFILE '/path/pet.txt' INTO TABLE pet;

请注意如果用Windows中的编辑器（使用\r\n做为行的结束符）创建文件，应使用：

mysql> LOAD DATA LOCAL INFILE '/path/pet.txt' INTO TABLE pet

    -> LINES TERMINATED BY '\r\n';

（在运行OS X的Apple机上，应使用行结束符'\r'。）

如果你愿意，你能明确地在LOAD DATA语句中指出列值的分隔符和行尾标记，但是默认标记是定位符和换行符。这对读入文件 “pet.txt”的语句已经足够。

如果该语句失败，可能是你安装的MySQL不与使用默认值的本地文件兼容。关于如何更改请参见5.6.4节，“LOAD DATA LOCAL安全问题”。

如果想要一次增加一个新记录，可以使用INSERT语句。最简单的形式是，提供每一列的值，其顺序与CREATE TABLE语句中列的顺序相同。假定Diane把一只新仓鼠命名为Puffball，你可以使用下面的INSERT语句添加一条新记录：

mysql> INSERT INTO pet

    -> VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);

注意，这里字符串和日期值均为引号扩起来的字符串。另外，可以直接用INSERT语句插入NULL代表不存在的值。不能使用LOAD DATA中所示的的\N。

从这个例子，你应该能看到涉及很多的键入用多个INSERT语句而非单个LOAD DATA语句装载你的初始记录

在我们的数据库设计中，不可逃避的就是数据库表的主键，可能有很多朋友没有深入思考过，主键的设计对整个数据库的设计影响很大，因此我们不得不要重视起来。

主键的必要性:

有 些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录 必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时，这些操作会变的非常麻烦。

主键的无意义性：

我 强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”字段，而这个字段呢在业务实际中本身就是应该具有唯一 性，具有唯一标识记录的功能，但我是不推荐采用订单编号字段作为主键的，因为具有实际意义的字段，具有“意义更改”的可能性，比如订单编号在刚开始的时候 我们一切顺利，后来客户说“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，这样原来的主键就面临危险了。因此，具有唯一性的实际字段也 代表可以作为主键。因此，我推荐是新设一个字段专门用为主键，此主键本身在业务逻辑上不体现，不具有实际意义。而这种主键在一定程序增加了复杂度，所以要 视实际系统的规模大小而定，对于小项目，以后扩展不会很大的话，也查允许用实际唯一的字段作主键的。

主键的选择

    我们现在在思考一下，应该采用什么来作表的主键比较合理，申明一下，主键的设计没有一个定论，各人有各人的方法，哪怕同一个，在不同的项目中，也会采用不同的主键设计原则。

第一：编号作主键

     此方法就是采用实际业务中的唯一字段的“编号”作为主键设计，这在小型的项目中是推荐这样做的，因为这可以使项目比较简单化，但在使用中却可能带来一些麻烦，比如要进行“编号修改”时，可能要涉及到很多相关联的其他表，就象黎叔说的“后果很严重”;还有就是上面提到的“业务要求允许编号重复时”，我们再那么先知，都无法知道业务将会修改成什么?

第二：自动编号主键

      这种方法也是很多朋友在使用的，就是新建一个ID字段，自动增长，非常方便也满足主键的原则，优点是：数据库自动编号，速度快，而且是增量增长，聚集型主键按顺序存放，对于检索非常有利;数字型的，占用空间小，易排序，在程序中传递也方便;如果通过非系统增加记录（比如手动录入，或是用其他工具直接在表里插入新记录，或老系统数据导入）时，非常方便，不用担心主键重复问题。

      缺点：其实缺点也就是来自其优点，就是因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其他系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）;如果其他系统主键不是数字型那就麻烦更大了，会导致修改主键数据类型了，这也会导致其他相关表的修改，后果同样很严重;就算其他系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个“o”(old)来表示这是老数据，那么自动增长的数字型又面临一个挑战。

第三：Max加一

     由于自动编号存在那些问题，所以有些朋友就采用自己生成，同样是数字型的，只是把自动增长去掉了，采用在Insert时，读取Max值后加一，这种方法可以避免自动编号的问题，但也存在一个效率问题，如果记录非常大的话，那么Max()也会影响效率的;更严重的是并发性问题，如果同时有两人读到相同的Max后，加一后插入的ID值会重复，这已经是有经验教训的了。

第四：自制加一

     考虑Max加一的效率后，有人采用自制加一，也就是建一个特别的表，字段为：表名，当前序列值。这样在往表中插入值时，先从此表中找到相应表的最大值后加一，进行插入，有人可能发现，也可能会存在并发处理，这个并发处理，我们可以采用lock线程的方式来避免，在生成此值的时，先Lock，取到值以后，再unLock出来，这样不会有两人同时生成了。这比Max加一的速度要快多了。但同样存在一个问题：在与其他系统集成时，脱离了系统中的生成方法后，很麻烦保证自制表中的最大值与导入后的保持一致，而且数字型都存在上面讲到的“o”老数据的导入问题。因此在“自制加一”中可以把主键设为字符型的。字符型的自制加一我倒是蛮推荐的，应该字符型主键可以应付很多我们意想不到的情况。

第五：GUID主键

    目前一个比较好的主键是采用GUID，当然我是推荐主键还是字符型的，但值由GUID生成，GUID是可以自动生成，也可以程序生成，而且键值不可能重复，可以解决系统集成问题，几个系统的GUID值导到一起时，也不会发生重复，就算有“o”老数据也可以区分，而且效率很高，在.NET里可以直接使用System.Guid.NewGuid()进行生成，在SQL里也可以使用 NewID()生成。优点是：

同 IDENTITY 列相比，uniqueidentifier 列可以通过 NewID() 函数提前得知新增加的行 ID，为应用程序的后续处理提供了很大方便。

便于数据库移植，其它数据库中并不一定具有 IDENTITY 列，而 Guid 列可以作为字符型列转换到其它数据库中，同时将应用程序中产生的 GUID 值存入数据库，它不会对原有数据带来影响。

便于数据库初始化，如果应用程序要加载一些初始数据， IDENTITY 列的处理方式就比较麻烦，而 uniqueidentifier 列则无需任何处理，直接用 T-SQL 加载即可。

便于对某些对象或常量进行永久标识，如类的 ClassID，对象的实例标识，UDDI 中的联系人、服务接口、tModel标识定义等。

缺点是：

GUID 值较长，不容易记忆和输入，而且这个值是随机、无顺序的

GUID 的值有 16 个字节，与其它那些诸如 4 字节的整数相比要相对大一些。这意味着如果在数据库中使用 uniqueidentifier 键，可能会带来两方面的消极影响：存储空间增大；索引时间较慢。

我也不是推荐GUID最好，其实在不同的情况，我们都可以采用上面的某一种方式，思考了一些利与弊，也方便大家在进行设计时参考。这些也只是我的一点思考而已，而且可能我知识面限制，会有一些误论在里面，希望大家有什么想法欢迎讨论。