易栈网-膘叔

其实，这个新闻里所说的：【众所周知，2006年12月之后申请的网易免费邮箱不再提供免费POP/SMTP服务】，我还真不知道。。。
我只是奇怪为什么我的帐号可以发邮件，而同事的却不能发。。毕竟我们更多的时候是用PHP来发邮件的。

原来是这样啊，http://www.cnbeta.com/articles/101483.htm：

据广大网友反映，从今天晚上20点40分开始，网易免费邮箱（163、126）再次免费开放POP/SMTP服务。众所周知，2006年12月之后 申请的网易免费邮箱不再提供免费POP/SMTP服务，不少用户因此都埋怨网易小气。可能是因为前几年稳坐国内免费邮箱头把交椅的缘故，网易一直对用户要 求免费开放POP的呼声置之不理。 这两年，随着QQ邮箱的高歌猛进，大量网易邮箱用户开始倒戈，投入QQ邮箱和gmail的怀抱，网易的免费邮箱老大哥地位也摇摇欲坠。2010年伊始，网易邮箱便展开了一些列大动作。升级到3.5版后，网友们欣喜地发现网易邮箱开始变得厚道起来，主要变现在：

1.从上个月开始， 免费邮箱去掉了发信时的广告尾巴；
2.从今天晚上20时40分开始，网易163和126免费邮箱可以免费开通POP服务。（默认未开启，用户需在邮箱设置中手动开启）

--EOF--

邮箱中，我常用的也就163和yahoo了。自从foxmail推出后，我也用了foxmail，但是现在。。。。登录却跳到了QQmail，真伤心。。。139邮箱也在用，不过。纯粹是为了免费提醒功能。可以让我收到一些提醒信息。。

163一改版，我就立马发现了。确实顺手，而且速度也很快

上个月谷歌推出了自己的DNS服务Google Public DNS，该项目的主要目标之一是速度。但问题是大多数互联网用户不知道什么是DNS服务器，更不用说如何配置DNS服务器或者说测试它的速度有多快了。现在Google推出了他自己的DNS测试工具Namebench，它可以帮你轻松找到最快的DNS。

Namebench作者是Google的一个工程师，他开发这个这个工具的目的是希望它能够帮助人们正确查找出有效的DNS中最快的一个，使网速达 到同等条件下能够达到的最快速度。Namebench是跨平台图形用户界面软件，并提供命令行接口，支持包括Windows，Linux和OS X在内的操作系统平台，而且是完全开源的。这个项目作为Google的”20% 项目”运行。不妨下载试试看！

你可能担心，Namebench是由Google工程师开发的，那么它是否会偏袒Google Public DNS呢？实际上不会，我刚才测试了一下，结果显示Google Public DNS的速度只是所有DNS中速度中等的一个，最快的DNS服务是Google Public DNS的最大竞争对手—OpenDNS。

使用Namebench进行测试可能会花费几分钟时间，但这是值得的，因为在它帮你找的最佳选择之后，就能使你的网速在同等条件下尽可能的快了，这对于抢沙发的你来说是多么重要啊！不是吗？

--EOF--
其实，新闻是几天前的了，本来也没有这么关注过，但事实上，最近发生的很多事情让人不得不关注啊。先是DNS频繁出错，后来 又是无法解析，时断时续，然后就开始使用8。8。8。8这类国外的DNS，所以，对于namebench就有点关注了。

有时候真的想建议领导，把8小时工作制改为7小时，对于技术人员来说，每天能够拿出一小时时间来看看书，学习一点其他的，或者放松一下，其实对于效率来说，反而会是提高的。

新闻原址：http://www.cnbeta.com/articles/101265.htm

关于使用GUID和INT做主键，性能差异的文章历来很多，不过。大多都是从理论上来说明，这次难得看到某人用PC机做测试，所以贴上来看看。但我不贴全文，毕竟。。。大量的代码贴上来，也没有太大的意义 。所以仅贴上主体内容和测试结果，当然还会有一些用户的评论。。

原文网址为：http://www.cnblogs.com/jackhuclan/archive/2010/01/04/1639005.html
内容大致如下，【如想看全文，请使用上面的链接】
在数据库的设计中我们常常用Guid或int来做主键，根据所学的知识一直感觉int做主键效率要高，但没有做仔细的测试无法说明道理。碰巧今天在数据库的优化过程中，遇到此问题，于是做了一下测试。

测试环境：

　　台式电脑 Pentiun(R) 4 Cpu 3.06GHz
Win XP professional
1.5G DDR RAM
SQL Server 2005 个人版 

测试过程：
首先创建测试数据库Test
1.创建Test_Guid表，创建Test_Int表
2.创建Test_Guid子表：Test_Guid_Detail和创建Test_Int子表：Test_Int_Detail，用来做连接查询
3、然后进行一些CRUD的操作【这是我写的，因为原文中写插入N行数据，删除N行数据之类的太复杂，也太多，简化为一句话了】

测试结果如下：

综上所述，使用int做主键比用guid做主键各中情况下效率均有提高，特别是在有连接查询和删除记录效率提升明显。

而且本人今日在guid做主键的数据查询中因为嵌套几个子查询结果屡屡出现查询超时。因此本人赞同用int做主键，不赞同guid做主键。
以上观点代表个人观点，欢迎大家各抒己见，说明guid和int各自做主键的优劣所在。

----EOF---

本来到这里就可以结束了，但有一个用户的评论还算不错：

更多的人认为GUID在做数据迁移的时候很方便，而如果使用INT则会有意料不到的问题。而GUID遇到的问题会少很多。。。

相对于以上的观点我还是比较认同的，但我认为性能相差这么大是有可能有以下的原因：
1、作者用的是PC机
2、操作系统是XP
3、sql server 是个人版【我没有试用服务器版性能如何，但我想，一定比个人版性能更优，当然这是猜测】

说归说，对于MYSQL来说，基本上还是只能使用INT做主键。毕竟MYSQL没有自带的生成GUID的方法【我不是指手动生成，我是说自动生成。。。UUID()函数是可以生成GUID的，但不能象INT那样自动插入，也没有办法设置default为UUID()方法】

由于最近一直在使用thinksns，所以相对关注的就比较多了一点。BUG偶尔也会发现一些，小的就不提了，没意义，偶尔也有可能是手误的关系，但一些稍大一点的。我还是写下来做个记录。。

比如这个插件配置的BUG。

一般来说，项目的配置要覆盖原始配置都是array_merge就结束了。于是乎，ThinkSNS在每个插件的Conf目录下的Config文件里也都有这么一行。

然而。。。问题就出来这里，插件的作者好象都没有注意过Array_merge的作用范围。

大多情况都是这样写的：

看到第二段没？如果有相同的KEY，后面的会覆盖前面的。。那么。。上面第6行的array_merge，和没运行有什么区别？？？

把参数顺序颠倒一下就OK了。。。

MYISAM和INNODB的争论由来已久，如今，我又找到两篇文章，让我们看看有关这两种引擎的优劣的文章：浅谈MySQL存储引擎选择 InnoDB还是MyISAM以及InnoDB还是MyISAM 再谈MySQL存储引擎的选择

第一篇：浅谈MySQL存储引擎选择 InnoDB还是MyISAM

作者：酷壳，来源于：http://database.51cto.com/art/200905/122382.htm

MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。

下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？

思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从 InnoDB中获得全文索引。

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小 决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB 只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方 式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

第二篇：InnoDB还是MyISAM 再谈MySQL存储引擎的选择

作者：邵宗文，来源于：http://database.51cto.com/art/200905/124370.htm

两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

原因如下：

1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候 MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的 binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据 库实例的数据量基本都是几十G大小。

4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是 where对它主键是有效，非主键的都会锁全表的。

5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让 他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十 多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

文章都不太长，适合着看看就行了。。