网页优化之DNS和页面预拉取
网站优化之预拉取分作两个方面来讨论，一个方面是页面元素的预拉取，一个方面是DNS的预拉取。
一 首先来说说DNS的预拉取
DNS 实现域名到IP的映射。通过域名访问站点，如果DNS信息不在缓存中话，每次请求都要做DNS解析。目前每次DNS解析，通常在200ms以下。针对DNS解析耗时问题，一些浏览器通过DNS 预拉取 来提高访问的流畅性。
DNS 预拉取是一种DNS 预解析技术，当你浏览网页时，浏览器会在加载网页时对网页中的链接或者link中的href的域名进行解析缓存，整个操作是并行地运行在后台，不会影响当前的用户体验；这样在用户真正单击当前网页中的连接时就无需进行DNS的解析，减少用户等待时间，提高用户体验。
不仅客户端可以通过配置项来控制是否开启DNS缓存，服务器也是可以控制的，通过HTTP协议头部增加x-dns-prefetch-control为on或者off或者直接在页面中通过meta信息来进行控制：<meta http-equiv="x-dns-prefetch-control" content="off">
对于网页开发者而言，可以通过link标签来强制对某一个域名进行DNS的预拉取：
<link rel="dns-prefetch" href="http://www.qq.com/">
Firefox的话，可以通过about:config中的network.dnsCacheEntries和network.dnsCacheExpiration 来调整DNS缓存的大小和过期的时间。默认的过期时间是60秒。
Firefox的DNS缓存设置插件：
https://addons.mozilla.org/zh-CN/firefox/addon/5914/
目前支持 DNS Prefetch 的浏览器有 google chrome 和 firefox 3.5
对于chrome而言，可以通过about:histograms 命令，查询DNS.PrefetchQueue可以看到相关的dns缓存的情况。
参考文档：
https://developer.mozilla.org/En/Controlling_DNS_prefetching
备注：
IE浏览器4.x以后的版本，DNS缓存默认的时间是10分钟，可以通过修改注册表来达到修改这个默认缓存时间。
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
在编辑菜单上，单击添加数值，然后添加以下注册表值：
数值名称：DnsCacheTimeout
数据类型：REG_DWORD
基数：十进制
数值：（以秒为单位的时间）
二 页面元素预拉取
用户在打开首页后，如果停留较长时间，而且根据统计得知用户进入某些个二级页面的概率很高，如在x.soso.com这样的站点，从首页到某一个电影的详情页，这样的概率是很高的。
如何在首页或者网站入口的地方，为后面的一些常常需要访问的页面做一些后续页面元素预拉取操作呢，通过预拉取提高后续页面的访问速度。
对于firefox而言，页面元素的预拉取变得比较简单一些，通过link标签或者meta标签就可以实现预拉取：
<link rel="prefetch" href="/images/big.jpeg"> 通过将rel的值设置为prefetch或者next就可以进行预拉取。
<meta http-equiv="Link" content="/images/big.jpeg; rel=prefetch">
Firefox浏览器会判断当前页面空闲的时候才会去拉取指定的预拉取的元素，而且对于预拉取的元素也会带上当前页面作为引用页(避免一些防盗链设置)，和添加一些特定的http头部X-moz: prefetch便于服务器进行标识。
<html>
<head>
<title>firefox prefetch</title>
<link href="http://ime.qq.com/fcgi-bin/getword?key=0f2bff76ec96181f1078250ba3e8245f&cb=window.QQWebIME.callback402&q=fgh&p=5" rel="prefetch"></link>
<meta http-equiv="Link" content="http://articles.csdn.net/uploads/allimg/100928/100QK645-0.jpg; rel=prefetch">
</head>
<body>
firefox prefetch test
<p>
normal image<br/>
<img src="http://img.cnbeta.com/newsimg/100924/11502901065691984.jpg"></img><br/>
</p>
</body>
</html>
Firefox下通过about:cache?device=disk命令可以实时查看到页面元素的缓存情况，模仿上面的例子你就会看到在firebug下抓不到包的请求，这里会有缓存的。
参考文档：
https://developer.mozilla.org/en/Link_prefetching_FAQ
IE下的一些插件如IE Pro可以实现累死的预拉取的功能：
http://www.downloadsquad.com/2008/05/20/ie7pro-2-3-adds-prefetching-session-management-to-internet-expl/
Chrome的一些插件也可以实现类似的功能：
https://chrome.google.com/extensions/detail/lcgjcablhbecaaheaiebnjingaocdmdf
总结：
对于预拉取而言，都会额外的耗费一些带宽，只有在有必要的时候才去实施。如qzone这种会弹出一个引导页面的时候，可以做一些用户博客元素的预拉取；另一方面，国内的浏览器大多还是ie，这种情况下通过一些简单的标记是很难实现预拉取的，这时需要通过js在业务层来实现预拉取，一般而言，最好是通过js来判断当前页面已经onload完毕，然后通过new Image的方式来预拉取一些想要拉取的元素。如果有必要，尽量将这种预拉取的操作放到清晨或者夜深的时候才来做。
DNS的预拉取在手机上来实现是比较好的，手机上打开页面的速度比较慢，正好可以并行的来进行预拉取的动作。
页面元素的预拉取对于一些页面元素相对较多，如很多CSS和JS文件、大的图片文件的时候以及一些常用页面里面一些变动比较大的页面元素的时候，这个时候进行预拉取的效果会更好一些。如果用户不需要的话，毕竟预拉取会浪费用户和服务器的带宽。
在我们的页面中，如果不是显示指出来的话，javascript是同步加载的，也就是javascript的加载是阻塞的，后面的元素需要等待javascript加载完毕后才能进行再加载。呵呵，对于一些意义不是很大的javascript，如果放在页面的头部，如果加载很慢的话，会严重影响用户的体验的。
有人会问这时为什么呢？因为有可能你的javascript代码会动态的植入一些元素到页面的dom中。
因此对于那些会有修改dom的javascript（最简单如里面会有document.writlen这样的语句），我们只能阻塞的加载，而且最好也是放在页面的最底部。但是对于那些不会导致dom修改的javascript，如一些统计的javascript，如google的统计等，我们完全可以异步的来加载，不必同步阻塞的来等待。如何异步加载一个javascript文件呢？
一 defer方式
在w3c的html中定义的script标签有一个defer的属性，这个属性开启的话表示这段javascript代码可以延迟加载。
<!ELEMENT SCRIPT - - %Script; -- script statements -->
<!ATTLIST SCRIPT
charset %Charset; #IMPLIED -- char encoding of linked resource --
type ...
我们写的javascript不一定都能保证是没有问题，可能在某些特殊的环境下，后者某些浏览器上，某些用户的cookie环境等导致javascript代码执行出错。这个时候我们需要知道javascript代码执行有问题，从而在下一个版本中解决这个问题。
怎么来发现我们的javascript代码有问题呢，通过damnit网站提供的工具可以方便的解决这个问题。
1 在ie和firefox下onerror这个事件，当javascript代码执行出错的时候，会触发这个事件，我们添加这个事件的处理函数，在处理函数里面添加上报即可。
如果需要利用 onerror 事件，就必须创建一个处理错误的函数。你可以把这个函数叫作 onerror 事件处理器 (onerror event handler)。这个事件处理器使用三个参数来调用：msg（错误消息）、url（发生错误的页面的 url）、line（发生错误的代码行）
onerror=handleErr
var txt=""
function handleErr(msg,url,l)
{
txt="There was an error on this page.\n\n"
txt+="Error: " + msg + "\n"
txt+="URL: " + url + "\n"
txt+="Line: " + l + "\n\n"
txt+="Click OK to continue.\n\n"
alert(txt);
return ...
Cookie是什么，估计搞了很久的web开发人员也会很困惑，path是什么意思，secure是什么意思，时间是什么意思....
我也是困扰了很久。cookie到底是什么？使用的过程中需要注意一些什么？经过一番折腾之后，终于忍不住开完了rfc的英文文档，事情终于解决了，一切恢复了平静。且让我慢慢到来，cookie到底是什么。
通过抓包可以比较方便的看到一次服务器端返回的cookie的样子：
Set-Cookie：customer=test; path=/; domain=test.com; expires= Wednesday, 19-MAY-10 23:12:40 GMT; [secure];
其中每个属性的解释:
customer=test; 这个键值对表示的是想要传递的信息，键叫做customer，值是test
domain: 关联的域名,例如www.qq.com, 它的domain = test.com,该domain默认为当前请求的域,但是如果cookie中domain的值和请求的域不相符的话,这个cookie就会被忽略.
path: 控制哪些网站上目录的访问能触发发送.例如请求的地址是上面的URL,如果path=/,这个cookie就会被发送,但是path为其他的话,该cookie会被忽略.
expires: cookie的过期时间,这里的时间是GMT格林威治时间，不是我们中国当前的时间哦，GMT加上8个小时就是我们的中国的北京时间了。如果没有明确填写这里的话，表示这是一个会话cookie，只是在浏览器的一次回话中有用，一旦浏览器关闭这个cookie就不存在了，很多登陆使用到cookie会使用会话cookie。expires还有一个用处就是在服务器想要清除一个cookie的时候，只需要设置expires为当前时间之前的一个时间，如设置为1970年，这样的话浏览器就会把cookie清除掉了，因为已经过期。
secure: 如果secure 这个词被作为Set-Cookie 头的一部分，那么cookie 只能通过安全通道传输（目前即SSL通道）。否则，浏览器将忽略此Cookie，这里一般是在https时才有用。
看看rfc中对cookie中的几个字段的详细解释吧：
set-cookie = "Set-Cookie:" cookies
cookies ...
在众多的网站优化手册中，你会听到很多这样的说法，有的说要开启服务器的etag，有的说不要。
但是很少有人说不开启 Last-Modified，这是为什么呢，ETAG和Last-Modified之间又有什么关系呢。
Etag和Last-Modified都是有服务器端生成，并且随着文件的改变而改变，这样浏览器端就会只重新请求时，服务器会根据之前返回的etag值和last-modified的值来判断请求的文件是否发生变化，
如果没有变化的话，就给请求的agent（一般理解为浏览器）一个304的http头部，not modified的回应，告诉agent说你本地的文件还是新的，目前服务器还没有变更，你就拿本地的来用吧。从而减少浏览器端和agent端数据的流量（想想如果每次请求都返回完整的内容，当访问量大的时候，流量的有多大），加快浏览器的反应速度；另一方面，也减轻服务器端的压力，提高了服务器并发的能力。所以服务器端Etag和last modified配置上都比较重要。
呵呵，那么etag和last modified之间有什么不同点呢？
任何东东的出现都是有原因的，last modified只能精确到秒，如果一个文件1秒内被改了好些次，那么last moidfied就没有用了；再或者分布式部署的时候，由于机子的时钟有可能不一样，用户从一台机子到另外一台机子的时候，last modified就没有用了。于是etag这个类似基于文件唯一标识的hash的就出现了，这样的话，不管你服务器怎么变化，不管你1秒变化多少次，只要唯一标识的hash不变，文件不变。
一般而言，etag是根据文件的innode（文件的索引节点值）以及mtime（文件修改时间）以及size（文件大小）三个部分组成。但是这里也还是有点问题的，因为不同的服务器上，文件的innode节点有可能是不一样的，所以在配置的时候需要小心，根据自己系统的特点选择唯一的标识。但是在集群服务器上，这个是很难实现的，于是乎就有的网站优化手册里建议你关闭etag这个选项，也是有道理的。不过明晰事情的真相后，自己也可以根据自己的业务特点来使用了。
呵呵，有的服务器etag和last modified都使用了。那么web服务器处理这两个条件的优先级如何呢？（这个估计很少人去追究了）
通过跟踪了一下apache1.3的源码，得知etag的优先级高于last modified。呵呵，所以yahoo的优化法则上说关闭etag，不无道理晒。
看看apache的源码，让你来个明白：
关注加黑部分，其它的都是一些参数检查和配置检查。
int set_last_modified(request_rec *r, time_t mtime)
{
char *etag, weak_etag[MAX_STRING_LEN];
char *if_match, *if_modified_since, *if_unmodified, *if_nonematch;
time_t now = time(NULL);
if (now < 0)
now = r->request_time;
table_set(r->headers_out, "Last-Modified",
gm_timestr_822(r->pool, (mtime > now) ? now : mtime));
/* Make an ETag header out of various pieces of information. We use
* the ...
网站优化之网站图标网站头像favicon.ico制作
现在很多浏览器都会在地址栏、收藏栏、tab页上面显示一个网站的图标。这个图标就是你站点根目录下的favicon.ico文件。这是浏览器默认的动作，通过抓包工具可以很明显的看到，如tt浏览器，没有缓存的情况下，打开页面的时候就回去get一下/favicon.ico。
当然也可以显示去指定,这样的话可以控制ico图片所在的路径，以及这个图片的格式。在html文件中加入如下的代码就好了：
<link rel="shortcut icon" href="你ico图片的url">
如何方便的来制作这个网站图标呢，参考如下的一些在线制作的工具，可以省去很大一部分的工作：
国产 制作ico图标 不过生成的ico文件稍微有一点大。
国外 制作ico图标 效果好一些。
更多参考和推荐
车东的博客还带有图片展示的，可以去看个究竟哦。
备注：
1 上传了ico到你的网站的根目录下后，如果通过地址获取的时候提示你保存的话，说明你的服务器不支持这种类型的mime-type，需要修改一下服务器的配置。
如lighttpd，在mime-type配置下，增加：
“.ico” => “image/x-icon”,
还不行的话，打开这个选项：mimetype.use-xattr = “enable”
2 对于很多服务器的设置都没有明显的针对ico类型的文件来设置过期时间的，由于ico文件很少进行变化，需要将其过期时间设置长一点。我的是一年。
lighttpd中修改配置如下：
$HTTP["url"] =~ “\.ico$” {
expire.url = ( “” => “access 1 years” )
}
3 如果你刷新了浏览器还是看不到你的网站图标的话，你需要清空一下浏览器的cache。重启浏览器试一下。
追加说明：
1 如果你没有设置favicon而且有空的话，看看你的web服务器的error log，你会看到大量的404请求，都是请求这个图片的。
所以加上这个 ...
网站优化之wordpress站点性能优化
对于偶们这些无钱购买大带宽、高性能服务器的同志来说。使用一个国外的性能差的vps，流量、网速的限制促使我们不得不对自己的小小站点进行优化。
让其能够稍微快一点的展现在访问者面前，对于web站点来说，速度是第一位的，其它都是第二位的。
所以对网站的优化就像呼吸，不能停止！
对于wordpress站点来说，优化的核心和重点主要就是静态话，减少页面元素的数量。呵呵，两者做到了，速度就上去了。
优化过程如下，不断更新中：
一 gzip
http://redmine.lighttpd.net/wiki/1/Docs:ModCompress
php:(这里需要注意php.ini的位置)
zlib.output_compression = On
zlib.output_handler = On
lighttpd:
compress.cache-dir = “/var/www/cache/”
compress.filetype = (”text/plain”, “text/html”)
二 expire
expire.url = ( “/wp-content/” => “access 1 years”,
“/wp-includes/” => “access 1 years”)
$HTTP["url"] =~ "\.(html|htm)$" {
expire.url = ( "" => "access 4 hours" )
}
#对于后台管理的目录也不放过:)
$HTTP["url"] =~ "^/wp-admin/" {
expire.url = ( "" => "access 1 years" )
}
三 静态化
安装cos-html-cache插件，使得站点的页面静态化
配置lighttpd支持404的处理
server.error-handler-404 = “/index.php”
四 合并css以及js文件
通过firebug或者fiddler来抓包，分析css和js加载的顺序，将这些css并入到一个文件中，然后通过css整理工具，将其中的无用的字符如空格、回车换行等信息去掉。
css整理工具，csscompressor：
css整理工具，csscompressor
工具使用和相关信息参考我的博客：
css压缩工具 网站优化
js整理工具，jsmin.
然后修改主题模板对应的header-default.php
将原来导入css和js的地方替换为新生成的js和css
五 ...
网站优化之数据库性能优化
数据库往往是很多站点的瓶颈，根据业务需要，根据使用需要，根据常用的sql语句去优化数据库往往能够得到一些事半功倍的效果
今天同学说它用的drp系统当有10来个并发用户时，就表现得很慢了，问我原因。
我初步定位一下，发现是数据库的问题。就我之前也曾遇到同样的问题，故总结一下，避免他人遇到同样的问题，少走弯路：
一天，你发现你的系统的并发能力下降，看看是不是你的数据库出问题了。
1 你的数据库的表是不是很大了，select count(*) from *** 看一下你的表中的记录数是不是太多了。
如果太多的话，建议你按照逻辑的分数据库，然后在表中寻找一个字段来进行分表，将每个表中的记录数减少。
在一个太多记录的表中进行查询和更新都是很低效率的，最简单的道理是会导致大量的读写磁盘操作。
2 查看表的定义，show create table ***，看看是不是你的表的字段上的索引建的太多了。
如果太多，建议合并或者去掉一些索引，过多的索引会让更新数据变慢，因为更新数据时还需要同时更新这些数据对应的索引信息。
对于一些需要查询或者group by的字段，加上索引。
3 上面两点你都做了，如果还没有改善，那么需要修改一下你的数据库服务器的配置了。
检查你服务器的并发设置，有的服务器默认的并发量是很小的。
将你的数据库服务器的查询cache设置大一些，索引cache也设置大一些，缓存cache设置大一些，每个连接的cache也设置大一些。
如果你的表不是很大，而且要求实时的相应的话，如用户信息，最好使用完全内存映射这样的模式，如mysql中内存。
4 做了上述优化，还是不行的话，看看你的操作系统的设置了，是不是你的操作系统对并发用户数的限制啥的。
5 如果你有很多的时间和精力，而且你的服务器读请求很多的话，给你的数据库服务器加个cache，让大量的读操作能够让cache来满足。
6 如果你没有很多的时间和精力，给你的数据库服务器做热备份，在热备份的机子上做读操作。
7 还是不行的话，看看是不是你的机子的硬件性能不好，是不是网络问题了，更换更好的硬件，选择更高的带块吧，这个是最好的方式了。
写在最后的话：
数据库的索引很重要，mysql的存储引擎的选择很重要。
1 对于数据量大的系统，每当你查询、order by等等操作的时候 ，尽量先explain一下你的sql语句，看看是否使用了索引。
mysql的索引是使用B树来建立索引的，所以对于多字段组合的复合索引，where条件中的字段是按照左优先的顺序来使用索引。
如果不明白的话，看看B树的数据结构就明白，只有从左到右的顺序来使用索引才能取得索引的效果。
2 对于并发量很大的请求，建议使用mysql的innodb这种存储引擎，基于行的lock锁，能够支持到较大并发的更新。一般常用的myisam是基于表锁的，这种引擎在
并发量很大的写操作方便基本不占任何的优势。
3 根据业务的需要，分库分表是很重要的，将数据量按照一定的规则来取模，将数据量变小，这样查询和插入都能够得到很好的速度。
4 如果你比较怕麻烦来根据mysql的show status来对mysql的配置参数进行优化，可以使用这位牛人写的脚本来帮助你进行处理
mysql的性能诊断利器:http://www.day32.com/MySQL/
5 如果上述还不能解决你的问题，那就在业务层借助memcached这样的cache来帮忙吧。尽量将请求从cache中获得数据，从而减少mysql的压力
网站优化之数据库优化
数据库在当前的各个网站中的地位是不言而喻的。但是对数据库关心的人却是比较少的。
如何去根据业务的需要建表，根据业务的需要去为特定的字段建立索引。
对于记录数量少于一万条的站点来岁，优化似乎是没有必要的，但是对于一个记录数量在十万条以上的站点，对于
数据库的优化就是势在必行的了。优化前后的效果也是会给你带来震撼和惊喜的。
目前web2.0的程序，很大瓶颈是数据库的吞度量。不过，如何才能确定系统的瓶颈是数据库呢，
因为只有确定数据库是整个系统的瓶颈，我们才有必要去优化他，毕竟，还有这么多需求等待我们去做。
如何确定数据库是瓶颈？
1 如果程序设计良好，有一个数据库操作逻辑层，可以从这个层的统计数据看到每个请求花费的时间，
如果平均时间已经不能让你容忍的话，数据库已经是瓶颈了。
2 在数据库的服务器上使用top命令，看看mysql服务器占用资源的情况，看看机子的平均负载。
如果服务器的平均负载已经很高，mysql占用了块100%的cpu资源，说明mysql服务器很忙了。
3 在数据库服务器上使用iostat命令，看看磁盘IO，如果block住的操作比较多的话，
说明数据库操作还是过于频繁了，磁盘都响应不急了。
4 建议打开mysql的慢查询日志，这样grep select看一下日志中的慢查询的数量，
如果数量较多，说明慢查询的数量很多，需要进行调整了。
5 如果有一天数据库无法插入了，需要检查一下数据库表是不是过大了。32位的操作系统上一个表
最大的容量是2^32这么大。
不过还是建议增加一个数据库操作的逻辑层，在数据库操作的前后记录下操作的时间，
进行统计上报，利用监控程序来报警相关负责人，这样可以及早的知道数据库是瓶颈，提前做出优化。
知道数据库是瓶颈了，如何来进行优化呢？
1 我们第一个想到是看看数据库的容量是不是太大了，如果数据库表太大的话，
索引文件也会比较大，每次的更新操作就会更加的费时。需要考虑进行分库和分表了。
分库分表按照一定的规则来对数据库中的记录进行分区来存储，一方面可以做到一定的
负载均衡，将请求平分下来，每个区段去独自承受；另一方面，分库分表可以使我们
存储和操作更多的数据。
不过分库分表需要多之前基于单库的程序进行修改，存在一定的风险，因此，在程序设计
之初就应该考虑到分库分表的需要，最好是将数据库操作层独立出来，便于扩展和更改。
2 如果数据库表不是很大，但是查询慢的话，我们需要检查一下我们的sql查询语句，
利用mysql的explain语句看看是不是使用了索引，如果没有使用索引，那我们需要在
相应的字段上建上索引，反复的使用explain，寻找到个一个合适的索引。
在建索引时需要考虑：
1）数据库的索引要做到越少越好
因为每次更新都需要更新索引，索引过多就会降低写入的速度
2）最窄的字段放在键的左边
这样提高了索引中每一个点的基数，带来更好的索引读写性能
3）尽量避免file sort排序、临时表和表扫描
对于大表，全表扫描会导致大量的磁盘IO的操作，会导致操作非常的缓慢
4）对于大表，尽量不要将索引建在字符串类型的列上，字符串的匹配是很费时的，需要
付出很高的性能代价，如果一定有必要，建议对字符串列进行hash后取一个整形的值来进行
索引。
3 如果更新操作有点慢，而读操作的响应要求不需要很及时的话，可以考虑利用mysql的主从
热备来分担读写的压力。
毕竟对数据库的操作，写少读多。因此，我们将对数据库的写操作放到mysql的主服务器上，
利用mysql的热备，我们在备份的数据库服务器上进行读操作，由于可以有多个热备mysql，
于是可以将读操作分布在多个热备上面，从而将读操作均衡开来，提高读操作的性能。
4 缓存的使用
缓存是一切后台程序的根本，因为80%的请求是对应20%的数据，我们只需要少量的内存将20%的
数据缓存起来，就可以大大的满足我们系统需求，何乐而不为呢。
1）mysql设置中尽量增加key cache，thread cache、查询的cache
2）在应用程序层增加一个memcached这样的通用cache
3）对于少量数据，但是操作频繁的表使用mysql提供的内存heap表，可以获得极高的写入和读取速度
5 数据库的设计上进行优化
对于传统的数据库设计我们讲究建模范式，避免数据的冗余从而导致脏数据。然而在我们实际的
应用中需要根据情况来使用第三范式的一些规则，对于一些频繁需要在多个地方出现的数据，如同
一个论坛这种用户和主题以及回复等有关联的应用中，如果我们将用户同主题和回复分开来存储，
每次查询一下一篇文章或者一个回复的情况都需要对用户表和主题表或者回复表进行联查，如果数据量
小的话，这样联查的性能还是可以接受的，如果表大一点，上了3、4十万以上的数据，联查的速度就
会比较慢了。
该范式化的地方需要进行范式化，但是还是需要根据情况来设计我们的表，从而达到性能和良好设计的折中。
其它的话：
1 对于数据库的操作建议分层处理，至少分为两层，一层是数据库操作的逻辑层，一层是数据库的cache层。
从一开始就考虑如此，可以很方便在未来对数据库进行划分部署、分库分表扩展
2 增加mysql的监控，监控mysql的慢查询日志，监控mysql的请求情况
3 根据自己的需要来选择mysql的存储引擎
myisam有较高的读写速度，但是由于表锁定，不能同时进行快速的读和写。
innodb支持事务，提供了行级的锁，但是为了使用事务，表空间会比较大，而且不支持全文索引
heap将表放到内存中，适合与表小而需要频繁操作的情况，如用户信息，其读写很快，但是不是持久的，
需要自己来写工具让其持久
4 mysql服务器的一些状态检测的命令
show slave status：可以看到主从同步的情况
show [full] processlist：可以看到mysql服务器的请求情况，如果发现lock情况很多，需要注意了
show status：可以看到mysql服务器的各种请求情况
针对mysql的优化还没有结束呢，这里还有很多优化的地方，后续会有专门的文章来介绍的！一起期待吧...
网站优化之系统瓶颈查找
网站响应慢了，用户开始埋怨，老大安排你去优化，可是优化如何开始呢。
优化开始前一定要理清思路，问自己，网站的瓶颈在哪里。
系统的瓶颈在何方呢?如果你的系统有完善的监控分析系统的话，可以从统计数据和图形上
看到大致的系统瓶颈所在，但是如果你的系统没有这些数据，你又如何来确定系统的瓶颈呢。
按照一般的思路，我们对系统进行逻辑功能的划分，如静态服务器，动态服务器，
数据库服务器，业务逻辑服务器。分别针对对这些服务器的带宽、内存使用、cpu使用率、磁盘使用情况进行
分析，如对于动态服务器而言，其cpu的使用率一般情况下是其瓶颈；而对于静态文件服务器，
由于其逻辑简单，但需要传输大量的文件，其出口的带宽很有可能是其瓶颈；对于数据库服务器，
cpu和磁盘都有可能是瓶颈。
我们可以通过如下几个方面来进行查找和排除：
1 网络带宽
带宽可能是最直接的一个瓶颈，可以很容易的估计到。
假如运营商给你提供了10M的带宽，注意带宽的单位是bit，
如果你的一个页面的大小是10K字节，那么一秒钟的最多的并发量这样计算：
10*1024/8/10=128
如果每秒并发超过这个数字，你的带宽就无法接受了。
或者通过netstat命令来观察一下你的网络收发包的情况，使用netstat -s来观察一些统计
的数据，如果发现等待包队列里总是有大量的包待处理，一方面说明可能你的程序有问题，
另一方面说明可能你的并发量太大，系统已经处理不过来了，可能已经开始丢包了。
按照这个两个思路去检查吧。
2 CPU
如果带宽不是问题，又有这么大的并发量，下一个很容易是问题的就是你的cpu了。
如果你的网站有大量的动态请求，如php操作数据库后再返回，
cgi代码逻辑里有大量的排序等耗费cpu的操作，或者是你的cgi程序
写的不好，会死循环，这时你的cpu就将成为瓶颈。
在linux上试试top命令，看看你的机子的负载，通过最右上角的1分钟、5、15分钟采样的平均负载可以
看到你的机子在一段时间内的一个负载情况，如果过去15分钟你的机子的负载大于你的cpu的数目*5，
说明你的机子很繁忙了，很多进程都需要等待处理了。
或者vmstat -n 1命令，看看你的cpu idle的时间有多少，等待处理的进程数量有多少，磁盘块的读写有多少。
如果cpu idle的时间很少，或者等待处理的进程数量很多，说明你的系统比较繁忙。
3 磁盘操作
如果你的带宽很大，cpu比较的空闲，接下来的瓶颈很可能是磁盘的io操作了。
从内存读取数据是相当快的，但是从硬盘读取数据是内存读取数据的50到100倍的时间，
使用iostat -dx查看一下你的硬盘操作的情况，如果有大量的block阻塞着等待写入到硬盘，
你需要检查一下你的代码，看看是否有大量的日志操作，或者写文件的操作阻塞住了。
4 业务逻辑服务器响应慢
如果上述都ok，而且你的cgi又连接到其它的业务逻辑服务器请求数据的情况，你需要检查
你与业务逻辑服务器之间的连接是否正常，带宽是否够用，你的业务逻辑服务器的性能如何。
5 内存不够用
对于一些大容量缓存的业务服务器，如果缓存过多的内容，淘汰策略不好的话，会导致使用掉过多的内存，
从而引起操作系统进行大量的swap交换，进而影响到系统的性能，成为瓶颈。
通过ipcs -a观看系统的使用的共享内存的情况，如果共享内存使用太多的话，考虑较少一点共享内存的大小。
使用free来来观察系统的内存使用情况，如果发现空闲的内存空间少，使用top命令，然后ctl+M看看
那些进程占用了大量的内存，适当关掉一些进程，部署在其它的服务器上。