易栈网-膘叔

SEO是做网站的人最想了解的东西。在很多人眼里，它，很神秘。毕竟也有很多人靠这玩意吃饭，也不能砸人家饭碗不是？

提到SEO，就不能不提，搜索引擎最关心什么，这个就是09年的报告，我从帕兰映像里复制而来：

著名SEO网站SEOMOZ今年调查得出的一份“影响搜索引擎排名因素的报告”。他们每两件做这样一个调查，调查对象是全世界各地的SEO专家。然后总结出专家们的百分比报告，对于SEOer来说，还是非常值得研究的。

总的排名因素百分比分布情况

• 24% 域名的权威性和信誉
• 22% 页面的外链数量和质量
• 20% 外部链接的锚文字
• 15% 页面上关键字使用情况
• 7% 流量和点击率
• 6% 网络社交关系指标
• 5% 域名注册和主机数据

5个对搜索引擎排名最重要的排名因素

• 1.73% 非常重要 外部链接含有关键字的锚文字
• 2.71% 非常重要 外部链接广度(外部链接的数量和质量)
• 3.67% 非常重要 外部链接源的多样性(有很多来自不同域名的链接)
• 4.66% 非常重要 在Title标签中使用关键字
• 5.66% 非常重要 基于从可信任域名到网站链接距离的可信赖度(比如: trustrank,domain moztrust,等等)

5个对搜索引擎排名最负面的排名因素

• 68% 非常重要 有意或恶意隐藏作弊
• 56% 很重要 从已知的链接商购买链接
• 51%一般重要 链接到垃圾(Spam)网站或页面
• 51%一般重要 隐藏用户代理
• 51%一般重要 经常down机、网站不能访问

5个最具争议的排名因素

• 16.3% 强烈争议 利用Cookie探测器作弊
• 15.4% 中度争议 利用Javascript/富媒体支持探测器作弊
• 15.3% 中度争议 使用背景颜色来隐藏正文的文字
• 15.3% 中度争议 通过IP地址隐藏作弊(Cloaking by IP Address)
• 15.2% 中度争议 通过侦测客户端(User-Agent)作弊

更详细的数据可以访问SEOMOZ原文查看。

看到某人的博客在介绍这个游戏的时候，大吃一惊，这。。。不是网络小说中有名的重生嘛。
回到过去，重新开始。但事实上呢？

原文怎么说来着？

Achron号称是世界第一款元时间战略游戏（meta-time strategy，拥有时间旅行功能的即时战略游戏），玩家和游戏中的单位可以同时和独立的在不同时间中跳跃。玩家可以通过窥探未来的结局而改变现有的策 略，冻结时间去实施完美协调的攻击，改变未来的历史进程。举例来说，如果玩家在某个没有预料到的地点遭受了一次突如其来的攻击，他可以跳到过去，改变军队 的行进方向。或者如果玩家在一场战役中战败，他可以到过去阻止战役发生。游戏共包含三个种族，两个是外星种族，一个是人类——Vecgir，精于瞬间移 动；Grekim，精于时间旅行；人类，精通攻击。

 不过，根据以前的那种小说也好，电影也好，都认为时间线洪流是永远不会重复的。当你真的到了过去，你已经不是在原来的时间线上了。原来的时间线关于你的故事就从那时候断了。其实想想也是，象这种即时战略游戏，你真的回到过去某一个时间点的时候，重新发展，电脑怎么办？电脑是AI，他可能就会做出与原来的时间线不一样的事情。其实相当于什么都没做。

说白了，这个元时间，其实就是即时存档，随时调用。。。呵呵

不过有点新颖

query cache在开发中应该算是应用的挺广泛的。但事实上，在高并发网站，query cache是应该并关闭的（我是指论坛、SNS类型的网站），而应该用其他的方式进行缓存，不是用数据库。
众所周知，在设置了query cache后，连续的查询同样的sql，那么这些SQL是会被缓存下来的，然而一旦有更新cahce会被清空。数据量小的时候可能感觉不出来，如果数据量大了，其实反而是影响效率的。因此一般不太会使用。。

mysql的参数是：

taobao DBA的苏普说：

当你的数据库打开了Query Cache（简称QC）功能后，数据库在执行SELECT语句时，会将其结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。

 在这个“Cache为王”的时代，我们总是通过不同的方式去缓存我们的结果从而提高响应效率，但一个缓存机制是否有效，效果如何，却是一个需要好好 思考的问题。在MySQL中的Query Cache就是一个适用较少情况的缓存机制。在上图中，如果缓存命中率非常高的话，有测试表明在极端情况下可以提高效率238%^[1]。但实际情况如何？Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。举 个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache 的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么Query Cache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%^[1]的处理能力。

如果你的应用对数据库的更新很少，那么QC将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候QC的作用会比较明显。

再如，一个更新频繁的BBS系统。下面是一个实际运行的论坛数据库的状态参数：

可以看到，数据库一共往QC中写入了约800W次缓存，但是实际命中的只有约500W次。也就是说，每一个缓存的使用率约为0.66次。很难说，该 缓存的作用是否大于QC系统所带来的开销。但是有一点是很肯定的，QC缓存的作用是很微小的，如果应用层能够实现缓存，将可以忽略QC的效果。

————-下面是关于QC的一些其他细节—————–

一、Query Cache相关参数：

• query_cache_size QC占用空间大小，通过将其设置为0关闭QC功能
• query_cache_type 0表示关闭QC；1表示正常缓存；2表示SQL_CACHE才缓存
• query_cache_limit 最大缓存结果集
• query_cache_min_res_unit 手册上说，QC会按照这个值分配缓存block的大小。
• Qcache_lowmem_prunes 这是一个状态变量(show status)，当缓存空间不够需要释放旧的缓存时，该值会自增。

二、Query Cache观察：

CREATE TABLE t1(id INT,var1 varchar(10));
	//Com_select:8	Qcache_hits:1
INSERT INTO t1 VALUES(1,’WWW’);
	//Com_select:8	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:1
INSERT INTO t1 VALUES(2,’RRRR’);
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:0
SELECT * FROM t1 WHERE id=1; //INSERT后Cache失效
	//Com_select:10  Qcache_hits:2 Qcache_queries_in_cache:1

参考：

1. http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
2. http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
3. http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/

(全文完)

 本文引用地址为：http://rdc.taobao.com/blog/dba/html/325_query-cache-cool-or-not.html

对于数据库来说，开发人员可能更多的属于不明真相的围观群众这类人。对于字段长度或许都有所了解，对于不同的字符集所占的位数也会明白一些，但究竟是不是你想象的那样，你又真的了解多少？

看看人家玄月写的文章吧。不要不承认，其实你我都一样，都是知其然不知其所以然，而且都是看着书然后人云亦云。有时候不测试不亲自动手是看不到真相的。当然我也仅转载。我也没有测试，其实我就在真相门外徘徊。

原文如下：

字符与字节的问题
1、表t1
mysql> show create table t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`a` char(1) DEFAULT NULL,
`b` binary(1) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=gbk

1）插入数据：
mysql> insert into t1 values(’w',’w'),(’中’,'中’);

mysql> select * from t1;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | ? |
+——+——+

2）插入数据被截断:
mysql> insert into t1 values(’xy’,'xy’),(’中国’,'中国’);
Query OK, 2 rows affected, 4 warnings (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 4

mysql> select * from t1;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | ? |
| x | x |
| 中 | ? |
+——+——+

2、表t2
mysql> show create table t2\G
*************************** 1. row ***************************
Table: t2
Create Table: CREATE TABLE `t2` (
`a` char(2) DEFAULT NULL,
`b` binary(2) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=gbk

1）插入数据：
mysql> insert into t2 values(’w',’w'),(’中’,'中’);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

mysql> select * from t2;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | 中 |
+——+——+
2 rows in set (0.01 sec)

mysql> insert into t2 values(’xy’,'xy’),(’中国’,'中国’);
Query OK, 2 rows affected, 1 warning (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 1

mysql> select * from t2;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | 中 |
| xy | xy |
| 中国 | 中 |
+——+——+

总结： char以字符来计算，一个中文一个英文都是占1个字符；
Binary以字节来计算，一个英文占1个字节，一个中文占2个字节。

原文地址：http://rdc.taobao.com/blog/dba/html/324_%e5%ad%97%e7%ac%a6%e4%b8%8e%e5%ad%97%e8%8a%82.html

几件小事记录
1、会牵着大人的一只手走了。还是摇摇晃晃。但这是个好兆头啊。应该快了吧。呵呵。会自己扶着床边、墙边往前走了

2、爸爸等音节有点会发了。只是妈妈一直不会叫。

3、拿着碗喝水，但放到嘴边时，还是有点控制不住力量

4、睡觉 前讲故事。三个小猪。讲到大灰狼的时候，和妈妈一起：呼 （这是大灰狼吹小猪的房子的声音）哈哈