“如果一个设计只是简单地反映了问题描述，你去实现它就会落入磁盘 I/O的地狱。不管你用Ruby on Rails、Cobol on Cogs、C++还是手写汇编都一样，读写负载照样会害死你。””

Write Through和Write Back Write Through和Write Back是阵列卡Cache的两种使用方式，也称为透写和回写。当选用write through方式时，系统的写磁盘操作并不利用阵列卡的Cache，而是直接与磁盘进行数据的交互。而write Back方式则利用阵列Cache作为系统与磁盘间的二传手，系统先将数据交给Cache，然后再由Cache将数据传给磁盘。

一、先说明下概念:Mysql 分表:字面意思是将一张表划分为N个小表；每个小表包含（.MYD数据文件，.MYI索引文件，.frm表结构文件，是一个真正的表）。Mysql分区:将一个表的数据划分为N个区,逻辑上还是一张表，不过存储数据的文件会变多。二、区别:数据处理上:1 分表利用了Merge引擎，对表关系进行管理。存取数据发生在各个子表里。

用了很长时间的mysql,对于它的内部结构很少研究。 新的一年里，需要沉下心里，仔细研究

1. 千万不要 ORDER BY RAND()想打乱返回的数据行？随机挑一个数据？真不知道谁发明了这种用法，但很多新手很喜欢这样用。但你确不了解这样做有多么可怕的性能问题。如果你真的想把返回的数据行打乱了，你有N种方法可以达到这个目的。这样使用只让你的数据库的性能呈指数级的下降。这里的问题是：MySQL会不得不去执行RAND()函数（很耗CPU时间），而且这是为了每一行记录去记行，

1 尽可能地合并给定表DML 语句会获得更高的效率mysql> ALTER TABLE album DROP index country_id, dropindex album_type_id;Query OK, 553875 rows affected (15.72 sec)mysql> ALTER TABLE album ADD INDEX (country_id);Que

摘要：社交巨头Facebook的“冷存储”战略又向前迈进了一大步，前进的指导方针仍然为闪存。“挨刀”的则是Facebook“老臣”Memcached，不过这次不再是以往几倍几倍的提升速率，而是直接将其炼化为闪存版。好吧，下面来初窥一下Facebook的新键值缓存系统McDipper。上回说到社交巨头Facebook苦衷，因其不能像一般企业或机构将“冷数据刻录成光盘”，不得不向一些硬件供

最近碰到一个bug:   中文字符时而显示正常，时而显示乱码。追查良久，发现原因出在Mysql断线重连上。修改如下：在mysql_init(NULL)调用之后，mysql_real_connect之前，调用mysql_options(conn,MYSQL_SET_CHARSET_NAME,"Latin1")这样，在断线重连后，字符集不会发生变化。

Recently, I am learning use MongoDB and analysis source code.  I will write some articles to keep track of my processes. About MongoDB:MongoDB  is a scalable,high-performance, open source NoSQL

摘要：本文讲述了Anders Karlsson在发现MySQL与MongoDB对比中处于劣势后挖空心思的对MySQL进行提升。各种存储引擎、各种内存管理引擎及嵌入式思想，在各种尝试后MySQL也是终于取得了胜利。然而这种胜利真的能称为胜利吗？或者这种胜利真的是大家想要的吗？初步的键值比较，MongoDB完胜快还要更快，这一直都是我们给予数据库系统的目标MySQL Dragste

show global status where Variable_name in('com_select','com_insert','com_delete','com_update'); 等待10秒 磁盘IOPS计算与测量 IOPS 是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。随机读写频繁的应用，如OLTP