易栈网-膘叔

之前在“ Yii的又一个BUG？”提过我将数据导入到数据库时，进直接用ActiveRecord导入的，所以字段的类型都是String，后来发现问题，指定字段 为int值
这两天为了做一个查询，看了一下程序又遇到了问题：
同样的参数，同样的内容，一个查询能够有值，一个查询一点数据都没有。。。这是怎么回事？
一步步的测试下来，最后怀疑是字段类型，从$_GET回来的参数应该是字符串型而不是int，于是做了一个强制转换，数据果然就有了。我晕啊。。。大哥，你绕了我吧？
看来以后对于这类的数据，只要涉及mongo的，还是要多做一次额外的处理，否则连问题都没法发现。当然这也是因为不细心导致的。
慎记

本来。。。VPS已经换到budgetVM上面去了，但不幸的是，这两天VPS出了点问题。

结果。。。数据丢失了。
所以我现在又切换到了linode上面。果然，linode还是最好的VPS，没有之一啊。。。

准备利用google的搜索来一一恢复我这段时间的数据。当然。还有googlereader。。。
他们的support里面这么说：

Dear Customers;

We are aware that some of your systems are offline, or failing to reboot, we are working to correct this issue immediatly and we will update you once it has been completed.

This does not affect all of our customers but it appears to be ~5 Virtual Machines per Hardware Node which are failing to boot.

We will update you via your support ticket once it has been resolved. I can assure you we are working dillegintly twords a solution at this time.

Regards,

Nick Rose

Enzu Inc.

然后:

Status update: Node Maintenance Continues

Our administrators are still working on restoring your account to service. We apologize for the inconvenience.

We will be providing a 1 Month SLA Credit for this outage. Further details will arrive when your ticket is resolved.

If you do not need the data on your current vps and would like it reinstalled we can do this for you which will bring it back into service immediately. If you would prefer to wait for the admins to complete their work no further action on your part is required.

We will continue to send updates as they become available.

Thank you for your patience.
-----------------

看到这个就让我感觉纠结了

在讲今天的内容前，请允许我说几句：what the fuck，再说一句：“你哭著對我說童話裡都是騙人的”
前两天说过为了速度我建了索引，虽然给id建了unique的索引，但是数据还是不由分说的插了重复的。好吧。因为数据在unique前就进数据库了。所以。。。我必须要再加上dropDups这个条件。

于是乎，我就先开始删除索引，然后灾难就来了：

b.archive.dropIndex({id:1,unique:true})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true},{name:"id"})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true},{"name":"id"})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({category_id:1})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"category_id":1})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"key":{"status":1}})
{ "errmsg" : "index not found", "ok" : 0 }

为什么为什么？？？？
为什么我会这么做？是因为：http://www.mongodb.org/display/DOCS/Indexes
这里面写着：

Dropping Indexes

To delete all indexes on the specified collection:

db.collection.dropIndexes();

To delete a single index:

db.collection.dropIndex({x: 1, y: -1})

Running directly as a command without helper:

// note: command was "deleteIndexes", not "dropIndexes", before MongoDB v1.3.2 // remove index with key pattern {y:1} from collection foo db.runCommand({dropIndexes:'foo', index : {y:1}}) // remove all indexes: db.runCommand({dropIndexes:'foo', index : '*'})

我晕啊。这是肿么了。。。
后来还是神仙和赵拂衣说了一句，试一下dropIndex("xxx")，果然。。。Over了。你说，你这不是忽悠人嘛 ，为了这个，我折腾了一个晚上啊。。。。
害得我当时只能dropIndexes，先删除所有的，再重建索引。。。数据又多，我等了好久好久啊。

前段时候做了个一万条数据的对比，这回做了个2000000条数据的对比：
测试方式还是和以前一样：

测试开始：
1、order by id ASC  limit 25，很常见的查询吧。每页显示25条。
没有索引的时候：0.05秒左右（1万条是0.88秒，很奇怪）
用了id,unique索引后，0.004,第一次的时候0.08，后面稳定在0.00x左右（与1W左右一致）

2、where category_id = 1 limit 25，某个条件
无索引时：24秒左右 (很夸张。。。)
有索引：第一次0.06左右，后面稳定在0.00x(x>6)，即在0.006~0.01之间(与1W左右一致）

3、where category_id = xx order by pubdate limit 25
无索引：20秒左右，最慢的一次达到了70秒
有索引的时候，与条件2差不多。。

虽然不是特别的深入测试，但这样也几乎足够了。不过，这带来另一个问题。内存消耗比较大啊。果然是吃内存大户

在手册里，关于header函数的说明是说服务端会输出一系列的头，用firebug也可以看得很清楚
一般来说，我们用header控制的情况不是特别多，毕竟不会主动去改什么：一般也就设置设置编码、跳转、压缩等，不太会过多的干涉。下载的时候也会设置头，黑黑

手册上，我们对于cache都是写着如何设置，以便让代码不被cache：

header("Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Pragma: no-cache"); // Date in the past

而且在设置的时候还得注意在header前不能有输出，否则header设置无效，但都没有写过，如何给页面设置Cache，虽然我们知道有一些办法，比如 E-TAG之类的。当然也有简单的设置：
比如我们在输出前，对内容进行md5，将它当成e-tag只要没变化，就不会有影响。也有其他的方式：

$seconds_to_cache = 3600;
$ts = gmdate("D, d M Y H:i:s", time() + $seconds_to_cache) . " GMT";
header("Expires: $ts"); header("Pragma: cache");
header("Cache-Control: max-age=$seconds_to_cache");

缓存1小时，主要是过期时间得用gmdate来设置，而不是date，这个要注意，其他都差不多。maxage要和expire能够对得上。

不算笔记的笔记。