QQ收不到自定义表情在是非常痛苦的事情，所以DDWT.NET教给大家如何结局决QQ无法显示自定义表情的故障。
具体步骤如下：
第一步：备份我们的聊天记录
像聊天记录，这样重要的历史资料怎么能轻易删除呢!所以首先我们需要点击QQ面板左下角的“菜单”按钮，选中“好友与资料”中的“消息管理器”，来对我们的聊天记录进行管理。这时会弹出消息管理器窗口，在窗口中，单击“导出”按钮下拉菜单中的“导出聊天记录为备份文件”，即可将备份文件保存在我们指定的文件夹内。
第二步：备份自定义表情图片
QQ中的自定义表情图片默认存于X:Program FilesTencentQQ目录下，您的QQ号码名目录下的CustomFaceRecv文件夹中(X：代表你的程序存储盘)。接下来我们就将这个文件夹中的所有图片都进行备份，保存在另外的备份文件夹中。
第三步：删除带有我们QQ号码的文件夹
现在我们就可以坦然地将X:Program FilesTencentQQ目录中带有我们QQ号码的文件夹彻底删除掉了。
第四步：重新登录QQ
重新登录后，你会发现QQ自定义表情不再是冷漠的自定义表情代码了，好景重现!欣喜吧~
第五步：导入聊天记录
还是用第一步中的方法打开“消息管理器”。反其道而行之，将我们备份的QQ备份文件导入即可。
第六步：导入自定义表情
如果还需要我们曾经惯用的自定义表情，我们也只要将刚刚在X:Program FilesTencentQQ你QQ号码CustomFaceRecv文件夹中备份的文件重新恢复到这个文件夹就可以了。
OK!大功告成，好好享受自在的自定义表情生活吧!
具体步骤如下：
第一步：备份我们的聊天记录
像聊天记录，这样重要的历史资料怎么能轻易删除呢!所以首先我们需要点击QQ面板左下角的“菜单”按钮，选中“好友与资料”中的“消息管理器”，来对我们的聊天记录进行管理。这时会弹出消息管理器窗口，在窗口中，单击“导出”按钮下拉菜单中的“导出聊天记录为备份文件”，即可将备份文件保存在我们指定的文件夹内。
第二步：备份自定义表情图片
QQ中的自定义表情图片默认存于X:Program FilesTencentQQ目录下，您的QQ号码名目录下的CustomFaceRecv文件夹中(X：代表你的程序存储盘)。接下来我们就将这个文件夹中的所有图片都进行备份，保存在另外的备份文件夹中。
第三步：删除带有我们QQ号码的文件夹
现在我们就可以坦然地将X:Program FilesTencentQQ目录中带有我们QQ号码的文件夹彻底删除掉了。
第四步：重新登录QQ
重新登录后，你会发现QQ自定义表情不再是冷漠的自定义表情代码了，好景重现!欣喜吧~
第五步：导入聊天记录
还是用第一步中的方法打开“消息管理器”。反其道而行之，将我们备份的QQ备份文件导入即可。
第六步：导入自定义表情
如果还需要我们曾经惯用的自定义表情，我们也只要将刚刚在X:Program FilesTencentQQ你QQ号码CustomFaceRecv文件夹中备份的文件重新恢复到这个文件夹就可以了。
OK!大功告成，好好享受自在的自定义表情生活吧!
眼睛疲倦的原因一般与眼泪的分泌有关，这要引起你的重视，并要加倍保护眼睛，而如果能在饮食中加入一些营养眼睛的食物，是最方便最有效的方法。
维他命A
不用多说，素有"护眼之必需"之称的维他命A，是预防眼干、视力衰退、夜盲症的良方，以胡萝卜及绿、黄的蔬菜及红枣含量最多。
维他命B
维他命B是视觉神经的营养来源之一，维他命B1不足，眼睛容易疲劳；维他命B2不足，容易引起角膜炎。可以多吃些芝麻、大豆、鲜奶、小麦胚芽等食物。
枸杞子
枸杞子清肝明目的疗效大家早已知道，因为它含有丰富的胡萝卜素，维他命A、B1、B2、C，钙、铁等，是健康眼睛的必需营养。
枸杞子的三种食疗配方：
1. 枸杞子+米：煮成粥后，加入一点白糖，能够治疗视力模糊及流泪的现象。
2. 枸杞子+菊花：用热水冲泡饮用，能使眼睛轻松、明亮。
3. 枸杞子+猪肝：煲汤具有清热、消除眼涩、消除因熬夜出现的黑眼圈。
决明子具有清肝明目及润肠的功效，能改善眼睛肿痛、红赤多泪，防止视力减弱。
还要学会睡觉
你知道吗?睡觉前喝什么水和睡眠的姿势都会影响你的眼睛状况。
1. 睡觉前不能喝过多的水，否则频繁起夜是一方面，还会引起眼泡明显的浮肿；另外，咖啡和茶，会让体内水分迅速挥发，眼睛也因而更容易干涩。
2.充足的睡眠，是消除眼睛疲倦的最佳方法，不过要注意睡姿，俯卧和侧睡往往会让眼尾出现皱纹，或出现眼肿现象，恰当的睡姿应该是仰卧而睡。
老人干眼症很常见，主要原因是由于泪液分泌减少及其质量发生变化引起。泪液是由两眼外上角的泪腺分泌的，藉眨眼活动涂抹在眼球表面，保持眼睛的滋润和光滑。泪液除水分外，还含有黏液和脂肪成分，在角膜表面保留时间较长。老人这些成分失调，泪膜容易消失，这也是眼干的原因之一。防治的方法是：注意保护眼睛，避免强光、高温刺激；看书、看电视或电脑屏幕不可时间过长；禁用阿托品类抑制腺体分泌的药物；间断补充鱼肝油丸或常吃点肝、猪肝食品；也中服用中药杞菊地黄丸；如眼干症状较重，可经眼科医生用人工泪液或1%甲基纤维素滴眼。
眼睛干涩疲劳的食疗方
使用电脑、看书、看电视时，您是否常觉得眼睛干涩、酸痛、疲劳？长时间使用眼睛而造成用眼过度，是眼睛疲劳的一大主因。眼睛疲劳的一般症状是视物稍久则模糊，有的甚至无法写作或阅读，眼睛干涩、头昏痛，严重时可出现恶心、呕吐等。另外，视疲劳还导致成年人发生近视或提前花眼，白内障、青光眼、视网膜剥离等眼疾也会伴随着用眼过度而来。
保护眼睛、防止视力伤害、减缓眼疲劳，除了光线适宜、保持正确的操作姿势、保证休息和做眼保健操之外，还有一条非常重要，那就是要给眼睛补充营养。
现代医学研究表明，维生素与眼疾的发生、视力的好坏有着非常密切的关系。用眼过多者，需要更多的眼睛所需的维生素及矿物质。合理补充眼睛所需的营养素，对保护眼睛、防止视力伤害、防治眼疾、提高视力非常重要。
所以，眼疲劳者要注意饮食和营养的平衡，平时多吃些粗粮、杂粮、红绿蔬菜、薯类、豆类、水果等含有维生素、蛋白质和纤维素的食物。现向大家介绍眼干涩食疗验方二则，可供参考。
1、黑豆核桃冲牛奶：
【原料】黑豆粉1匙，核桃仁泥1匙，牛奶1包，蜂蜜1匙。
【做法】将黑豆500克，炒熟后待冷，磨成粉。核桃仁500克，炒微焦去衣，待冷后捣如泥。取以上两种食品各1匙，冲入煮沸过的牛奶1杯后加入蜂蜜1匙，每天早晨或早餐后服用，或与早点共进。
【功效】黑豆含有丰富的蛋白质与维生素B1等，营养价值高，又因黑色食物入肾，配合核桃仁，可增加补肾力量，再加上牛奶和蜂蜜，这些食物含有较多的维生素B1、钙、磷等，能增强眼内肌力，加强调节功能，改善眼疲劳的症状。
2、枸杞桑葚粥
【原料】枸杞子5克，桑葚子5克，山药5克，红枣5个，粳米100克。
【做法】将上述原料熬成粥食用。
【功效】此方中的枸杞子、桑葚子能补肝肾，山药、红枣健脾胃。视力疲劳者如能每日早晚两餐，较长时间服用，既能消除眼疲劳症状，又能增强体质。
有益眼睛的食物
保护眼睛，除了平时注意劳逸结合，不要长时间连续看书、看电视、定时做眼睛保健操外，经常吃些有益于眼睛的食品，对保护眼睛也能起到很大的作用。那么，对眼睛有益的食物有哪些呢？
首先是瘦肉、禽肉、动物的内脏、鱼虾、奶类、蛋类、豆类等，它们含有丰富的蛋白质，而蛋白质又是组成细胞的主要成分，组织的修补更新需要不断地补充蛋白质。
其次，含有维生素A的食物也对眼睛有益。缺乏维生素A时，眼睛对黑暗环境的适应能力减退，严重的时候容易患夜盲症。每天摄入足够的维生素A还可以预防和治疗干眼病。维生素A的最好来源是各种动物的肝脏，而植物性的食物，如胡萝卜、苋菜、菠菜、韭菜、青椒、红心白薯以及水果中的桔子、杏子、柿子等。
除此之外，多吃含有维生素C的食物。因为维生素C是组成眼球水晶体的成分之一。如果缺乏维生素C就容易患水晶体浑浊的白内障病。维生素C丰富的食物有各种新鲜蔬菜和水果，其中尤以青椒、黄瓜、菜花、小白菜、鲜枣、生梨、桔子等含量最高。
维他命A
不用多说，素有"护眼之必需"之称的维他命A，是预防眼干、视力衰退、夜盲症的良方，以胡萝卜及绿、黄的蔬菜及红枣含量最多。
维他命B
维他命B是视觉神经的营养来源之一，维他命B1不足，眼睛容易疲劳；维他命B2不足，容易引起角膜炎。可以多吃些芝麻、大豆、鲜奶、小麦胚芽等食物。
枸杞子
枸杞子清肝明目的疗效大家早已知道，因为它含有丰富的胡萝卜素，维他命A、B1、B2、C，钙、铁等，是健康眼睛的必需营养。
枸杞子的三种食疗配方：
1. 枸杞子+米：煮成粥后，加入一点白糖，能够治疗视力模糊及流泪的现象。
2. 枸杞子+菊花：用热水冲泡饮用，能使眼睛轻松、明亮。
3. 枸杞子+猪肝：煲汤具有清热、消除眼涩、消除因熬夜出现的黑眼圈。
决明子具有清肝明目及润肠的功效，能改善眼睛肿痛、红赤多泪，防止视力减弱。
还要学会睡觉
你知道吗?睡觉前喝什么水和睡眠的姿势都会影响你的眼睛状况。
1. 睡觉前不能喝过多的水，否则频繁起夜是一方面，还会引起眼泡明显的浮肿；另外，咖啡和茶，会让体内水分迅速挥发，眼睛也因而更容易干涩。
2.充足的睡眠，是消除眼睛疲倦的最佳方法，不过要注意睡姿，俯卧和侧睡往往会让眼尾出现皱纹，或出现眼肿现象，恰当的睡姿应该是仰卧而睡。
老人干眼症很常见，主要原因是由于泪液分泌减少及其质量发生变化引起。泪液是由两眼外上角的泪腺分泌的，藉眨眼活动涂抹在眼球表面，保持眼睛的滋润和光滑。泪液除水分外，还含有黏液和脂肪成分，在角膜表面保留时间较长。老人这些成分失调，泪膜容易消失，这也是眼干的原因之一。防治的方法是：注意保护眼睛，避免强光、高温刺激；看书、看电视或电脑屏幕不可时间过长；禁用阿托品类抑制腺体分泌的药物；间断补充鱼肝油丸或常吃点肝、猪肝食品；也中服用中药杞菊地黄丸；如眼干症状较重，可经眼科医生用人工泪液或1%甲基纤维素滴眼。
眼睛干涩疲劳的食疗方
使用电脑、看书、看电视时，您是否常觉得眼睛干涩、酸痛、疲劳？长时间使用眼睛而造成用眼过度，是眼睛疲劳的一大主因。眼睛疲劳的一般症状是视物稍久则模糊，有的甚至无法写作或阅读，眼睛干涩、头昏痛，严重时可出现恶心、呕吐等。另外，视疲劳还导致成年人发生近视或提前花眼，白内障、青光眼、视网膜剥离等眼疾也会伴随着用眼过度而来。
保护眼睛、防止视力伤害、减缓眼疲劳，除了光线适宜、保持正确的操作姿势、保证休息和做眼保健操之外，还有一条非常重要，那就是要给眼睛补充营养。
现代医学研究表明，维生素与眼疾的发生、视力的好坏有着非常密切的关系。用眼过多者，需要更多的眼睛所需的维生素及矿物质。合理补充眼睛所需的营养素，对保护眼睛、防止视力伤害、防治眼疾、提高视力非常重要。
所以，眼疲劳者要注意饮食和营养的平衡，平时多吃些粗粮、杂粮、红绿蔬菜、薯类、豆类、水果等含有维生素、蛋白质和纤维素的食物。现向大家介绍眼干涩食疗验方二则，可供参考。
1、黑豆核桃冲牛奶：
【原料】黑豆粉1匙，核桃仁泥1匙，牛奶1包，蜂蜜1匙。
【做法】将黑豆500克，炒熟后待冷，磨成粉。核桃仁500克，炒微焦去衣，待冷后捣如泥。取以上两种食品各1匙，冲入煮沸过的牛奶1杯后加入蜂蜜1匙，每天早晨或早餐后服用，或与早点共进。
【功效】黑豆含有丰富的蛋白质与维生素B1等，营养价值高，又因黑色食物入肾，配合核桃仁，可增加补肾力量，再加上牛奶和蜂蜜，这些食物含有较多的维生素B1、钙、磷等，能增强眼内肌力，加强调节功能，改善眼疲劳的症状。
2、枸杞桑葚粥
【原料】枸杞子5克，桑葚子5克，山药5克，红枣5个，粳米100克。
【做法】将上述原料熬成粥食用。
【功效】此方中的枸杞子、桑葚子能补肝肾，山药、红枣健脾胃。视力疲劳者如能每日早晚两餐，较长时间服用，既能消除眼疲劳症状，又能增强体质。
有益眼睛的食物
保护眼睛，除了平时注意劳逸结合，不要长时间连续看书、看电视、定时做眼睛保健操外，经常吃些有益于眼睛的食品，对保护眼睛也能起到很大的作用。那么，对眼睛有益的食物有哪些呢？
首先是瘦肉、禽肉、动物的内脏、鱼虾、奶类、蛋类、豆类等，它们含有丰富的蛋白质，而蛋白质又是组成细胞的主要成分，组织的修补更新需要不断地补充蛋白质。
其次，含有维生素A的食物也对眼睛有益。缺乏维生素A时，眼睛对黑暗环境的适应能力减退，严重的时候容易患夜盲症。每天摄入足够的维生素A还可以预防和治疗干眼病。维生素A的最好来源是各种动物的肝脏，而植物性的食物，如胡萝卜、苋菜、菠菜、韭菜、青椒、红心白薯以及水果中的桔子、杏子、柿子等。
除此之外，多吃含有维生素C的食物。因为维生素C是组成眼球水晶体的成分之一。如果缺乏维生素C就容易患水晶体浑浊的白内障病。维生素C丰富的食物有各种新鲜蔬菜和水果，其中尤以青椒、黄瓜、菜花、小白菜、鲜枣、生梨、桔子等含量最高。
3月28日，中国移动通信集团公司对外宣布，为进一步推动TD-SCDMA(简称TD)技术和产业的成熟，将于4月1日起面向北京、上海、天津、沈阳、广州、深圳、厦门和秦皇岛8个城市，正式启动TD社会化业务测试和试商用工作，并公布了3G手机收费标准。
据悉，中国移动此次向试商用客户提供十分优惠的三款TD套餐和数据卡套餐，语音资费比当前G网水平略低。在试商用期间客户在TD网所发生的通信费用，享受高达五折的优惠。
3G时代还真的来了，你准备好迎接了没有？先把手上的手机用烂掉再说吧，最主要的是等3G手机终端价格再降下，因为从资费来看，似乎没有太大门槛，但是手机购买价估计是个门槛。
附表：
TD-SCDMA试商用标准资费
月租费
50元/月
本地基本通话费
主叫0.40元/分钟，被叫免费
国内漫游通话费
0.60元/分钟，被叫0.40元/分钟
国内长途通话费
0.07元/6秒
短信息费
发送网内0.1元/条，网外0.15元/条，接收免费
可视电话资费标准
本地通信
主叫0.6元/分钟，被叫免费
国内漫游
主叫0.9元/分钟，被叫0.60元/分钟
国内长途
0.10元/6秒
说明：上述国内漫游、国内长途资费均不含港澳台通信资费，港澳台、国际长途资费标准参照现有GSM网相关资费标准执行。
视图是MySQL 5.0中增加的三大新功能之一（另外两个是存储过程与触发器），也是一般稍微“高级”一点的数据库所必需要有的功能。MySQL在定义视图上没什么限制，基本上所有的查询都可定义为视图，并且也支持可更新视图（当然只有在视图和行列与基础表的行列之间存在一一对应关系时才能更新），因此从功能上说MySQL的视图功能已经很完善了。
然而若要在应用中使用视图，还需要了解处理视图时的性能，而MySQL在这方面问题是比较大的，需要特别注意。首先要知道MySQL在处理视图时有两种算法，分别称为MERGE和TEMPTABLE。在执行"CREATE VIEW"语句时可以指定使用哪种算法。所谓MERGE是指在处理涉及到视图的操作时，将对视图的操作根据视图的定义进行展开，有点类似于C语言中的宏展开。比如设有以下的表（类似于博客中的评论）：
CREATE TABLE `comment` (
`id` int(11) NOT NULL,
`user_id` int(11) default NULL,
`content` varchar(255) default NULL,
PRIMARY KEY (`id`),
KEY `idx_comment_uid` (`user_id`)
) ENGINE=InnoDB;
假设user_id < 10000的用户为VIP用户，我们可以这样创建一个视图来表示VIP用户的评论：
CREATE VIEW vip_comment AS SELECT * FROM comment WHERE user_id < 10000;
这时我们在操作vip_comment视图时使用的就是MERGE算法。如：
mysql > EXPLAIN EXTENDED SELECT count(*) FROM vip_comment WHERE user_id < 0;
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
| 1 | SIMPLE | comment | range | idx_comment_uid | idx_comment_uid | 5 | NULL | 10 | Using where; Using index |
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
mysql> show warnings;
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1003 | select count(0) AS `count(*)` from `test`.`comment` where ((`test`.`comment`.`user_id` < 0) and (`test`.`comment`.`user_id` < 10000)) |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
可以看到，对vip_comment的操作已经被扩展为对comment表的操作。
一般来说在能够使用MERGE算法的时候MySQL处理视图上没什么性能问题，但并非在任何时候都能使用MERGE算法。事实上，只要视图的定义稍稍有点复杂，MySQL就没办法使用MERGE算法了。准确的说，只要视图定义中使用了以下SQL构造块就无法使用MERGE算法：
比如我们希望使用如下的视图来表示每个用户的评论数，即：
CREATE VIEW comment_count AS SELECT user_id, count(*) AS count FROM comment GROUP BY user_id;
使用这个视图的时候，我们可能心里有个小算盘。目前我们先用这个视图顶着，如果性能确实有问题，那我们就再来搞一张comment_count的表，其中就记下来每个用户的评论数。而我们现在先用这个视图是为了将来要是改的话会方便点（这也是视图--即教科书中所谓的外模式--这个东西存在的主要原因之一，另一主要原因是便于权限控制）。但是遇到了MySQL这个蠢货，我们的算盘铁定会失败。
我们来看一下指定user_id从comment_count选取记录时的执行策略：
mysql> explain select count(*) from comment_count where user_id = 90;
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 101 | Using where |
| 2 | DERIVED | comment | index | NULL | idx_comment_uid | 5 | NULL | 524833 | Using index |
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
2 rows in set (4.18 sec)
可以看出，MySQL首先是先执行comment_count的视图定义，将结果存储在临时表中（即DERIVED），然后再扫描这一临时表，选择出满足"user_id = 90"的那一条记录。这样，虽然我们最终只需要统计90号用户的评论数，并且comment表的user_id字段上也有索引，MySQL也会扫描整个comment表，并按user_id分组计算出所有用户的评论数。一般来说，这铁定会使你的系统玩完。这里面还要注意的是即使在进行EXPLAIN时，视图的物化也是要先执行的，因此若评论很多的话EXPLAIN也是一样的慢。
这个问题的根源是MySQL的查询优化本来就存在很多问题。对于上述的查询，要达到比较好的优化效果在数据库中一般是如下处理的：
1、将对视图的操作转化为FROM子句中的子查询：
select * from (select user_id, count(*) as count from comment group by user_id) as comment_count where user_id = 90;
2、子查询提升。因为子查询中使用了group by，因此先将外面的条件作为提升后的having条件
select user_id, count(*) as count from comment group by user_id having user_id = 90;
3、由于having条件中不涉及聚集函数，转化为where条件
select user_id, count(*) as count from comment where user_id = 90 group by user_id;
4、由于指定where条件后，user_id已经是一个常数，根据常数group by没意义，因此去掉group by
select user_id, count(*) as count from comment where user_id = 90;
一般从概念上要经过这四步转化，才能得到最后的优化语句。除第4步无法根据EXPLAIN输出和查询性能判断出MySQL是否进行这一优化外，前3类优化MySQL都不会进行。因此，MySQL要能够有效的处理上述查询还有很长的路要走。
PS: 相对来说PostgreSQL的查询优化能力就强得多，上面的查询在PostgreSQL中就能够产生上述优化后的最终执行计划。PostgreSQL比较关注查询优化估计与PostgreSQL的学院派风格或PostgreSQL中的rule system有关。
然而若要在应用中使用视图，还需要了解处理视图时的性能，而MySQL在这方面问题是比较大的，需要特别注意。首先要知道MySQL在处理视图时有两种算法，分别称为MERGE和TEMPTABLE。在执行"CREATE VIEW"语句时可以指定使用哪种算法。所谓MERGE是指在处理涉及到视图的操作时，将对视图的操作根据视图的定义进行展开，有点类似于C语言中的宏展开。比如设有以下的表（类似于博客中的评论）：
CREATE TABLE `comment` (
`id` int(11) NOT NULL,
`user_id` int(11) default NULL,
`content` varchar(255) default NULL,
PRIMARY KEY (`id`),
KEY `idx_comment_uid` (`user_id`)
) ENGINE=InnoDB;
假设user_id < 10000的用户为VIP用户，我们可以这样创建一个视图来表示VIP用户的评论：
CREATE VIEW vip_comment AS SELECT * FROM comment WHERE user_id < 10000;
这时我们在操作vip_comment视图时使用的就是MERGE算法。如：
mysql > EXPLAIN EXTENDED SELECT count(*) FROM vip_comment WHERE user_id < 0;
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
| 1 | SIMPLE | comment | range | idx_comment_uid | idx_comment_uid | 5 | NULL | 10 | Using where; Using index |
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
mysql> show warnings;
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1003 | select count(0) AS `count(*)` from `test`.`comment` where ((`test`.`comment`.`user_id` < 0) and (`test`.`comment`.`user_id` < 10000)) |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
可以看到，对vip_comment的操作已经被扩展为对comment表的操作。
一般来说在能够使用MERGE算法的时候MySQL处理视图上没什么性能问题，但并非在任何时候都能使用MERGE算法。事实上，只要视图的定义稍稍有点复杂，MySQL就没办法使用MERGE算法了。准确的说，只要视图定义中使用了以下SQL构造块就无法使用MERGE算法：
- 聚集函数
- DISTINCT
- GROUP BY
- HAVING
- 集合操作（在MySQL中只有UNION, UNION ALL，没有EXCEPT和INTERSECT）
- 子查询
比如我们希望使用如下的视图来表示每个用户的评论数，即：
CREATE VIEW comment_count AS SELECT user_id, count(*) AS count FROM comment GROUP BY user_id;
使用这个视图的时候，我们可能心里有个小算盘。目前我们先用这个视图顶着，如果性能确实有问题，那我们就再来搞一张comment_count的表，其中就记下来每个用户的评论数。而我们现在先用这个视图是为了将来要是改的话会方便点（这也是视图--即教科书中所谓的外模式--这个东西存在的主要原因之一，另一主要原因是便于权限控制）。但是遇到了MySQL这个蠢货，我们的算盘铁定会失败。
我们来看一下指定user_id从comment_count选取记录时的执行策略：
mysql> explain select count(*) from comment_count where user_id = 90;
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 101 | Using where |
| 2 | DERIVED | comment | index | NULL | idx_comment_uid | 5 | NULL | 524833 | Using index |
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
2 rows in set (4.18 sec)
可以看出，MySQL首先是先执行comment_count的视图定义，将结果存储在临时表中（即DERIVED），然后再扫描这一临时表，选择出满足"user_id = 90"的那一条记录。这样，虽然我们最终只需要统计90号用户的评论数，并且comment表的user_id字段上也有索引，MySQL也会扫描整个comment表，并按user_id分组计算出所有用户的评论数。一般来说，这铁定会使你的系统玩完。这里面还要注意的是即使在进行EXPLAIN时，视图的物化也是要先执行的，因此若评论很多的话EXPLAIN也是一样的慢。
这个问题的根源是MySQL的查询优化本来就存在很多问题。对于上述的查询，要达到比较好的优化效果在数据库中一般是如下处理的：
1、将对视图的操作转化为FROM子句中的子查询：
select * from (select user_id, count(*) as count from comment group by user_id) as comment_count where user_id = 90;
2、子查询提升。因为子查询中使用了group by，因此先将外面的条件作为提升后的having条件
select user_id, count(*) as count from comment group by user_id having user_id = 90;
3、由于having条件中不涉及聚集函数，转化为where条件
select user_id, count(*) as count from comment where user_id = 90 group by user_id;
4、由于指定where条件后，user_id已经是一个常数，根据常数group by没意义，因此去掉group by
select user_id, count(*) as count from comment where user_id = 90;
一般从概念上要经过这四步转化，才能得到最后的优化语句。除第4步无法根据EXPLAIN输出和查询性能判断出MySQL是否进行这一优化外，前3类优化MySQL都不会进行。因此，MySQL要能够有效的处理上述查询还有很长的路要走。
PS: 相对来说PostgreSQL的查询优化能力就强得多，上面的查询在PostgreSQL中就能够产生上述优化后的最终执行计划。PostgreSQL比较关注查询优化估计与PostgreSQL的学院派风格或PostgreSQL中的rule system有关。
相比IE，火狐Firefox浏览器的优势我就不再在此详谈了，仅说两点：完全支持网页标准化设计；功能强大的可扩展性。一直以来Firefox成了我默认的网上冲浪的入口，再后来陆续接触到一些Firefox扩展，超级喜欢。下面的列表是我近两年来常用的一些火狐SEO扩展，可以在Firefox浏览器直接点击链接下载安装。
转自:Charles@网站优化博客
- Web Developer Toolbar - 十分强大的网页设计师必备扩展，可以浏览网站的cookies，CSS，图片，页面信息，窗口大小，还可以查看源代码等等。
- SEO for FireFox - 在Google及Yahoo的搜索结果中显示网站的信息及网页的Technorati、del.icio.us链接数量等等。
- SEOpen - 方便查询网站的收录情况及反向链接。
- SearchStatus - 可以在浏览器的状态栏下显示网页的PageRank值及网站的Alexa排名。（注：我没装Google工具栏）
- del.icio.us - 好的SEO文章直接存到书签了，Tags方便管理
- IEView - 测试网页在IE的表现力就不要重新打开IE了
- EditCSS - 闻如其名，对CSS的编辑扩展
- Linkification - 将文本链接转换成个性链接
- Adblock Plus - 屏蔽烦人的广告
- ShowIP - 显示当前页的IP及whois信息
- FireBug - 查找网站的BUG，红颜色标志出来
- MeasureIt - 测量网站尺寸
- FireFTP - 把firefox变成FTP工具
- ColorZilla - 装上这个插件，用来显示颜色代码
- Copy as HTML Link - 把网站的链接显示出来
转自:Charles@网站优化博客
