首先，Google对新站或较新鲜度的东西都比较敏感，有很高的查知性。它会通过外部链接很快查看到你的站点，通常通过外部链接的收录率多少，给予一个站的评价高低，如果发现新站点击或收录率高那么自然收录速度也很快。

　　另外，Google 使用 PageRank 技术检查整个网络链接结构，并确定哪些网页重要性最高。然后进行超文本匹配分析，以确定哪些网页与正在执行的特定搜索相关。在综合考虑整体重要性以及与特定查询的相关性之后，Google 才将最相关最可靠的搜索结果放在首位。这也是Google收录网页的特点之一。

　　特点二，Google会将链接的文字描述作为关键词加以索引，所以我们在作友情链接时千万要仔细设计链接的文字描述，使之既符合网站的定位又不失相关性，以此博得Google的信任。

　　特点三，Google 漫游器会定期抓取 Web，将大量网页列入索引。稍后完成的下一次抓取会注意到新网站、对现有网站的更改以及失效的链接，并对内容的变化在搜索结果中加以调整。

　　那么，百度搜索引擎收录习惯，它较重视第一次收录印象，根据第一次印象做为网站重要与非重要衡量指标。相对Google而言，百度搜索引擎的人为参与度较高，也就是说在某些层面上可能由人来决定是否收录网页而不是由机器来决定。所以，网站在登录百度搜索引擎之前最好把内容做得丰富点、原创内容多一点、网页关键词与内容的相关度高一点，这样才能给百度较好的初次印象。

　　百度对网页的更新相对Google而言更加敏感，可能这与百度的本土性格有关。百度搜索引擎每周更新，网页视重要性有不同的更新率，频率在几天至一月之间。所以在百度的搜索结果中基本上都标明了收录时间。

　　看了以上针对百度与Google的收录习惯，以后大家在优化过程中会更有针对性，在内容方面尽可多些原创，有时候原创会比你刻意增加关键词更有收录效果。

　　大家一定要注意，虽然关键字密度是排名的一个重要的因素，当然不可忽略，但最重要的还是内容。很多人都为了达到2%~8%的关键字密度而不故内容质量，刻意地在页面加上所优化的目标关键了，其实这样做有时候反而会得到相反的效果

豆瓣从今年开始也加入 Google Analytics 的统计阵营。让我们通过它加载的 Google Analytics 源码，简单分析一下它都是怎么应用的。

我们先从豆瓣的源码来看看它的Google Analytics统计代码

豆瓣 Google Analytics 代码

我们知道一般默认的 Google Analytics代码如下：

默认 Google Analytics 统计代码

两相对比，我们就会发现豆瓣加载 ga.js 的方式与默认的方式有些不太一样，由于豆瓣并没有采用 https 加密访问，所以撇弃了默认的ga.js加载方式。

默认的统计函数，pageTracker 也被豆瓣改成了 _ga ，这个只是名称定义上的区别，并没有什么实质的改变。豆瓣的主要应用是下面两个函数：

使用 _ga._addOrganic 识别非主流搜索引擎

再来看豆瓣比默认 Google Analytics 代码增加的部分，那就是多了数个 _ga._addOrganic ，这是 Google Analytics 添加自定义搜索引擎的代码。尽管 Google Analytics 对于主流的搜索引擎都能自动识别，但毕竟能识别的是国外的主流搜索引擎，在国内，像搜狐的 Sogou，QQ 的 soso，网易的有道等搜索引擎，都不能被 Google Analytics 正确识别，而被当作推荐来源。这时候我们就可以利用_addOrganic 参数来识别这些非主流搜索引擎，如豆瓣的做法。

使用 _addIgnoredOrganic 忽略关键字

除了添加自定义搜索引擎，豆瓣在最后还添加了如下这些代码:

_ga._addIgnoredOrganic("豆瓣");
_ga._addIgnoredOrganic("douban");
_ga._addIgnoredOrganic("豆瓣网");
_ga._addIgnoredOrganic("www.douban.com");

这些代码用来把引号中的关键词从搜索引擎的关键词报告中排除，而当成直接点击量来源。

为什么要这么做？因为一个知名的大网站，来自这些品牌词的搜索流量都非常大，常常是排在前几位的搜索关键词来源，而这通常是因为搜索引擎养成现在的人都懒得记网址，直接搜索品牌名来记住域名。这些品牌词对于网站的关键词来源分析并没有很直接的帮助，所以在来自品牌词的流量很大的情况下，可以直接把这些关键词识别成直接点击量来源。

关于自定义 Google Analytics 搜索引擎和排除特定关键词为直接点击量来源的语法，可以参考 Google Code 上关于这方面的详细介绍。

通过 _setVar 识别用户

当我们登录豆瓣后，再来分析豆瓣的源码，会发现多了一个ga._setVar(”xxxx”)的 Google Analytics 参数。

豆瓣使用 Google Analytics 的._setVar参数来跟踪登录用户行为

_setVar() 函数是 Google Analytics 的用户定义函数，主要用于对特定来源的用户行为进行分类，例如可以对登录浏览的用户设置一个数值，然后在 Google Analytics 后台的访问者/用户定义 中查看其浏览属性。

Google Analytics 访问者/用户定义报告

分析豆瓣的源码可以知道，豆瓣对每一个登录后的用户，都赋以一个专门的 id 值，这样可以在用户定义报告里，看到整体的登录用户访问行为，乃至每个登录用户的浏览行为。通过这样设定后，豆瓣便可以轻易获取高忠诚度访问用户的访问行为。关于_setVar()的更多说明，请参阅 Google Analytics的技术文档

如何根据访问者在我的网站上访问的页面或在表单上做出的响应对其进行分类？在 Google Analytics 官方的帮助文件，也给出了另外一个应用案例

值得注意的是，原来在设置 _setVar() 函数的时候，整个网站的跳出率会出现重大的偏差，不过在最近的google analytics官方博客，指出该bug已经修正，客户在进行这方面设置的时候，还是要注意对比前后数据是否有重大偏差。

通过 _trackPageview 区分不同类型的评论

豆瓣上的书评，影评和乐评可以说是豆瓣网站的核心价值所在。一般评论的URL格式如下：

豆瓣上单条评论的URL

当我们查看该页面的网页源代码时，会发现有趣的现象:

豆瓣单条评论页的 Google Analytics 代码

我们知道，一般 Google Analytics 的_trackPageview() 括弧中的参数是留空的， Google Analytics 会自动捕获网址的 URL 参数，如果在 _trackPageview()括弧中输入特定的数值，那么在 Google Analytics 的报表中，URL 将是我们指定的参数，而不再是我们在地址栏看到的 URL。

如上面的例子，我们在 Google Analytics 中看到的URL将是/book/review/1946018/，而不再是我们在浏览器地址栏看到的/review/1946018/

当所在频道是电影或者音乐时，_trackPageview() 中的参数将根据所在频道的属性，变为/movie/xxxxx 或者 /music/xxxxx的数值。

豆瓣通过对的参数进行重新指定，主要有以下的好处：

保证了用户和搜索引擎看到的 URL 比较简短，达到 URL 对用户友好和对搜索引擎友好的目的；而在 Google Analytics 报告中，通过 内容/内容细目/ 报告，又能了解到各个频道总的浏览情况。

在GA的内容细目报告中，将会多出 /book/ /music/ /movie/ 这样的文件夹来，总而获得各个频道的合计浏览数据。

而如果只是使用默认 _trackPageview()，你将只能得到所有评论页面的浏览数据，而无法得到细分的各个频道的浏览数据。

关于_trackPageview()的具体的使用方法可参照 Google Code 的说明

注意事项:使用 _trackPageview() 参数重新指定 URL 之后，网站覆盖图的数据将受到影响。可参阅 Google Analytics 的官方帮助文件

除了豆瓣使用 _trackPageview() 来对URL进行重写，大众点评网也采用了类似的做法（应该是比豆瓣更早采用。。。因为是我在点评网任职时候实验的做法;那时候豆瓣还没有使用 Google Analytis 统计代码，呵呵），有兴趣的同学可以自己去研究点评的 Google Analytis 代码。

一、什么是索引？

索 引用来快速地寻找那些具有特定值的记录，所有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进行自动类型转换，因为转换过程也会使索引变得不起作用。

搜索引擎核心技术(PHP编程思路)

谈到网页搜索引擎时，大多数人都会想到雅虎。的确，雅虎开创了一个互联网络的搜索时代。然而，雅虎目前用于搜索网页的技术却并非该公司原先自己开发的。2000年8月，雅虎采用了Google（www.google.com）这家由斯坦福大学学生创建的风险公司的技术。理由非常简单，Google的搜索引擎比雅虎先前使用的技术能更快、更准确搜索到所需要的信息。

　　让我们自己来设计、开发一个强劲、高效的搜索引擎和数据库恐怕短时间内在技术、资金等方面是不可能的，不过，既然雅虎都在使用别人的技术，那么我们是不是也可以使用别人现成的搜索引擎网站呢？

剖析编程思路

　　我们可以这样设想：模拟一个查询，向某个搜索引擎网站发出相应格式的搜索命令，然后传回搜索结果，对结果的HTML代码进行分析，剥离多余的字符和代码，最后按所需要的格式显示在我们自己的网站页面里。

　　这样，问题的关键就在于，我们要选定一个搜索信息准确（这样我们的搜索才会更有意义啊）、速度快（因为我们分析搜索结果并显示需要额外的时间），搜索结果简洁（便于进行HTML源代码分析和剥离）的搜索网站，由于新一代搜索引擎Google的各种优良特性，这里我们选择它为例，来看看用PHP怎样实现后台对Google(www.google.com)搜索、前台个性化显示这一过程。

　　我们先来看看Google的查询命令的构成。进入www.google.com网站，在查询栏中输入“abcd”，点击查询按钮，我们可以发现浏览器的地址栏变成："http://www.google.com/search?q=abcd&btnG=Google%CB%D1%CB%F7& amp;hl=zh-CN&lr="，可见，Google是通过表单的get方式来传递查询参数并递交查询命令的。我们可以使用PHP中的 file()函数来模拟这个查询过程。

了解File（）函数

　　语法: array file(string filename);

　　返回值为数组，将文件全部读入数组变量中。这里的文件可以是本地的，也可以是远程的，远程文件必须指明所使用的协议。例如： result=file(“http://www.google.com/search?q=a  mp;hl=zh-CN&lr=”)，该语句将模拟我们在Google上查询单词“abcd”的过程，并将搜索结果以每行为元素，传回到数组变量 result中。因为这里读取的文件是远程的，所以协议名“http://”不能缺少。

　　如果要让用户输入搜索字符进行任意搜索，我们可以做一个输入文本框和提交按钮，并将上文中的被搜索字符“abcd”用变量替换：
<?php
echo '<form>'; //没有参数的form，默认提交方式为get，提交到本身
echo '<input type="text" name="keywords">'; //构造一个文本输入框
echo '<input type="submit" value="查询">'; //构造一个提交查询按钮
echo '</form>';

if (isset( keywords)) //提交后PHP会生成变量 kwywords,即要求下面的程序在提交后运行
{
urlencode( keywords); //对用户输入内容进行URL编码
result=file("http://www.google.com/search?q=". keywords."&btnG=Google%CB%D1%CB%F7&hl=zh-CN&lr=");
//对查询语句进行变量替换,将查询结果保存在数组变量 result中
result_string=join(" ", result); //将数组$result合并成字符串，各数组元素之间用空格粘和
 //进一步处理
}
?>

　　上面的这段程序已经能按用户输入内容进行查询，并将返回的结果合成一个字符串变量$result_string。请注意要使用urlencode()函数将用户输入内容进行URL编码，才可以正常地对输入的汉字、空格以及其他特殊字符进行查询，这样做也是尽可能逼真地模拟Google的查询命令，保证搜索结果的正确性。

对Google的分析

　　为了便于理解，现在假设我们所真正需要的东西是：搜索结果的标题。网址和简介等，这是一个简洁而典型的需求。这样，我们所要做的便是：去除Google搜索结果的台头和脚注，包括一个Google的标志、再次搜索的输入框和搜索结果说明等，并且在剩余的搜索结果各项条目中剥离原来的HTML格式标记，替换成我们想要的格式。

　　要做到这一点，我们必须仔细地分析Google搜索结果的HTML源码，找到其中的规律。不难发现，在Google的搜索结果的正文总是包含在源码的第一个<p>标记和倒数第二个<p>标记之间，并且倒数第二个<p>标记后紧跟table字符，而且这个组合 “<p><table”在源码中也仅有一次，利用这个特点，我们可以这样去除Google的台头和脚注。

　　以下所有程序均依次接续在上文程序的“进一步处理”处。

　　result_string = strstr( result_string, "<p>"); //取 result_string从第一个<p>开始后的字符串，以去除Google台头
position= strpos( result_string,"<p>table符号的位置
result_string= substr( result_string,0, position);//截取第一个<p>table符号之前的字符串,以去除脚注

应用与实现

　　OK，现在我们已经得到有用的HTML源码主干了，剩下的问题是如何自主地显示这些内容。我们再分析一下这些搜索结果条目，发现每个条目之间也是很有规律的用
分隔，也就是各成一个段落，按这个特点我们用explode()函数把每个条目切开：

　　语法：explode(string separator, string string);

　　返回一个数组，按separator切开后的各个小字串被保存在数组中。

　　于是：
result_array=explode("<p>", result_string); //用字串"<p>"把结果切开

　　我们就得到一个数组 result_array，其中每个元素都是一个搜索结果条目。我们所要做的仅仅是研究每个条目及其HTML显示格式代码，然后按要求替换就行了。下面用循环来处理 result_array中的每个条目。
for( i=0; i {
 //处理每个条目
}

　　对于每个条目，我们也很容易找到一些特点：每个条目都由标题、摘要、简介、类别、网址等组成，每个部分都换行，即包含<br>标记，于是再次分割：（以下处理程序放在上文的循环中）
every_item=explode("<br>", result_array[ i]);

　　这样我们得到一个数组 every_item，其中 every_item[0]就是标题， every_item[1]和 every_item[2]两行为摘要， every_item[3]和 every_item[4]等等的头部如果包含“<font size=-1 color=#6f6f6f >简介:</font>”、“<font size=-1 color=#6f6f6f>类别:</font>”字符，则是简介或类别（因为有的结果条目没有该项），如果头部包含“< font color=green>”则肯定就是网址啦，这种对比判断我们常使用正则表达式（略），如果要替换也很方便，比如包含标题的$every_item[0]，其本身是有链接的，我们希望修改这个链接属性，让它在新窗口打开链接：
echo eregi_replace(' {
 //处理每个条目中除去第一项（第一项为标题，已经显示）的每一项
 //更多格式修改
}

　　这样就修改了链接属性，其余很多显示格式的修改、剥离、替换都能用正则替换eregi_replace()来完成。

　　至此我们已经得到了每个搜索条目的每一项，并能任意修改每项的格式，甚至可以给他套上漂亮的表格。然而一个好的程序应该能适应各种运行环境的，这里也不例外，我们其实还只是讨论了搜索结果的HTML剥离的一种框架方法，真正要做得完美，还要考虑很多内容，比如要显示一共搜索出多少结果，分成多少页等等，甚至还可以刨除与Google相关的那些“类别”、“简介”等代码，让客户根本看不到原始网站。不过这些内容和要求我们都能通过分析HTML进行剥离得到。现在大家完全能自己动手，做个极富个性化的搜索引擎啦。