导读：

         淘宝丁奇分享的PPT：MySQL数据库的IO操作，详细分享了四块的内容，并且告诉大家如何调整MySQL数据库IO操作相关的参数，给出了详细的选择策略，现替其整理成文章分享与此。

PPT内容提纲：

1.MySQL的文件及简介

2.数据访问流程

3.文件访问模式

4.影响io行为的一些参数和选择策略

1.MySQL的文件及简介

2.数据访问流程

一个简单的查询 select * from t where id>=(  select id from t where k1=100 limit 100000,1) limit 2;

表结构：

CREATE TABLE t (

id int(11) NOT NULL,

k1 int(11) DEFAULT NULL,

data char(100) DEFAULT NULL,

PRIMARY KEY (id),

KEY k1 (k1)

) ENGINE=InnoDB DEFAULT CHARSET=gbk;

3.数据访问流程

4.数据访问流程

一个简单的更新   insert into t values(1, 100, ‘abcd’);

5.文件访问模式

1. *.frm

表定义文件。访问特点：极少改动、整体访问–什么模式最适合？

2. *ibd

表数据文件。访问特点：大量随机读写–什么模式最适合？

内部什么样？

MongoDB的 PHP 客户端有一个 MongoCursor 类，它是用于获取一次查询结果集的句柄（或者叫游标），这个简单的取数据操作，内部实现其实不是那么简单。本文就通过对 MongoCursor 类一些操作进行分析，向大家揭开 MongoDB 客户端服务器通信的一些内部细节。

getNext与网络请求

通常来说，每一次find操作都会返回一个MongoCursor对象，在这个对象上调用getNext方法，就能够获得一条结果数据。循环调用getNext方法就能获取多条数据。下面我们就来看看其内部取数据的具体逻辑。

首先我们用最简单的方法来生成一个MongoCursor对象：

$m = new Mongo();
$collection = $m->demoDb->demoCollection;
$cursor = $collection->find();

当我们调用 find 方法的时候，会生成一个 MongoCursor 对象，而这时候只是生成一个内存中的对象而已，并不会把我们的 find 查询发送到服务端，因为在生成 MongoCursor 对象后，我们还可能对它做一些其它操作，比如 sort，limit 等等。这就对查询条件进行了改变。

那什么时候 PHP 会对 MongoDB 发起 find 的网络请求呢，是在 MongoCursor 调用 getNext 方法的时候。比如我们在上面代码的基础上，再执行 sort 和 getNext 两个方法：

$cursor->sort( array( 'name' => 1 ) );
$result = $cursor->getNext();

这时候第二行代码就会触发 find 的网络请求，具体请求的内容如下图，下图是对这次请求的二进制协议进行解析后的数据结构展示：

从上面图中我们可以看到，Number to Return 字段是0，MongoDB 协议里0表示不做限制，获取全部数据。所以这一次的 find 操作会把所有这个 collection 中的所有数据都拿到。而我们调用一次 getNext 实际上只拿到一条数据。那是不是说我们每调一次 getNext，PHP 就会进行一次网络请求获取一条数据呢？结果当然是否定的，这样效率未免也太低了。那好，那是不是 PHP 在第一次调用 getNext 就把所有数据拿回来，存在内存中，然后后续的 getNext 调用都在本地内存里取就行了呢？结果还是否定的，这样数据量大点 PHP 就容易被暴菊了吧。

今天在同事那里看到了一个很不错的MongoDB的客户端工具MongoVue，地址是http://www.mongovue.com/。做的不错，1.0版本的开始收费了，费用也不贵才35＄。真正需要的同学可以掏点钱买个吧，也算是支持这个工具，如果只是学习研究用的话我这里还有一个0.9.7版本，虽然比起1.0版来说有些bug，平常使用也够了，需要的同学可以单独联系我。

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

ps和pstree是用于系统分析的基本命令。ps有3中不同风格的命令选项，UNIX风格、BSD风格和GNU风格。这里我们只介绍UNIX风格选项。

ps命令可以显示当前运行的进程列表。top命令也可以显示进程信息，但ps可以提供更加详细的内容。使用相应选项可以影响进程显示的数量。ps -A命令可以列出所有进程及其相应的进程ID（PID），当我们使用如pmap或renice等工具时会用到此PID。

当系统运行java应用时，ps -A产生的输出结果很容易填满整个显示区域，这导致很难得到所有运行中进程的完整视图。在这种情况下，pstree命令就派上用场了，它使用树状显示所有运行中的进程并合并所有的子进程（例如java线程），pstree命令有助于确认原始进程。还有另一个ps变种pgrep也非常有用。

例子2-4：ps输出示例

下面我们来了解一些常用的选项

-e ：所有进程。等同于-A

-l ：显示长格式

-F ：附加全格式

-H ：显示进程的层次结构

-L ：显示线程，可能出现LWP和NLWP栏位

-m ：在进程后显示线程

下面的命令演示输出进程的详细信息：

ps -elFL

例子2-5：输出进程详细信息示例

输出栏位说明：

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 ：启动任务的命令行（包括参数）

导读：本文作者Jeff Miller是美食网页应用Punchfork的创始人，同时也是DuckDuckGo、Ginzametrics、Art.sy、DataMinr以及Forkly的投资人。作者通过对自己创业初期一些错误选择进行盘点，告诉读者在创业初期应该学会选择，因为在创业初期，时间是最宝贵的财富。

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

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

回顾我自己创业的这六个月，发现自己对时机的选择真的是非常糟糕的。我经常在某项工作上花费大量时间，而最后对达成目标却没有任何效果。我特别容易偏爱短期（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。

mongodb与mysql命令对比

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

MySQL

MongoDB

说明

mysqld

mongod

服务器守护进程

mysql

mongo

客户端工具

mysqldump

mongodump

逻辑备份工具

mysql

mongorestore

逻辑恢复工具

db.repairDatabase()

修复数据库

mysqldump

mongoexport

数据导出工具

source

mongoimport

数据导入工具

grant * privileges on . to …

Db.addUser()

Db.auth()

新建用户并权限

show databases

show dbs

显示库列表

Show tables

Show collections

显示表列表

Show slave status

Rs.status

查询主从状态

Create table users(a int, b int)

db.createCollection(“mycoll”, {capped:true,

size:100000}) 另：可隐式创建表。

创建表

Create INDEX idxname ON users(name)

db.users.ensureIndex({name:1})

创建索引

Create INDEX idxname ON users(name,ts DESC)

在MySQL中，慢查询日志是经常作为我们优化数据库的依据，那在MongoDB中是否有类似的功能呢?答案是肯定的，那就是Mongo Database Profiler.不仅有，而且还有一些比MySQL的Slow Query Log更详细的信息。它就是我们这篇文章的主题。

**　　开启 Profiling 功能**

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

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

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

{“was” : 0 , “ok” : 1}

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

0 – 不开启

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

2 – 记录所有命令

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

　　db.setProfilingLevel( level , slowms )

db.setProfilingLevel( 1 , 10 );

**　　查询 Profiling 记录**

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

　　> db.system.profile.find()

{“ts” : “Thu Jan 29 2009 15:19:32 GMT-0500 (EST)” , “info” : “query test.$cmd ntoreturn:1 reslen:66 nscanned:0

(译者注：作者借这个题目反讽另一篇同名的文章)

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快些。真的，如果你把精力都花在这上面了，那就不用写代码了。

今天再从excel里导入数据到Mysql中的时候，发现一个表里的数据总是导入失败．后来经过查找是用的INNODB表引擎的问题．而换成MYISAM表引擎的话，则不存在此问题．并试图先导入成Myisam表，然后手动修改表引擎为INNODB.结果提示＂MySQL Got error 139 from storage engine＂错误．经google一番发现．是由于INNODB单条记录有8K的限制，而导入的excel表里字段不到20个．内容特别的多的．

官方解释如下：

Solution:

1.divide your table into small ones. If one table contain more than 10 text colums, and the data contain is a little bit long. this error will be thrown out.

2.modify InnoDB to MyISAM.Problem description:

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.

[21 Apr 2005 7:02] Heikki Tuuri

进行了一下Mongodb亿级数据量的性能测试，分别测试如下几个项目：

（所有插入都是单线程进行，所有读取都是多线程进行）

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 }

mongodb索引规则基本上与传统的关系库一样，大部分优化MySQL/Oracle/SQLite索引的技巧也适用于mongodb。

一、 为什么用索引：

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

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

二、 索引管理：

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

},

最近trunk.ly的工程师通过mongostat发现了大量的page fault，然后通过检查发现，他们的索引已经超出内存限制了（没有keep all index in RAM）。于是他们决定开始减小索引大小，通过测试得出了如下的数据，不同的数据类型的索引大小有2到3倍的差距。

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

这是测试结果图，分别是用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的监控

mongostat是mongdb自带的状态检测工具，在命令行下使用。它会间隔固定时间获取mongodb的当前运行状态，并输出。如果你发现数据库突然变慢或者有其他问题的话，你第一手的操作就考虑采用mongostat来查看mongo的状态。

它的输出有以下几列：

• inserts/s 每秒插入次数
• query/s 每秒查询次数
• update/s 每秒更新次数
• delete/s 每秒删除次数
• getmore/s 每秒执行getmore次数
• command/s 每秒的命令数，比以上插入、查找、更新、删除的综合还多，还统计了别的命令
• flushs/s 每秒执行fsync将数据写入硬盘的次数。
• mapped/s 所有的被mmap的数据量，单位是MB，
• vsize 虚拟内存使用量，单位MB
• res 物理内存使用量，单位MB
• faults/s 每秒访问失败数（只有Linux有），数据被交换出物理内存，放到swap。不要超过100，否则就是机器内存太小，造成频繁swap写入。此时要升级内存或者扩展
• locked % 被锁的时间百分比，尽量控制在50%以下吧
• idx miss % 索引不命中所占百分比。如果太高的话就要考虑索引是不是少了
• q t|r|w 当Mongodb接收到太多的命令而数据库被锁住无法执行完成，它会将命令加入队列。这一栏显示了总共、读、写3个队列的长度，都为0的话表示mongo毫无压力。高并发时，一般队列值会升高。
• conn 当前连接数
• time 时间戳

二.mongodb的优化

mongodb可以通过profile来监控数据，进行优化。

查看当前是否开启profile功能用命令

db.getProfilingLevel() 返回level等级，值为0|1|2，分别代表意思：0代表关闭，1代表记录慢命令，2代表全部

开始profile功能为

db.setProfilingLevel(level); #level等级，值同上

level为1的时候，慢命令默认值为100ms，更改为db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)这样就更改为50毫秒

通过db.system.profile.find() 查看当前的监控日志。

如：

Js代码

1.  db.system.profile.find({millis:{$gt:500}})

2. { “ts” : ISODate(“2011-07-23T02:50:13.941Z”), “info” : “query order.order reslen:11022 nscanned:672230 \nquery: { status: 1.0 } nreturned:101 bytes:11006 640ms”, “millis” : 640 }

MMS (MongoDB Monitoring Service) is a hosted application created by 10gen for monitoring MongoDB deployments. MMS Collects statistics on all key server and hardware indicators and presents this data through an intuitive web interface

先简单说下原理：

1、在mms服务器上添加mongodb服务器的ip,端口，user，password. 2、在mongodb服务器所在的内网空闲机器上安装定制的agent脚本。 3、agent脚本从mms获取你的服务器Ip及端口等信息，然后连接到mongodb服务器获取必要的监控数据。 4、agent脚本将监控信息上传到mms服务器，我们登陆后就可以查看到相应的信息了。

主页地址如下

１. https://mms.10gen.com/help/install.html

在Hosts项上点击添加，此处hostname填写内网IP，port为mongodb端口，user/password为用户名和密码。

首先得检查一下服务器上的python版本

测试服务器上python版本为2.4

需要安装pymongo,simplejson,hashlib,hmac等包

可以先安装 python的setuptools.

sudo apt-get install python-setuptools

然后依次安装：easy_install simplejson hmac hashlib

再安装 pymongo

可能需要安装依赖

先执行

apt-get install build-essential python-dev

yum 命令

yum install gcc python-devel

安装 easy_install pymongo

新开了一个vps,装了最新的nginx 1.0.2版本，将原来的虚拟主机配置直接拿过来．用nginx -t 测试语法的时候，发现提示以下警告信息

[root@centos nginx]# ./sbin/nginx -t nginx: [warn] the “log_format” directive may be used only on “http” level in /usr/local/nginx/conf/vhosts/bbs.conf:62

解决办法如下：

将/usr/local/nginx/conf/nginx.conf 里server段里的下面代码移出放到该server段的前面即可。

log_format  access  ‘$remote_addr – $remote_user [$time_local] “$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘ ‘”$http_user_agent” $http_x_forwarded_for’;

如果有其的虚拟主机开启了日志，也按上面的要求移出server段放在server段的前面即可。

再**/usr/local/nginx/sbin/nginx -t** 测试一下，没有warn警告信息了。

[root@centos vhosts]# ../../sbin/nginx -t nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful [root@centos vhosts]#