1.0版之后超过15天后功能受限。可以通过删除以下注册表项来解除限制：

[HKEY_CURRENT_USER\Software\Classes\CLSID\{B1159E65-821C3-21C5-CE21-34A484D54444}\4FF78130]

把这个项下的值全删掉就可以了。

下面上图给大家感受下强大的MongoVue，可以提高你使用MongoDB的幸福指数好几十点，上图是王道：

1、配置连接

2、试下新建一个名为AccessLog的Collection ：

3、插入一个Document

4、查看我们插入的数据，数据可以通过多种方式展示（树形、表格、文本）

上面我们都是通过图形界面的操作的吧，下面有一个窗口列出了上述操作的客户端命令哦，这是学习的好资源，在用图形界面的时候依然可以学习熟悉下命令行。

当然上述只是介绍了下最基本的功能，还有更新，删除数据库，从mysql数据库导入数据等等功能，想了解更详细的内容请访问官方网站：http://www.mongovue.com/

http://blog.nosqlfan.com/tags/mongodb

您可能也喜欢：
Mongodb 与mysql 语法比较	Mongodb亿级数据量的性能测试	mongodb索引讲解与性能调优	mongodb的监控与性能优化
无觅

F ：进程标志
S ：进程状态。S=sleeping，R=running，T=stopped/traced，D=interruptable sleep，Z=zombie。参见1.1.7“进程状态”中关于这些状态的介绍。
UID ：进程所有者（可能是启动者）用户名
PID ：进程ID
PPID ：父进程ID
LWP ：LWP(轻量级进程【light weight process】,也称作线程)ID
C ：处理器使用率百分比
NLWP ：进程中lwp（线程）的数量。（别名thcount）
PRI ：进程的优先级。（参看1.1.4“进程优先级和Nice值”）
NI ：Nice值（whether the process tries to be nice by adjusting the priority by the number given; see below for details）
ADDR ：进程地址空间（不显示）
SZ ：进程所有内存（code+data+stack）总数，单位为KB。
WCHAN ：内核功能名称，如果进程正在运行中
RSS ：常驻集大小，任务所使用的非交换物理内存（KB）
PSR ：当前执行进程的处理器
STIME ：开始时间
TTY ：终端名称
TIME ：进程所用的CPU时间总数（自从启动）
CMD ：启动任务的命令行（包括参数）

线程信息

您可能也喜欢：
Linux 指令篇:工作行程资讯与管理--ps	PS 命令详解	Linux网管必备的几个命令	Linux 查看文件系统及分区格式！
无觅

创业的选择有两种，一是白手起家做创新品牌，另外就是已经有发展基础的品牌去做大，这两者之间最大的不同就是把握时机。每天都会有成百上千的机会摆在你的面前，你会选择哪一个？把握住其中的一个机会就意味着你将放弃其它那成百上千的诱惑。所以，创业最关键的技能就是把握时机。

作为一个成熟的企业，在发展的过程中都会面临各种时机，这些时机有的会让公司在付出较少的前提下获得更多利益，有的会促使公司有较大的发展。这些时机会由很多事情决定，比如有足够的活跃用户会向你进行反馈市场信息、发现某个榜样可以让你参考学习、发现了能够促进达成目标的优化方案等等。

回顾我自己创业的这六个月，发现自己对时机的选择真的是非常糟糕的。我经常在某项工作上花费大量时间，而最后对达成目标却没有任何效果。我特别容易偏爱短期（1至2周时间）项目，这些项目看起来充满乐趣而且不会造成大的危害。这样的项目做得多了，你就会发现，真的很浪费时间。

以下是我曾在上面做出错误选择的一些事情：

1. 邀请访问制度。邀请访问制度是激发用户对产品的兴趣的策略之一。但对我而言，我所做的是让用户感到生气，因为我没有让他们在最短的时间内使用到我的产品。现在回想下，我把用户阻止在我的应用之外，目的竟然是希望他们能够更加喜欢我的应用。另外，实施邀请访问制度，也浪费了大量工程师们的时间。

2. 实时流量观测。我曾经做过这样一个事情，利用GoSquared（之前还用过Chartbeat）实时观测我的网页应用上的用户信息。我能看到网站上有多少用户、在世界各地什么地方、通过哪些网页进入到我的网站、他们正在哪些网页等等。其实，这只是虚荣心在作怪，因此，我每天都会花费大量时间去查看十几次实时数据统计。现在，我已经忽略实时统计了，我只利用Google Analytics查看下历史数据。

3. 用户管理面板。我建立了一个管理面板，在这上面，我可以通过Qwerly API看到所有注册用户的详细社会资料。比如一个新用户Fred Bloggs通过Facebook在我的应用上登记了，那么我将可以看到Fred的LinkedIn信息、Twitter上的信息以及他的照片。当初开发这个功能的目的是想发现有影响力的用户，继而可以进一步接触，但直到现在也没有达到目的。而当我的应用拥有成千上万的用户之后，这个管理面板已经不能使用了。

4. 过早的尝试广告。我非常渴望能够利用广告赚钱，我在网站头版放上广告链接的时候，我的网站还只有几千的日访问量。当然，这个广告每天也只有10个左右的点击，这绝对是一个教训。你的网站需要有真正吸引用户的东西，然后才能够吸引广告客户。

5. Amazon affiliate链接。这是我最不该尝试的另一个企图赚钱的试验。但当时被一个毫无根据的想法激发了，认为用户在浏览我的网站时应该会想要购买食谱。我用了还几天建立了这个功能，比如学习亚马逊联盟API规则、编写代码以及匹配食谱等等。最终，我每天的盈利不足1美元。在做Amazon affiliate的用户中，我还没见过谁比我赚的更少的。

6. TechCrunch。TechCrunch是美国知名科技博客，是科技创业者获得投资者青睐和获得科技行业知名度的优秀平台。但根据我的经验，它不一定适合所有人。我花费了大量的时间和精力是自己的创业能够被TechCrunch报道，最终确实被报道了，但是，就文章本身和所带来的流量来讲，没有达到我所期望的。我觉得自己的选择出现了问题，我应该选择不怎么高科技的站点来吸引我站在的受众，比如LifeHacker 以及 kottke.org。

7. 一次性合作项目。我曾经花费两周时间利用我的API建立了一个客户蓝本，为的是能够与另一家公司达成合作伙伴关系。而这个关系从未达成，也可以说还未开始就已经结束了。当然，这种错误有时候使必须的，你必须在试图获得巨大利益的时候做出一些赌博性质的举动。但是，在创业初期，两周的时间真的很宝贵。我们应该使自己的产品更加完善更加成熟，而不是急着去感谢合作伙伴。

8. 在家工作。创业第一年，我的所有工作都是从家庭办公室开始的。之后，我搬到了市中心一个共享的办公室。自从搬了之后，我的工作效率比在家办公提高了2到3倍，对于这个现象，我不知道如何解释为什么在家效率就不高，总觉得有一个莫名的心里障碍，让我无法快速、高效地工作。如果我的第一天工作就在外面办公，我想我的公司将会走得更远。虽然这是事后才想到，但是我想这应该是正确的。

等错误发生之后才批评很容易，但我相信这些错误大多是可以在第一时间避免的。这些错误在我的创业历程中曾使我偏离发展目标，但无论怎样，我们还是需要学会选择，选择如何更新产品版本、选择听取反馈并努力使产品更好。（编译：魏兵）

本文为CSDN编译整理，未经允许不得转载。如需转载请联系market@csdn.net。

您可能也喜欢：
高效时间管理，加速你的工作－介绍GTD	用户行为分析-使用JS和_trackPageview函数从时间维度监测页面表现	时间管理的40项准则	启用Xdebug使用WinCacheGrind分析脚本执行时间
无觅

传统的关系数据库一般由数据库（database）、表（table）、记录（record）三个层次概念组成，MongoDB是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。MongoDB对于关系型数据库里的表，但是集合中没有列、行和关系概念，这体现了模式自由的特点。 

mongodb语法

MongoDB的好处挺多的，比如多列索引，查询时可以用一些统计函数，支持多条件查询，但是目前多表查询是不支持的，可以想办法通过数据冗余来解决多表查询的问题。

MongoDB对数据的操作很丰富，下面做一些举例说明，内容大部分来自官方文档，另外有部分为自己理解。

查询colls所有数据

db.colls.find() //select * from colls

通过指定条件查询

db.colls.find({‘last_name’: ‘Smith’});//select * from colls where last_name=’Smith’

指定多条件查询

db.colls.find( { x : 3, y : “foo” } );//select * from colls where x=3 and y=’foo’

指定条件范围查询

db.colls.find({j: {$ne: 3}, k: {$gt: 10} });//select * from colls where j!=3 and k>10

查询不包括某内容

db.colls.find({}, {a:0});//查询除a为0外的所有数据

支持<, <=, >, >=查询，需用符号替代分别为$lt，$lte，$gt，$gte

db.colls.find({ “field” : { $gt: value } } );

db.colls.find({ “field” : { $lt: value } } );

db.colls.find({ “field” : { $gte: value } } );

db.colls.find({ “field” : { $lte: value } } );

也可对某一字段做范围查询

db.colls.find({ “field” : { $gt: value1, $lt: value2 } } );

不等于查询用字符$ne

db.colls.find( { x : { $ne : 3 } } );

in查询用字符$in

db.colls.find( { “field” : { $in : array } } );

db.colls.find({j:{$in: [2,4,6]}});

not in查询用字符$nin

db.colls.find({j:{$nin: [2,4,6]}});

取模查询用字符$mod

db.colls.find( { a : { $mod : [ 10 , 1 ] } } )// where a % 10 == 1

$all查询

db.colls.find( { a: { $all: [ 2, 3 ] } } );//指定a满足数组中任意值时

$size查询

db.colls.find( { a : { $size: 1 } } );//对对象的数量查询，此查询查询a的子对象数目为1的记录

$exists查询

db.colls.find( { a : { $exists : true } } ); // 存在a对象的数据

db.colls.find( { a : { $exists : false } } ); // 不存在a对象的数据

$type查询$type值为bsonhttp://bsonspec.org/数 据的类型值

db.colls.find( { a : { $type : 2 } } ); // 匹配a为string类型数据

db.colls.find( { a : { $type : 16 } } ); // 匹配a为int类型数据

使用正则表达式匹配

db.colls.find( { name : /acme.*corp/i } );//类似于SQL中like

内嵌对象查询

db.colls.find( { “author.name” : “joe” } );

1.3.3版本及更高版本包含$not查询

db.colls.find( { name : { $not : /acme.*corp/i } } );

db.colls.find( { a : { $not : { $mod : [ 10 , 1 ] } } } );

sort()排序

db.colls.find().sort( { ts : -1 } );//1为升序2为降序

limit()对限制查询数据返回个数

db.colls.find().limit(10)

skip()跳过某些数据

db.colls.find().skip(10)

snapshot()快照保证没有重复数据返回或对象丢失

count()统计查询对象个数

db.students.find({‘address.state’ : ‘CA’}).count();//效率较高

db.students.find({‘address.state’ : ‘CA’}).toArray().length;//效率很低

group()对查询结果分组和SQL中group by函数类似

distinct()返回不重复值

您可能也喜欢：
MongoDB 客户端 MongoVue	Mongodb亿级数据量的性能测试	mongodb的监控与性能优化	MongoDB的ObjectId
无觅

　　开启 Profiling 功能

有两种方式可以控制 Profiling 的开关和级别，第一种是直接在启动参数里直接进行设置。

启动MongoDB时加上–profile=级别 即可。

也可以在客户端调用db.setProfilingLevel(级别) 命令来实时配置。可以通过db.getProfilingLevel()命令来获取当前的Profile级别。

　上面斜体的级别可以取0，1，2 三个值，他们表示的意义如下：

0 – 不开启

1 – 记录慢命令 (默认为>100ms)

2 – 记录所有命令

Profile 记录在级别1时会记录慢命令，那么这个慢的定义是什么?上面我们说到其默认为100ms，当然有默认就有设置，其设置方法和级别一样有两种，一种是通过添加–slowms启动参数配置。第二种是调用db.setProfilingLevel时加上第二个参数：

　　查询 Profiling 记录

与MySQL的慢查询日志不同，Mongo Profile 记录是直接存在系统db里的，记录位置 system.profile ，所以，我们只要查询这个Collection的记录就可以获取到我们的 Profile 记录了。

列出执行时间长于某一限度(5ms)的 Profile 记录：

查看最新的 Profile 记录：

db.system.profile.find().sort({$natural:-1})

Mongo Shell 还提供了一个比较简洁的命令show profile，可列出最近5条执行时间超过1ms的 Profile 记录。

　　Profile 信息内容详解：

ts-该命令在何时执行.

millis Time-该命令执行耗时，以毫秒记.

info-本命令的详细信息.

query-表明这是一个query查询操作.

ntoreturn-本次查询客户端要求返回的记录数.比如, findOne()命令执行时 ntoreturn 为 1.有limit(n) 条件时ntoreturn为n.

query-具体的查询条件(如x>3).

nscanned-本次查询扫描的记录数.

reslen-返回结果集的大小.

nreturned-本次查询实际返回的结果集.

update-表明这是一个update更新操作.

fastmod-Indicates a fast modify operation. See Updates. These operations are normally quite fast.

fastmodinsert – indicates a fast modify operation that performed an upsert.

upsert-表明update的upsert参数为true.此参数的功能是如果update的记录不存在，则用update的条件insert一条记录.

moved-表明本次update是否移动了硬盘上的数据，如果新记录比原记录短，通常不会移动当前记录，如果新记录比原记录长，那么可能会移动记录到其它位置，这时候会导致相关索引的更新.磁盘操作更多，加上索引更新，会使得这样的操作比较慢.

insert-这是一个insert插入操作.

getmore-这是一个getmore 操作，getmore通常发生在结果集比较大的查询时，第一个query返回了部分结果，后续的结果是通过getmore来获取的。

　　MongoDB 查询优化

如果nscanned(扫描的记录数)远大于nreturned(返回结果的记录数)的话，那么我们就要考虑通过加索引来优化记录定位了。

reslen 如果过大，那么说明我们返回的结果集太大了，这时请查看find函数的第二个参数是否只写上了你需要的属性名。(类似 于MySQL中不要总是select *)

对于创建索引的建议是：如果很少读，那么尽量不要添加索引，因为索引越多，写操作会越慢。如果读量很大，那么创建索引还是比较划算的。(和RDBMS一样，貌似是废话 -_-!!)

　　MongoDB 更新优化

如果写查询量或者update量过大的话，多加索引是会有好处的。以及～～～～(省略N字，和RDBMS差不多的道理)

Use fast modify operations when possible (and usually with these, an index). See Updates.

　　Profiler 的效率

Profiling 功能肯定是会影响效率的，但是不太严重，原因是他使用的是system.profile 来记录，而system.profile 是一个capped collection 这种collection 在操作上有一些限制和特点，但是效率更高。

您可能也喜欢：
MongoDB 索引数据类型优化，节省60％内存	mongodb的监控与性能优化	MongoDB 客户端 MongoVue	mongodb索引讲解与性能调优
无觅

Jaslabs的Justin Silverton列出了十条有关优化MySQL查询的语句，我不得不对此发表言论，因为这个清单非常非常糟糕。另外一个Mike也同样意识到了。所以在这个博客中，我要做两件事情，第一，指出为什么这个清单很糟糕，第二，列出我的清单，希望我的比较好些。继续看吧，无畏的读者们！

为什么那个清单很糟糕

1.他的力气没使对地方

我们要遵循的一个准则就是如果你要优化代码时，应该先找出瓶颈在哪。然而Silverton先生的力气没有用对地方。我认为60%的优化是基于清楚理解SQL和数据库基础的。你需要知道join和子查询的区别，列索引，以及如何将数据规范化等等。另外的35%的优化是需要清楚数据库选择时的性能表现，例如COUNT(*)可能很快也可能很慢，要看你选用什么数据库引擎。还有一些其他要考虑的因素，例如数据库在什么时候不用缓存，什么时候存在硬盘上而不存在内存中，什么时候数据库创建临时表等等。剩下的5%就很少会有人碰到了，但Silverton先生恰好在这上面花了大量的时间。我从来就没用过SQL_SAMLL_RESULT。

2.很好的问题，但是很糟糕的解决方法

Silverton先生提出了一些很好的问题。MySQL针对长度可变的列如TEXT或BLOB，将会使用动态行格式(dynamic row format)，这意味着排序将在硬盘上进行。我们的方法不是要回避这些数据类型，而是将这些数据类型从原来的表中分离开，放入另外一个表中。下面的schema可以说明这个想法：

CREATE TABLE posts (
    id int UNSIGNED NOT NULL AUTO_INCREMENT,
    author_id int UNSIGNED NOT NULL,
    created timestamp NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE posts_data (
    post_id int UNSIGNED NOT NULL.
    body text,
    PRIMARY KEY(post_id)
);

3. 有点匪夷所思……

他的许多建议都是让人非常吃惊的，譬如“移除不必要的括号”。你这样写SELECT * FROM posts WHERE (author_id = 5 AND published = 1)，还是这样写SELECT * FROM posts WHERE author_id = 5 AND published = 1 ，都不重要。任何比较好的DBMS都会自动进行识别做出处理。这种细节就好像C语言中是i++快些还是++i快些。真的，如果你把精力都花在这上面了，那就不用写代码了。

我的列表

看看我的列表是不是更好吧。我先从最普遍的开始。

1.建立基准，建立基准，建立基准！

如果需要做决定的话，我们需要数据说话。什么样的查询是最糟的？瓶颈在哪？我什么情况下会写出糟糕的查询？基准测试可以让你模拟高压情况，然后借助性能测评工具，可以让你发现数据库配置中的错误。这样的工具有supersmack, ab, SysBench。这些工具可以直接测试你的数据库(譬如supersmack)，或者模拟网络流量（譬如ab）。

2.性能测试，性能测试，性能测试!

那么，当你能够建立一些高压情况之后，你需要找出配置中的错误。这就是性能测评工具可以帮你做的了。它可以帮你发现配置中的瓶颈，不论是在内存中，CPU中，网络中，硬盘I/O，或者是以上皆有。

你要做的第一件事就是开启慢查询日志(slow query log)，装上mtop。这样你就能获取那些恶意的入侵者的信息了。有需要运行10秒的查询语句正在破坏你的应用程序吗？这些家伙会展示给你看他的查询语句是怎么写的。

在你发现那些很慢的查询语句后，你需要用MySQL自带的工具，如EXPLAIN，SHOW STATUS，SHOW PROCESSLIST。它们会告诉你资源都消耗在哪了，查询语句的缺陷在哪，譬如一个有三次join子查询的查询语句是否在内存中进行排序，还是在硬盘上进行。当然你也应该使用测评工具如top，procinfo，vmstat等等获取更多系统性能信息。

3.减小你的schema

在你开始写查询语句之前，你需要设计schema。记住将一个表装入内存所需要的空间大概是行数*一行的大小。除非你觉得世界上的每个人都会在你的网站注册2兆8000亿次的话，否则你不需要采用BITINT作为你的user_id。同样的，如果一个文本列是固定大小的话（譬如US邮编，通常是”XXXXX-XXXX”的形式），采用VARCHAR的话会给每行增加多余的字节。

有些人对数据库规范化不以为意，他们说这样会形成相当复杂的schema。然而适当的规范化会减少化冗余数据。（适当的规范化）就意味着牺牲少许性能，换取整体上更少的footprint，这种性能换取内存在计算机科学中是很常见的。最好的方法是IMO，就是开始先规范化，之后如果性能需要的话，再反规范化。你的数据库将会更逻辑化，你也不用过早的进行优化。（译者注，这一段我不是很理解，可能翻译错了，欢迎纠正。）

4.拆分你的表

通常有些表只有一些列你是经常需要更新的。例如对于一个博客，你需要在许多不同地方显示标题（如最近的文章列表），只在某个特定页显示概要或者全文。水平垂直拆分是很有帮助的：

CREATE TABLE posts (
    id int UNSIGNED NOT NULL AUTO_INCREMENT,
    author_id int UNSIGNED NOT NULL,
    title varchar(128),
    created timestamp NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE posts_data (
    post_id int UNSIGNED NOT NULL,
    teaser text,
    body text,
    PRIMARY KEY(post_id)
);

上面的schema是对读数据进行的优化。经常要访问的数据存在一个表中，那些不经常访问的数据放在另一个。被拆分后，不经常访问的数据占据更少的内存。你也可以优化写数据，经常更新的数据放在一个表，不经常更新的放在另一个表。这可以使缓存更高效，因为MySQL不需要让没有更新过的数据移出缓存。

5.不要过度使用artificial primary key

artificial primary key非常棒，因为他们使得schema更少的变化。如果我们将地理信息存在以美国邮编为基础的表中，如果邮编系统突然改变了，那我们就会有大麻烦了。另一方面，采用natural key有时候也很棒，譬如我们需要join多对多的关系表时，我们不应该这样：

CREATE TABLE posts_tags (
    relation_id int UNSIGNED NOT NULL AUTO_INCREMENT,
    post_id int UNSIGNED NOT NULL,
    tag_id int UNSIGNED NOT NULL,
    PRIMARY KEY(relation_id),
    UNIQUE INDEX(post_id, tag_id)
);

artificial key完全是多余的，而且post-tag关系的数量将会受到整形数据的系统最大值的限制。

CREATE TABLE posts_tags (
    post_id int UNSIGNED NOT NULL,
    tag_id int UNSIGNED NOT NULL,
    PRIMARY KEY(post_id, tag_id)
);

6.学习索引

你选择的索引的好坏很重要，不好的话可能破坏数据库。对那些还没有在数据库学习很深入的人来说，索引可以看作是就是hash排序。例如如果我们用查询语句SELECT * FROM users WHERE last_name = ‘Goldstein’，而last_name没有索引的话，那么DBMS将会查询每一行，看看是否等于“Goldstein”。索引通常是B-tree（还有其他的类型），可以加快比较的速度。

你需要给你要select,group,order,join的列加上索引。显然每个索引所需的空间正比于表的行数，所以越多的索引将会占用更多的内存。而且写数据时，索引也会有影响，因为每次写数据时都会更新对应的索引。你需要取一个平衡点，取决每个系统和实施代码的需要。

7.SQL不是C

C是经典的过程语言，对于一个程序员来说，C语言也是个陷阱，使你错误的以为SQL也是一种过程语言（当然SQL也不是功能语言也不是面向对象的）。你不要想象对数据进行操作，而是要想象有一组数据，以及它们之间的关系。经常使用子查询时会出现错误的用法。

SELECT a.id,
    (SELECT MAX(created)
    FROM posts
    WHERE author_id = a.id)
AS latest_post
FROM authors a

因为这个子查询是耦合的，子查询要使用外部查询的信息，我们应该使用join来代替。

SELECT a.id, MAX(p.created) AS latest_post
FROM authors a
INNER JOIN posts p
    ON (a.id = p.author_id)
GROUP BY a.id

8.理解你的引擎

MySQL有两种存储引擎：MyISAM和InnoDB。它们分别有自己的性能特点和考虑因素。总体来讲，MyISAM适合读数据很多的情况，InnoDB适合写数据很多的情况，但也有很多情况下正好相反。最大的区别是它们如何处理COUNT函数。

MyISAM缓存有表meta-data，如行数。这就意味着，COUNT(*)对于一个结构很好的查询是不需要消耗多少资源的。然后对于InnoDB来说，就没有这种缓存。举个例子，我们要对一个查询来分页，假设你有这样一个语句SELECT * FROM users LIMIT 5,10，而运行SELECT COUNT(*) FROM users LIMIT 5,10 时，对于MyISAM很快完成，而对InnoDB就需要和第一个语句相同的时间。MySQL有个SQL_CALC_FOUND_ROWS选项，可以告诉InnoDB运行查询语句时就计算行数，之后再从SELECT FOUND_ROWS()来获取。这是MySQL特有的。但使用InnoDB有时候是非常必要的，你可以获得一些功能（如行锁定，stord procedure等）。

9.MySQL特定的快捷键

MySQL提供了许多扩展，方便使用。譬如INSERT … SELECT, INSERT … ON DUPLICATE KEY UPDATE, 以及REPLACE。

我能用到它们时是毫不犹豫的，因为它们很方便，能在许多情况下发挥不错的效果。但是MySQL也有一些危险的关键字，应该少用。例如INSERT DELAYED,它告诉MySQL不需要立即插入数据(例如在写日志的时候)。但问题是如果在很高数据量的情况下，插入可能会被无限期延迟，导致插入队列爆满。你也可以使用MySQL的索引提示来指出哪些索引是需要使用的。MySQL大部分时间运行是不错的，但如果schema设计不好的话或语句写得不好的话，MySQL的表现可能很糟糕。

10.到这里为止吧

最后，如果你关心MySQL性能优化的话，请阅读Peter Zaitsev的关于MySQL性能的博客，他写了许多关于数据库管理和优化的博客。

原文链接：20bits.com   编译：伯乐在线?- 唐小娟

您可能也喜欢：
mysql优化-缓存篇	用mysql中的join来优化查询	Mysql中出现的＂MySQL Got error 139 from storage engine＂的原因	在mysql中对order by的字段进行优化
无觅

官方解释如下：

Description:
Since upgrading MySQL from version 4.0.xx to 4.1.11, when trying to place data into a
record it can fail with the error "#1030 - Got error 139 from storage engine". The problem
appears to be if the data reaches a certain size. I first found the problem when trying to
import a dump created by phpMyAdmin for one of my tables.

I am using the "Standard" install package from MySQL Web site. Running Apple Mac/MacOS X
10.3.9. PHP is version 4.3.10 (client API is 3.23.49).

I use phpMyAdmin to administer the DB, but I have run tests using PHP and the problem
still occurs.

I have also performed tests on my ISP's server (UNIX based) and the problem also occurs,
they are using MySQL client API of 4.1.11.

I still have access to a 4.0 server and can import the dump with no problems at all, even
using a dump from MySQL 4.1.11 using the "backward compatibility" option in phpMyAdmin.

How to repeat:
Create an InnoDB table with 1 INT field and 11 TEXT fields. 

Create an index on the INT field of type "PRIMARY". 

In the first 10 text fields, enter as many "a" characters as phpMyAdmin will allow. This
is 32000 characters in each field. Leave the last text field empty. Click "Go" to save the
changes. This should save without any problems. 

Then copy/paste field 10 to field 11 and click "Go". This results in a "#1030 - Got error
139 from storage engine" error.

If I remove the characters little by little at some point it will work, suggesting a size
problem. 

Please let me know if you need any additional information.

Hi!

In 4.1, to support at least 256-character UTF-8 column prefix indexes, InnoDB stores at
least 768 bytes of each column 'internally' to the record. With 11 TEXT fields you will
run over the 8000 byte record len limit.

./include/dict0mem.h:159:#define DICT_MAX_COL_PREFIX_LEN        768

I probably need to update the manual.

Thank you,

Heikki

Hi Heikki

Many thanks for the reply.

I read what you wrote several times, but a lot of it still went over my head, so apologies
if what I  write below is irrelevant  

Is this 8000 byte limit you mention the same one mentioned in section 15.17 of the manual,
i.e. because of the 16k database page size?

After reading the manual, section 15.17, I know:

1. The Database Page Size is set as standard as 16k - server needs recompiling to use a
new limit. From what I can see this setting affects the maximum row length for NON TEXT
and BLOB fields. If I set this limit to 64k I would expect to get a maximum of 41 TEXT
columns before this error occured?

2. Maximum Row Length for TEXT and BLOB columns is not mentioned, but 4GB limit is
mentioned for LONGTEXT and LONGBLOB columns.

3. Total Row Length cannot exceed 4GB.

4. "The internal maximum key length is 3500 bytes, but MySQL itself restricts this to 1024
bytes." - Not sure what this means  

You mentioned "column prefix indexes", not sure if the index I created is the same thing
so I removed this as well as the INT field and the problem still occurs. I.e. I had a
record with 11 TEXT fields only.

As a standard build, I find it hard to believe MySQL/InnoDB cannot support 11 TEXT fields
in one table. An 8000 byte limit for "internal" information about column prefix indexes
seems very small.

Are there any links I can read to help my confusion about what limits apply and when. More
importantly what changes can I make to help me solve this problem.

Many thanks for your time.

另外一篇介绍文章：http://www.cnblogs.com/analytics/archive/2010/10/05/1844262.html

您可能也喜欢：
优化MySQL语句的十个建议	mysql各种HA方案	深入Mysql字符集设置	MySQL远程访问时非常慢的解决办法
无觅

1） 普通插入性能 （插入的数据每条大约在1KB左右）

2） 批量插入性能 （使用的是官方C#客户端的InsertBatch），这个测的是批量插入性能能有多少提高

3） 安全插入功能 （确保插入成功，使用的是SafeMode.True开关），这个测的是安全插入性能会差多少

4） 查询一个索引后的数字列，返回10条记录（也就是10KB）的性能，这个测的是索引查询的性能

5） 查询两个索引后的数字列，返回10条记录（每条记录只返回20字节左右的2个小字段）的性能，这个测的是返回小数据量以及多一个查询条件对性能的影响

6） 查询一个索引后的数字列，按照另一个索引的日期字段排序（索引建立的时候是倒序，排序也是倒序），并且Skip100条记录后返回10条记录的性能，这个测的是Skip和Order对性能的影响

7） 查询100条记录（也就是100KB）的性能（没有排序，没有条件），这个测的是大数据量的查询结果对性能的影响

8） 统计随着测试的进行，总磁盘占用，索引磁盘占用以及数据磁盘占用的数量

并且每一种测试都使用单进程的Mongodb和同一台服务器开三个Mongodb进程作为Sharding（每一个进程大概只能用7GB左右的内存）两种方案

其实对于Sharding，虽然是一台机器放3个进程，但是在查询的时候每一个并行进程查询部分数据，再有运行于另外一个机器的mongos来汇总数据，理论上来说在某些情况下性能会有点提高

基于以上的种种假设，猜测某些情况性能会下降，某些情况性能会提高，那么来看一下最后的测试结果怎么样？

备注：测试的存储服务器是 E5620  @ 2.40GHz，24GB内存，CentOs操作系统，打压机器是E5504 @ 2.0GHz，4GB内存，Windows Server 2003操作系统，两者千兆网卡直连。

从这个测试可以看出，对于单进程的方式：

1） Mongodb的非安全插入方式，在一开始插入性能是非常高的，但是在达到了两千万条数据之后性能骤减，这个时候恰巧是服务器24G内存基本占满的时候（随着测试的进行mongodb不断占据内存，一直到操作系统的内存全部占满），也就是说Mongodb的内存映射方式，使得数据全部在内存中的时候速度飞快，当部分数据需要换出到磁盘上之后，性能下降很厉害。（这个性能其实也不算太差，因为我们对三个列的数据做了索引，即使在内存满了之后每秒也能插入2MB的数据，在一开始更是每秒插入25MB数据）。Foursquare其实也是把Mongodb当作带持久化的内存数据库使用的，只是在查不到达到内存瓶颈的时候Sharding没处理好。

2） 对于批量插入功能，其实是一次提交一批数据，但是相比一次一条插入性能并没有提高多少，一来是因为网络带宽已经成为了瓶颈，二来我想写锁也会是一个原因。

3） 对于安全插入功能，相对来说比较稳定，不会波动很大，我想可能是因为安全插入是确保数据直接持久化到磁盘的，而不是插入内存就完事。

4） 对于一列条件的查询，性能一直比较稳定，别小看，每秒能有8000-9000的查询次数，每次返回10KB，相当于每秒查询80MB数据，而且数据库记录是2亿之后还能维持这个水平，性能惊人。

5） 对于二列条件返回小数据的查询，总体上性能会比4）好一点，可能返回的数据量小对性能提高比较大，但是相对来说性能波动也厉害一点，可能多了一个条件就多了一个从磁盘换页的机会。

6） 对于一列数据外加Sort和Skip的查询，在数据量大了之后性能明显就变差了（此时是索引数据量超过内存大小的时候，不知道是否有联系），我猜想是Skip比较消耗性能，不过和4）相比性能也不是差距特别大。

7） 对于返回大数据的查询，一秒瓶颈也有800次左右，也就是80M数据，这就进一步说明了在有索引的情况下，顺序查询和按条件搜索性能是相差无几的，这个时候是IO和网络的瓶颈。

8） 在整个过程中索引占的数据量已经占到了总数据量的相当大比例，在达到1亿4千万数据量的时候，光索引就可以占据整个内存，此时查询性能还是非常高，插入性能也不算太差，mongodb的性能确实很牛。

那么在来看看Sharding模式有什么亮点：

1） 非安全插入和单进程的配置一样，在内存满了之后性能急剧下降。安全插入性能和单进程相比慢不少，但是非常稳定。

2） 对于一个条件和两个条件的查询，性能都比较稳定，但条件查询性能相当于单进程的一半，但是在多条件下有的时候甚至会比单进程高一点。我想这可能是某些时候数据块位于两个Sharding，这样Mongos会并行在两个Sharding查询，然后在把数据进行合并汇总，由于查询返回的数据量小，网络不太可能成为瓶颈了，使得Sharding才有出头的机会。

3） 对于Order和Skip的查询，Sharding方式的差距就出来了，我想主要性能损失可能在Order，因为我们并没有按照排序字段作为Sharding的Key，使用的是_id作为Key，这样排序就比较难进行。

4） 对于返回大数据量的查询，Sharding方式其实和单进程差距不是很大，我想数据的转发可能是一个性能损耗的原因（虽然mongos位于打压机本机，但是数据始终是转手了一次）。

5） 对于磁盘空间的占用，两者其实是差不多的，其中的一些差距可能是因为多个进程都会多分配一点空间，加起来有的时候会比单进程多占用点磁盘（而那些占用比单进程少的地方其实是开始的编码错误，把实际数据大小和磁盘文件占用大小搞错了）。

测试最后的各个Sharding分布情况如下：

{
"sharded" : true,
"ns" : "testdb.test",
"count" : 209766143,
"size" : 214800530672,
"avgObjSize" : 1024.0000011441311,
"storageSize" : 222462757776,
"nindexes" : 4,
"nchunks" : 823,
"shards" : {
"shard0000" : {
"ns" : "testdb.test",
"count" : 69474248,
"size" : 71141630032,
"avgObjSize" : 1024.0000011515058,
"storageSize" : 74154252592,
"numExtents" : 65,
"nindexes" : 4,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 11294125824,
"indexSizes" : {
"_id_" : 2928157632,
"Number_1" : 2832745408,
"Number1_1" : 2833974208,
"Date_-1" : 2699248576
},
"ok" : 1
},
"shard0001" : {
"ns" : "testdb.test",
"count" : 70446092,
"size" : 72136798288,
"avgObjSize" : 1024.00000113562,
"storageSize" : 74154252592,
"numExtents" : 65,
"nindexes" : 4,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 11394068224,
"indexSizes" : {
"_id_" : 2969355200,
"Number_1" : 2826453952,
"Number1_1" : 2828403648,
"Date_-1" : 2769855424
},
"ok" : 1
},
"shard0002" : {
"ns" : "testdb.test",
"count" : 69845803,
"size" : 71522102352,
"avgObjSize" : 1024.00000114538,
"storageSize" : 74154252592,
"numExtents" : 65,
"nindexes" : 4,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 11300515584,
"indexSizes" : {
"_id_" : 2930942912,
"Number_1" : 2835243968,
"Number1_1" : 2835907520,
"Date_-1" : 2698421184
},
"ok" : 1
}
},
"ok" : 1
}

虽然在最后由于时间的关系，没有测到10亿级别的数据量，但是通过这些数据已经可以证明Mongodb的性能是多么强劲了。另外一个原因是，在很多时候可能数据只达到千万我们就会对库进行拆分，不会让一个库的索引非常庞大。在测试的过程中还发现几个问题需要值得注意：

1） 在数据量很大的情况下，对服务进行重启，那么服务启动的初始化阶段，虽然可以接受数据的查询和修改，但是此时性能很差，因为mongodb会不断把数据从磁盘换入内存，此时的IO压力非常大。

2） 在数据量很大的情况下，如果服务没有正常关闭，那么Mongodb启动修复数据库的时间非常可观，在1.8中退出的-dur貌似可以解决这个问题，据官方说对读取没影响，写入速度会稍稍降低，有空我也会再进行下测试。

3） 在使用Sharding的时候，Mongodb时不时会对数据拆分搬迁，这个时候性能下降很厉害，虽然从测试图中看不出（因为我每一次测试都会测试比较多的迭代次数），但是我在实际观察中可以发现，在搬迁数据的时候每秒插入性能可能会低到几百条。其实我觉得能手动切分数据库就手动切分或者手动做历史库，不要依赖这种自动化的Sharding，因为一开始数据就放到正确的位置比分隔再搬迁效率不知道高多少。个人认为Mongodb单数据库存储不超过1亿的数据比较合适，再大还是手动分库吧。

4） 对于数据的插入，如果使用多线程并不会带来性能的提高，反而还会下降一点性能（并且可以在http接口上看到，有大量的线程处于等待）。

5） 在整个测试过程中，批量插入的时候遇到过几次连接被远程计算机关闭的错误，怀疑是有的时候Mongodb不稳定关闭了连接，或是官方的C#客户端有BUG，但是也仅仅是在数据量特别大的时候遇到几次。

最新补充：在之后我又进行了几天测试，把测试数据量进一步加大到5亿，总磁盘占用超过500G，发现和2亿数据量相比，所有性能都差不多，只是测试6和测试7在超过2亿级别数据之后，每400万记录作为一个循环，上下波动30%的性能，非常有规律。

您可能也喜欢：
MongoDB 客户端 MongoVue	mongodb的监控与性能优化	mongodb索引讲解与性能调优	Mongodb 与mysql 语法比较
无觅

一、 为什么用索引：

当查询中用到某些条件时，可以对该键建立索引，以提高查询速度。

如果数据量很多且查询多于更新时，可以用索引提高查询的速度。

二、 索引管理：

a)         查询索引：

1. 查询已有索引的明细：

查询索引很简单，比如说需要查询mailaccess数据库中的Mail collection上的索引时：

mongo                          进入mongo

MongoDB shell version: 1.8.1

connecting to: test

> use mailaccess                  进入mailaccess database

switched to db mailaccess

> db.Mail.getIndexes()             查询索引明细

[

{

"name" : "_id_",

"ns" : "mailaccess.Mail",

"key" : {

"_id" : 1

},

"v" : 0

},

{

"_id" : ObjectId("4df063ac48857df7ac35c348"),

"ns" : "mailaccess.Mail",

"key" : {

"user" : 1,

"folderId" : 1,

"mailfilename" : 1

},

"name" : "user_1_folderId_1_mailfilename_1",

"v" : 0

},

……

1. 查询索引大小：

> db.Mail.totalIndexSize()                  查询索引大小

114688                                                    索引所占大小，单位：字节

b)         创建索引：

db.Mail.ensureIndex({user:1,folderId:1,mailfilename:1})

该命令会在Mail上创建一索引，默认索引名称的规则为：

Keyname1_dir1_keyname2_dir2…，如果该索引的默认名称：

user_1_folderId_1_mailfilename_1

其中：1表示升序 -1表示降序

要是索引键很多时，最好自定义名称，如：定义名称为：index1

db.Mail.ensureIndex({user:1,folderId:1,mailfilename:1} ,{name:'index1'})

c)         删除索引：

如需删除名称为index1的索引：

db.Mail.dropIndex(‘index’)

如需删除Mail中的所有索引时：

db.Mail.dropIndex(‘*’)   _id索引不会删除

还有一种方式是删除collection，collection中的所以索引也会消失，注意：_id索引也会被删除。(删除collection中的数据不会删除索引)

d)         修改索引：

Mongodb没有单独的修改索引的方法，如果需要修改某个索引，需要先删除旧有的索引，再创建新的索引。

随着数据量的不断增长，你可能会发现某个collection需要修改索引或增加索引，此时创建索引就会很费力了，同时也很消耗性能。创建索引时mongodb默认是阻塞式，阻塞会让索引建立得更快，任何此期间的请求将不能响应。可以使用｛”background”:true｝选项在后台完成，同时也可能正常处理请求。不过这种方式也会造成请求的响应很慢。如果非紧急情况，最好在晚上统一处理。

三、 索引种类：

a)         默认索引：

Mongodb每个collection都会有一个默认主键_id，这个不能删除、也不会更名。当collection创建后，系统会自动创建一个”_id_”的索引，这个也是无法删除与更名的。

b)         单列索引：

在单个栏位上创建的索引，比如，需要对Mail的read创建升序索引：

db.Mail.ensureIndex({‘read’:1})

c)         组合索引：

对多个键创建的索引，比如，需要对Mail的user与folderId创建降序索引：

db.Mail.ensureIndex({‘user’:-1,’folderId’:-1})

d)         子文档索引：

可以为内嵌文档的键创建索引，这种与普通索引没有什么区别，比如：需要对Mail中的attachments下的filename创建索引:

db.Mail.ensureIndex({‘attachments.filename’:1})

注意：attachments.filename必须位于’’之中，否则会报错

e)         唯一索引：

唯一索引可能确保collection的每一个document指定的键的唯一性。当文档不存在指定键时，会被认为键值是“null”，所以“null”也会被认为是重复的，所以一般被作为唯一索引的键，最好都要有键值对。比如：要保证Mail中每个用户的mailfilename的唯一性：

db.Mail.ensureIndex({‘user’:1,‘filename’:1},{name:’index1’,‘unique’:true})

当为已有的collection增加唯一索引时，可能会有数据已经重复了。有时候可能希望将所有包含重复的文档都删除，可能在创建唯一索引时，使用dropDups选项：

db.Mail.ensureIndex({‘user’:1,‘filename’:1},{‘unique’:true，’dropDups’:true})

这个会将重复的数据只保留一份，不过有点鲁莽，如果数据很重要的话，建议不好这样做。

注意了：

Insert并不检查文档是否插入过，所以确保数据的唯一性，可能要用安全模式插入才行。这样，在插入时，如果有重复就会有错误提醒

f)          Sparse索引：

Sparse index解决索引文件过大的问题，有时候我们要索引的某个属性并非是所有记录都有，普通的索引是将所有的记录都包含进来，而sparse索引则仅包含含有这个属性的记录，它不会对该项值为空的行作索引。这样就大大减小了某些列的索引大小。目前的限制是，sparse index只能包含一个属性。比如：在Mail中有个标签属性labels，这个属性是唯一的，且有值的情况也不多，这种情况就最适合用sparse索引了，创建索引的命令为：

db.Mail.ensureIndex({labels:1},{sparse:true})

g) Covered 索引:

如果你查找的值正好是在索引中，则可以直接返回索引中存的值，而不用到数据文件中查找。（这个在传统关系型数据库中也有实现），不过，必须满足以下条件：

• 必须提供准备的返回字段，以便可以直接从索引库中查询
• 必须明确地排除使用_id字段{_id：0}

当用explain时，当indexOnly=true，表示有用到covered index:

// do a login with a covered index, returning the users roles/groups

> db.users.ensureIndex( { username : 1, password : 1, roles : 1} );

> db.users.save({username: "joe", password: "pass", roles: 2})

> db.users.save({username: "liz", password: "pass2", roles: 4})

> db.users.find({username: "joe"}, {_id: 0, roles: 1})

{ "roles" : 2 }

> db.users.find({username: "joe"}, {_id: 0, roles: 1}).explain()

{

"cursor" : "BtreeCursor username_1_password_1_roles_1",

...

"indexOnly" : true,

...

}

四、 正则表达式在索引中的使用：

正则表达式可以灵活地匹配查询条件，如果希望正则表达式能命中索引，就要注意了：

Mongodb能为前缀型的正则表达式命中索引，比如：需要查询Mail中user以z开头的：

/^z/

如果有user索引，这种查询很高效

但其他的即使有索引，也不会命中索引，比说：需要查询Mail中的user中含有z的：

/.*z.*/

/^.*z.*/

这种查询是不会命中到索引的，当数据量很大，速度很慢

总之，^后的条件必须明确，不能^.* ^[a-z]之类开头的

五、 索引分析：

a)         索引命中：

假设索引为:{a:1,b:1,c:1,…,z:1}：

实际上是有了：{a:1},{a:1,b:1},{a:1,b:1,c:1}…等索引的。

但是使用{b:1}、{a:1,c:1}等索引的查询是会被优化的，只有使用索引前部的查询才能使用该索引。

Mongodb的查询优化器会重排查询项的顺序，以便命中索引，比如：查询{x:’a’,y:’b’}的时候，如果已有了{y:1,x:1}的索引，mongodb也会自己找到并命中的。

创建索引的缺点是每次插入、更新与删除时都会产生额外的开销，这是因为数据库不但需要执行这些操作，还是处理索引，因些，要尽量可能少创建索引。每个集合默认的最大索引个数为64个。

b)         查询时，不要使用$ne or $nin，这样不能命中索引

c)         使用explain

db.collection.find(query).explain();

返回的信息如下

{“cursor” : “BasicCursor”,

“indexBounds” : [ ],

“nscanned” : 57594,

“nscannedObjects” : 57594,

“nYields” : 2 ,

“n” : 3 ,

“millis” : 108,

“indexOnly” : false}

现实结果可以得知cursor的类型，DB扫描的数据数，返回的数据数，还有执行的毫秒数。

“cursor” : “BasicCursor”：

命中的索引，当为BasicCursor时表示没有命中任何索引

indexBounds: 所使用的索引，被设置为表示为索引扫描的关键边界。

nscanned – 扫描的数据条数。

nscannedObjects – 扫描对象的数。

nYields – 查询所产生的锁的个数。

isMultiKey- MongoDB中提供了可以自动索引数组对象的值

If true, a multikey index was used.

n- 返回文档的数量

millis- 数据库中执行查询的时间

indexOnly – 是否使用了covered index。

六、 强制索引：

如果发现mongodb用了非预期的索引，可以用hint强制用某个索引，如：

db.Mail.find({user:’zhaoxy1@szdep.com’,folderId:’inbox’}).hint(‘index1’)

多数情况下这种指定没有什么必要，mongodb会替你选择用哪个索引，初次查询时，查询优化器会同时尝试各种查询方案，最先完成的被确定使用，其他的则终止掉。查询方案也会记录下来，以备是后应对相同键的查询，查询优化器定期也重试其他的方案，以防因为添加新的数据后，之前的方案不再是最优的。

七、 为排序创建索引：

随着集合的增长，如果查询中有用到排序时，就要创建索引了。如果对没有索引的键用sort，mongodb需要将所有的数据提到内存中进行排序，这个是很影响性能的。

八、 索引优化：

这个是有人统计的不同数据类型所占的索引的大小：

另外，如果有关于日期的索引，我针对于String/Long/Date做了下测试：

可以看出，用Date类型所占的索引最小(Long/Date所占的大小差不多，1000w时也只相差3M左右)，所以如果有需要日期索引的，需要将类型设置为Date或Long

九、 实例讲解：

以MA为例，场景为：

1. 获取某个邮件夹的所有邮件列表
2. 查看某个邮件夹中的已读邮件
3. 查看某个邮件夹中的未读邮件
4. 查看某个邮件夹中的重要邮件
5. 查看某个邮件夹中的邮件来源

索引为：

{user:1,folderId:1,sendTime:-1,read:1,sourceSystem:1,importantFlag:1},{name:’folder_list_index’}

需要用到的查询条件组合(都需要以sendTime降序排列)：

user:1,folderId:1,read:1,sourceSystem:1,importantFlag:1

user:1,folderId:1, read:1,sourceSystem:1

user:1,folderId:1,read:1

user,folderId, sourceSystem:1,importantFlag:1

user,folderId, sourceSystem:1

（红包部分必须hint，否则第一次速度会很快）

设计规则：

1. 索引中的栏位，尽量用int类型，这样可减少索引的内存大小。

比如：sendTime的类型为Long，read、sourceSystem、importantFlag的类型为int

2.    索引的组合尽量包含常见的查询：

比如：获取邮件夹列表，查看邮件夹中的已读、未读邮件、重要邮件这几个查询很常用，设计索引时尽量包括这些查询

3.   有需要排序的栏位，要建索引，否则mongodb会在内存中排序。另外，排序索引尽量加在某个固定的大范围之后。

比如：获取邮件夹列表并按照sendTime降序排列，查询条件的大范围肯定要有user/folderId，此时，可将sendTime放在user/folderId之后，这样user/folderId对应的记录已经都以sendTime:-1的形式存放在索引库中（此时，用sort与不用sort的效果是相同的），sort时，也不用在内存中进行排序。如果有其他查询都在这个范围之内时，即使不能自动命中索引，也可以通过强制索引来提高查询的速度

4. 查询列表范围尽量小，数据量很多时，不加limit的查询会死人的。

您可能也喜欢：
mongodb的监控与性能优化	MongoDB 索引数据类型优化，节省60％内存	Mongodb亿级数据量的性能测试	Mongodb 与mysql 语法比较
无觅

虽然能够想像得到，但是直观的数据图可能让我们更深刻的认识到。他们的测试再一次告诉我们：给索引定一个好的数据结构是多么重要。

这是测试结果图，分别是用int、MongoDB的ObjectID、base64和md5的字符串做索引产生的索引大小：

测试过程也非常简单，首先用下面脚本将各种不同数据结构的数据写入到不同的collection里：

#!/usr/bin/env python

import pymongo
import bson
from pymongo import Connection

db = connection.test_database

print('ObjectID')
for i in range(1, 1000000):
    db.objectids.insert({'i': i})

print('int')
for i in range(1, 1000000):
    db.ints.insert({'_id': i, 'i': i})

print('Base64 BSON')
for i in range(1, 1000000):
    db.base64s.insert({'_id': \
        bson.Binary(hashlib.md5(str(i)).digest(),
        bson.binary.MD5_SUBTYPE), 'i': i})

print('string')
for i in range(1, 1000000):
    db.strings.insert({'_id': hashlib.md5(str(i)).digest(), 'i': i})

然后获取每个collection的index大小，得到如下的结果，画成上面的图：

> db.base64s.stats()
{
        "totalIndexSize" : 67076096,
}
> db.objectids.stats()
{
        "totalIndexSize" : 41598976,
}
> db.ints.stats()
{
        "totalIndexSize" : 32522240,
}
> db.strings.stats()
{
        "totalIndexSize" : 90914816,

}

原文链接：How to save 200% RAM by selecting the right key data type for #MongoDB

相关教程：

三招解决MongoDB的磁盘IO问题

您可能也喜欢：
MongoDB数据库优化：Mongo Database Profiler	mongodb索引讲解与性能调优	mongodb的监控与性能优化	Mongodb 与mysql 语法比较
无觅