这是之前发布于《程序员》杂志2011年08期的一篇文章，这里再在Blog上发布一下。
在当前这个信息量飞速增长的时代，一个企业，尤其是电子商务企业的成功已经越来越多地与其海量数据处理能力相关联。高效、迅速地从海量数据中挖掘出潜在价值并转化为决策依据的能力，将成为企业的核心竞争力。
数据的重要性毋庸置疑，但随着数据的产生速度越来越快，数据量越来越大，数据处理技术的挑战自然也越来越大。如何从海量数据中挖掘出价值所在，分析出深层含义，进而转化为可操作的信息，已经成为各互联网企业尤其是电子商务公司不得不研究的课题。本文将介绍国内箱包行业电子商务领军者麦包包如何利用海量数据的分析处理（个性化推荐引擎）来协助用户更好地完成购买体验。
- 图1 数据层基础架构
数据层基础架构
如图1所示，麦包包的数据层基础架构与其他很多互联网公司相比，可能会有一点儿差异，那就是有一个用于实时分析处理的在线分析数据层，用来处理一些对实时性要求较高的分析任务。
总的来说，麦包包的数据层分为下面三个部分。
用于存放网站对外访问数据，如交易相关、产品相关、用户相关等数据。
用于分析各种报表、数据挖掘，如购买行为、销售分析、浏览跟踪等。
用于处理一些对实时性要求较高的分析，如在线交易分析、用户浏览推荐等。在线交易数据层和离线分析数据层对于大家来说都已经比较熟悉了，二者的数据特点和访问特点都很清晰明确，架构方向也相对明确。只有在线分析系统比较特别，既有高并发的用户访问，同时又兼具了分析型复杂查询及海量的基础数据，构建起来相对要复杂一些。所以下面简单介绍一下麦包包如何构建在线分析系统的应用之一——“个性化推荐引擎”。
个性化推荐引擎
我们首先分析一下这个推荐引擎的需求。
根据用户的喜好倾向以及访问历史记录，不同用户浏览同一个产品时，将给出不同的关联推荐结果。
不同用户访问同一个页面，我们将会根据用户的以往购买历史及浏览行为而展示个性化的内容。
随着用户的多次搜索及结果点击行为，我们会对搜索结果进行过滤重组，尽可能展示更符合用户需求的搜索结果。也就是说，在完全相同的基础数据中，不同用户在同一时间搜索同一个关键词，可能会给出不一样的结果；或者同一个用户重复多次搜索同一个关键词，也可能会有不一样的结果。
我们再来看一看推荐引擎的数据特点。
超过500万会员，5位数的SKU，7位数的访问量。将这些数据与会员及SKU的各类属性相互关联，数据量之庞大可想而知。
从性能优化角度来说，数据量大并不可怕，只要访问方式简单，很容易通过索引等手段进行优化。可偏偏不幸的是，由于将用户和产品进行多维度关联，既需要根据用户去分析，又需要根据产品去关联，再辅以运行时的各类属性；既可能各个维度同时存在，也可能只有任何一个维度；多维度就多维度吧，可还有很多访问是分析型，比较难以优化扩展。
当然，数据量大也并不一定就可怕，如果并发访问较小，响应时间要求不是太高，那也容易解决，可以用Hadoop之类的分布式系统来分析计算。可恰恰不巧的就是这个系统面对的是网站上的访问客户，对并发及响应时间的要求和OLTP系统一样。
需求已经确定，数据特点也已了解，下一步就是根据数据的特点，设计一个切实可行的架构来实现这些应用需求了。
在如此海量数据中进行高并发的复杂分析查询，还要能够快速响应，看上去就像是一个不可能的任务。但仔细分析之后，我们不难发现，推荐引擎结果主要由以下几个因素决定。
- 用户固定属性：年龄、性别、职业类型、地域、价格承受范围、色彩喜好、品牌喜好等。
以上四个因素实际上对应了四种数据，在分析每一种数据的特点之后，可以发现前面三个因素所对应的数据都是相对静态的，只有用户当前行为才是一个在不断变化的动态数据。也就是说，在海量数据中，只有少部分数据是动态的，其他大部分都是静态。
当然，用户属性中的各种喜好，也需要我们通过用户以往的历史购买以及浏览行为进行各种分析挖掘才能获得，但这都是由历史积淀数据分析得来，而不是由当前的运行时动态数据决定。价格承受范围以及地域特性也同样如此。
数据的这一特性对我们的架构设计起到了一个非常关键的作用，因为我们可以使用完全不同的方式来将静态数据和动态数据分开处理，再合并分析。静态数据的变化较小，实时性要求较低，我们将进行离线分析；动态数据相对较少，但实时性要求较高，我们在线实时处理。动、静数据在线合并分析。这样一来，我们就可以很轻松地绕过海量数据的高并发在线分析的问题，将这一动作交由离线分析系统定时作业批量完成，既不会有高并发问题，又不存在响应时间的压力。至于在线实时数据的处理，由于数据量的大幅缩减，以及访问方式的简化，比在线交易的OLTP系统复杂度高不了太多，自然也就容易优化了。
- 图2 推荐引擎基本架构
架构设计
简单来说，推荐引擎系统本身的基础架构就如图2所展现的一样，一部分数据进行离线计算，另一部分数据在线计算合并，最终通过推荐引擎API将数据处理后返回给前端应用。
看上去简单，但有几个问题并没有展现出来，那就是离线计算和在线计算这两部分具体是如何构建的？数据如何进入离线计算系统？又如何将离线运算结果回送至在线计算系统中？最终数据又如何交由前端应用使用？让我们再来看看图3。
离线分析层完全可以通过成熟的产品来构建，如Greenplum、Hadoop等，目前我们已经使用了Greeplum，后续很快还会引入Hadoop，通过HBase + Hive来对处理我们的用户与各SKU的关系数据，帮助进一步完善我们的协同过滤算法，进而优化推荐引擎。在线合并分析层我们选择MySQL数据库。可能有些人会问，为什么不使用当前如此流行的NoSQL产品呢？主要原因有以下两点。
NoSQL产品虽然流行，但每种产品都还只适于某些特定的应用场景，很多听上去完美的理论目前暂时还仅仅只是听上去完美，实际用起来仍然存在各种各样的问题。所以我们选择了更适合于我们的MySQL作为在线合并分析层的数据库。
图3 推荐引擎整体架构
整个架构的数据流，如图3所示。
- 前端应用产生用户的浏览日志、购买日志、搜索日志以及用户及产品属性数据进入。
- 通过文件日志收集程序以及基于MySQL开放复制协议所定制的数据同步工具（注：在我的个人网站上有介绍：http://isky000.com/database/mysql-replication-extend）将数据同步至离线分析系统中。
- 通过离线任务的统计分析，得出会员的各种喜好属性，并将之与产品属性进行关联分析，得出一个用户产品倾向性关联结果，然后再通过应用程序定期从离线分析系统将上述分析结果写入在线合并分析数据库中。
- 推荐引擎根据前端应用（如Search）传入的用户当前运行时操作属性，与在线合并分析数据库中属性进行合并（Merge），再过滤（Filter）。
- 前端应用从推荐引擎处获取Merge与Filter之后的数据，再在前端页面上完成展现。
以上就是整个推荐引擎的数据流架构方案，乍一看也没有太多特别的内容，但在实际实施过程中，会遇到以下几个难点。
- 各种日志传输到离线分析系统，如何做到尽可能实时并不影响在线系统。
这个难点，我们首先在每一个页面部署监测点，通过请求一个gif图片来获得用户的各种浏览信息，并存入到MySQL数据库，交易相关的数据自然也会有在数据库中进行存储。然后使用通过扩展MySQL复制协议而实现的日志解析合并程序，实时解析 MySQL日志，再将其以我们需要的格式传输至离线分析系统中进行分析运算。
- 如何将用户的运行时操作属性与我们的离线分析结果进行Merge及Filte。
这个难点，实际上在6月刊的《程序员》杂志对麦包包首席架构师盛国军的采访稿中，已经有了相应的介绍。我们主要使用了基于用户（User）、商品（Item）、话题（Topic）以及曝光（Exposure）这四种协同过滤技术，来实现推荐算法。
总的来说，数据量的增长，以及分析需求的越来越复杂，将会对互联网公司的数据处理能力提出越来越高的要求、越来越大的挑战。但每一个场景都有其特性，充分分析其数据特性，将合适的软件用在合适的场景下，才能更好地解决实际问题。
MySQL, recommendation, replication
接着上一篇 MySQL 数据库性能优化之缓存参数优化 ，这是 MySQL数据库性能优化专题 系列的第二篇文章：MySQL 数据库性能优化之表结构
很多人都将 数据库设计范式 作为数据库表结构设计“圣经”，认为只要按照这个范式需求设计，就能让设计出来的表结构足够优化，既能保证性能优异同时还能满足扩展性要求。殊不知，在N年前被奉为“圣经”的数据库设计3范式早就已经不完全适用了。这里我整理了一些比较常见的数据库表结构设计方面的优化技巧，希望对大家有用。
由于MySQL数据库是基于行（Row）存储的数据库，而数据库操作 IO 的时候是以 page（block）的方式，也就是说，如果我们每条记录所占用的空间量减小，就会使每个page中可存放的数据行数增大，那么每次 IO 可访问的行数也就增多了。反过来说，处理相同行数的数据，需要访问的 page 就会减少，也就是 IO 操作次数降低，直接提升性能。此外，由于我们的内存是有限的，增加每个page中存放的数据行数，就等于增加每个内存块的缓存数据量，同时还会提升内存换中数据命中的几率，也就是缓存命中率。
- 数据类型选择
数据库操作中最为耗时的操作就是 IO 处理，大部分数据库操作 90% 以上的时间都花在了 IO 读写上面。所以尽可能减少 IO 读写量，可以在很大程度上提高数据库操作的性能。
我们无法改变数据库中需要存储的数据，但是我们可以在这些数据的存储方式方面花一些心思。下面的这些关于字段类型的优化建议主要适用于记录条数较多，数据量较大的场景，因为精细化的数据类型设置可能带来维护成本的提高，过度优化也可能会带来其他的问题：
- 数字类型：非万不得已不要使用DOUBLE，不仅仅只是存储长度的问题，同时还会存在精确性的问题。同样，固定精度的小数，也不建议使用DECIMAL，建议乘以固定倍数转换成整数存储，可以大大节省存储空间，且不会带来任何附加维护成本。对于整数的存储，在数据量较大的情况下，建议区分开 TINYINT / INT / BIGINT 的选择，因为三者所占用的存储空间也有很大的差别，能确定不会使用负数的字段，建议添加unsigned定义。当然，如果数据量较小的数据库，也可以不用严格区分三个整数类型。
- 字符类型：非万不得已不要使用 TEXT 数据类型，其处理方式决定了他的性能要低于char或者是varchar类型的处理。定长字段，建议使用 CHAR 类型，不定长字段尽量使用 VARCHAR，且仅仅设定适当的最大长度，而不是非常随意的给一个很大的最大长度限定，因为不同的长度范围，MySQL也会有不一样的存储处理。
- 时间类型：尽量使用TIMESTAMP类型，因为其存储空间只需要 DATETIME 类型的一半。对于只需要精确到某一天的数据类型，建议使用DATE类型，因为他的存储空间只需要3个字节，比TIMESTAMP还少。不建议通过INT类型类存储一个unix timestamp 的值，因为这太不直观，会给维护带来不必要的麻烦，同时还不会带来任何好处。
- ENUM & SET：对于状态字段，可以尝试使用 ENUM 来存放，因为可以极大的降低存储空间，而且即使需要增加新的类型，只要增加于末尾，修改结构也不需要重建表数据。如果是存放可预先定义的属性数据呢？可以尝试使用SET类型，即使存在多种属性，同样可以游刃有余，同时还可以节省不小的存储空间。
- LOB类型：强烈反对在数据库中存放 LOB 类型数据，虽然数据库提供了这样的功能，但这不是他所擅长的，我们更应该让合适的工具做他擅长的事情，才能将其发挥到极致。在数据库中存储 LOB 数据就像让一个多年前在学校学过一点Java的营销专业人员来写 Java 代码一样。
- 字符编码
字符集直接决定了数据在MySQL中的存储编码方式，由于同样的内容使用不同字符集表示所占用的空间大小会有较大的差异，所以通过使用合适的字符集，可以帮助我们尽可能减少数据量，进而减少IO操作次数。
- 纯拉丁字符能表示的内容，没必要选择 latin1 之外的其他字符编码，因为这会节省大量的存储空间
- 如果我们可以确定不需要存放多种语言，就没必要非得使用UTF8或者其他UNICODE字符类型，这回造成大量的存储空间浪费
- MySQL的数据类型可以精确到字段，所以当我们需要大型数据库中存放多字节数据的时候，可以通过对不同表不同字段使用不同的数据类型来较大程度减小数据存储量，进而降低 IO 操作次数并提高缓存命中率
- 适当拆分
有些时候，我们可能会希望将一个完整的对象对应于一张数据库表，这对于应用程序开发来说是很有好的，但是有些时候可能会在性能上带来较大的问题。
当我们的表中存在类似于 TEXT 或者是很大的 VARCHAR类型的大字段的时候，如果我们大部分访问这张表的时候都不需要这个字段，我们就该义无反顾的将其拆分到另外的独立表中，以减少常用数据所占用的存储空间。这样做的一个明显好处就是每个数据块中可以存储的数据条数可以大大增加，既减少物理 IO 次数，也能大大提高内存中的缓存命中率。
上面几点的优化都是为了减少每条记录的存储空间大小，让每个数据库中能够存储更多的记录条数，以达到减少 IO 操作次数，提高缓存命中率。下面这个优化建议可能很多开发人员都会觉得不太理解，因为这是典型的反范式设计，而且也和上面的几点优化建议的目标相违背。
MySQL, MySQL数据库性能优化专题, performance tuning
在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。
这是 MySQL数据库性能优化专题 系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化
数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化：
- query_cache_size/query_cache_type （global）
Query cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求（未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache），MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤（如 SQL语句的解析，优化器优化以及向存储引擎请求数据等），极大的提高性能。
当然，Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。
Query Cache的使用需要多个参数配合，其中最为关键的是 query_cache_size 和 query_cache_type ，前者设置用于缓存 ResultSet 的内存大小，后者设置在何场景下使用 Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）来进行调整。query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有显示要求才使用query cache（使用sql_cache）。
- binlog_cache_size （global）
Binlog Cache 用于在打开了二进制日志（binlog）记录功能的环境，是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。
一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件（binlog_cache_disk_use）来缓存了。
- key_buffer_size （global）
Key Buffer 可能是大家最为熟悉的一个 MySQL 缓存参数了，尤其是在 MySQL 没有更换默认存储引擎的时候，很多朋友可能会发现，默认的 MySQL 配置文件中设置最大的一个内存参数就是这个参数了。key_buffer_size 参数用来设置用于缓存 MyISAM存储引擎中索引文件的内存区域大小。如果我们有足够的内存，这个缓存区域最好是能够存放下我们所有的 MyISAM 引擎表的所有索引，以尽可能提高性能。
此外，当我们在使用MyISAM 存储的时候有一个及其重要的点需要注意，由于 MyISAM 引擎的特性限制了他仅仅只会缓存索引块到内存中，而不会缓存表数据库块。所以，我们的 SQL 一定要尽可能让过滤条件都在索引中，以便让缓存帮助我们提高查询效率。
- bulk_insert_buffer_size （thread）
和key_buffer_size一样，这个参数同样也仅作用于使用 MyISAM存储引擎，用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候，会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件：
insert … select …
insert … values (…) ,(…),(…)…
load data infile… into… (非空表)
- innodb_buffer_pool_size（global）
当我们使用InnoDB存储引擎的时候，innodb_buffer_pool_size 参数可能是影响我们性能的最为关键的一个参数了，他用来设置用于缓存 InnoDB 索引及数据块的内存区域大小，类似于 MyISAM 存储引擎的 key_buffer_size 参数，当然，可能更像是 Oracle 的 db_cache_size。简单来说，当我们操作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。
和key_buffer_size 对于 MyISAM 引擎一样，innodb_buffer_pool_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小，直接关系到 InnoDB存储引擎的性能，所以如果我们有足够的内存，尽可将该参数设置到足够打，将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中，直至全部。
我们可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。
- innodb_additional_mem_pool_size（global）
这个参数我们平时调整的可能不是太多，很多人都使用了默认值，可能很多人都不是太熟悉这个参数的作用。innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL Instance中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。
这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL 会记录 Warning 信息到数据库的 error log 中，这时候你就知道该调整这个参数大小了。
- innodb_log_buffer_size （global）
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：
0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。
- innodb_max_dirty_pages_pct （global）
这个参数和上面的各个参数不同，他不是用来设置用于缓存某种数据的内存大小的一个参数，而是用来控制在 InnoDB Buffer Pool 中可以不用写入数据文件中的Dirty Page 的比例（已经被修但还没有从内存中写入到数据文件的脏数据）。这个比例值越大，从内存到磁盘的写入操作就会相对减少，所以能够一定程度下减少写入操作的磁盘IO。
但是，如果这个比例值过大，当数据库 Crash 之后重启的时间可能就会很长，因为会有大量的事务数据需要从日志文件恢复出来写入数据文件中。同时，过大的比例值同时可能也会造成在达到比例设定上限后的 flush 操作“过猛”而导致性能波动很大。
上面这几个参数是 MySQL 中为了减少磁盘物理IO而设计的主要参数，对 MySQL 的性能起到了至关重要的作用。
—EOF—
- query_cache_type : 如果全部使用innodb存储引擎，建议为0，如果使用MyISAM 存储引擎，建议为2，同时在SQL语句中显式控制是否是哟你gquery cache
- query_cache_size: 根据 命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）进行调整，一般不建议太大，256MB可能已经差不多了，大型的配置型静态数据可适当调大
- binlog_cache_size: 一般环境2MB～4MB是一个合适的选择，事务较大且写入频繁的数据库环境可以适当调大，但不建议超过32MB
- key_buffer_size: 如果不使用MyISAM存储引擎，16MB足以，用来缓存一些系统表信息等。如果使用 MyISAM存储引擎，在内存允许的情况下，尽可能将所有索引放入内存，简单来说就是“越大越好”
- bulk_insert_buffer_size: 如果经常性的需要使用批量插入的特殊语句（上面有说明）来插入数据，可以适当调大该参数至16MB～32MB，不建议继续增大，某人8MB
- innodb_buffer_pool_size: 如果不使用InnoDB存储引擎，可以不用调整这个参数，如果需要使用，在内存允许的情况下，尽可能将所有的InnoDB数据文件存放如内存中，同样将但来说也是“越大越好”
- innodb_additional_mem_pool_size: 一般的数据库建议调整到8MB～16MB，如果表特别多，可以调整到32MB，可以根据error log中的信息判断是否需要增大
- innodb_log_buffer_size: 默认是1MB，系的如频繁的系统可适当增大至4MB～8MB。当然如上面介绍所说，这个参数实际上还和另外的flush参数相关。一般来说不建议超过32MB
- innodb_max_dirty_pages_pct: 根据以往的经验，重启恢复的数据如果要超过1GB的话，启动速度会比较慢，几乎难以接受，所以建议不大于 1GB/innodb_buffer_pool_size(GB)*100 这个值。当然，如果你能够忍受启动时间比较长，而且希望尽量减少内存至磁盘的flush，可以将这个值调整到90，但不建议超过90
注：以上取值范围仅仅只是我的根据以往遇到的数据库场景所得到的一些优化经验值，并不一定适用于所有场景，所以在实际优化过程中还需要大家自己不断的调整分析，也欢迎大家随时通过 Mail 与我联系沟通交流优化或者是架构方面的技术，一起探讨相互学习。
MySQL, MySQL数据库性能优化专题, performance tuning
自上次 对 myperf 作了一个基本的介绍 之后，反响不错，就准备再针对 myperf 的 3 个模式分别说明一下。
之前已经说明，myperf 有三个mode（功能模式），分别为： top, snap, report。第一个mode比较独立，后2个mode相辅相成。今天这里就先介绍一下 myperf 的第一个mode：“top” 。
简单来说，“top” mode其实就是一个类似于我们 Linux/Unix 下最常使用的基本的性能查看程序 top 一样，实时刷新展示数据库当前的一些比较重要的性能指标。
myperf 默认就是 “top” mode，我们可以通过执行 “myperf -h” 来看看程序的帮助内容：
myperf 几乎每一项参数都可以记录在配置文件中，唯一的例外就是当使用配置文件的时候，我们还需要一个参数告知配置文件的位置。
“top” mode 执行过程必须要能够连接到数据库，才能获取到数据库中的一些实时性能数据。可以通过命令行参数或者是配置文件的方式指定数据库连接参数：
- 命令行参数方式：
myperf -u username -p password -H host -i interval -m mode
如果连接端口不是3306，还需要通过 -P 参数指定数据库监听端口
注：默认情况下是不会显示当前正在执行的SQL内容的，可以通过 -s 参数开启该功能。如果是MySQL5.5 还可以通过 -e 参数选项开启event的一些信息
- 配置文件方式：
myperf -c configfile
如果选择使用配置文件的方式，则可以通过 -c 参数指定配置文件位置，并将其他参数都记录在配置文件中的方式来执行。
注：配置文件中的参数项名称都使用长名称
BTW：经历了2个星期才完成这么一个简单的说明，是自己真没有时间还是只是自己最近的惰性问题？
图3 推荐引擎整体架构
