五一归来两周，精力都放在了因为服务器压力突增而来的各种鸡飞狗跳的事情上，今天总结一下，算是对过去两周的总结，希望对各创业团队有所借鉴。
1.访问突增，连锁反应
最先开始出现问题的，是在小负载下没有出现的问题，在大压力时，只要DB一堵，表像就会是循环锁死。
解决之道：
服务要有清晰的架构，开发规范里一定要有明确的架构层次规范，最好还有代码的层次规范。

2.mysql设计不合理，压力指数增加
mysql中存在大量的更新操作，特别是大字段或者变长字段的频繁更新，导致磁盘io居高不下，慢查询越来越多。
硬解决之道：
raid卡加电，开启raid写缓存：一般服务器的raid卡都没有开启，开启是有一定用处的，但有一个前提，不是待续的高写入，否则这个写缓存是没有意义的。电池充电时无法缓存，一般三个月充一次电。
转微博：FusionioChina 回复 @YauzZ:多一个故障点。多一份丢数据的可能。而且目前有Raid卡的内存做到1GB。丢不起呀。(5月11日 23:29)
从raid分到多个盘、盘柜，都是从硬件上用多硬盘分担的好方案。

软解决之道：
写方案建立mysql隔离层，在写入前预先处理，类似软件缓存方案，效果明显，修改复杂。

3.后续可做
灵活的中间层数据层切换逻辑，让负载可以随时转移、分隔，基本可以达到“人傻钱多，万事不愁”。

1.下载 http://archive.cloudera.com/cdh/3/sqoop-1.2.0-CDH3B4.tar.gz

2.下载 http://archive.cloudera.com/cdh/3/hadoop-0.20.2-CDH3B4.tar.gz

3.解压 2

4.复制3里hadoop-core-0.20.2-CDH3B4.jar到sqoop的lib下

5.在某处复制mysql-connector-java-5.1.10.jar到sqoop的lib下

6.修改configure-sqoop

注释掉hbase zookeeper检查：
#if [ ! -d "${HBASE_HOME}" ]; then
# echo "Error: $HBASE_HOME does not exist!"
# echo 'Please set $HBASE_HOME to the root of your HBase installation.'
# exit 1
#fi
#if [ ! -d "${ZOOKEEPER_HOME}" ]; then
# echo "Error: $ZOOKEEPER_HOME does not exist!"
# echo 'Please set $ZOOKEEPER_HOME to the root of your ZooKeeper installation.'
# exit 1
#fi

7.运行：
列出mysql所有的表：

./sqoop list-tables --connect jdbc:mysql://127.0.0.1/operation --username root --password 123

导入mysql表到hive：

./sqoop import --connect jdbc:mysql://192.168.100.52/operation --username root --password 3487e498770b9740086144fc03140876 --table active_uuid --hive-import

导入需要表里有主建，还要注意不要使用127.0.0.1，因为map出去不一定在哪个节点执行。

如果曾经执行失败过，那再执行的时候，会有错误提示：

ERROR tool.ImportTool: Encountered IOException running import job: org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory xxx already exists

执行 $HADOOP_HOME/bin/hadoop fs -rmr xxx 即可

8.验证:

bin/hive
show tables;多了一个表

9.经验：
sqoop做了一些mysqldump时的map reduce，所以速度会比单纯的dump后load快。

==========尽职的安静的分隔线===========
在实际工作中遇到下面一个问题：
有一个表，存有2000万数据。
主键为ID bigint(20) NOT NULL auto_increment
另有一字段time timestamp NOT NULL default CURRENT_TIMESTAMP

故事从这两个字段说起：
sql1需要从这个表中检索出来时间为2010-05-26 11:55:00之前并且id号大于20000的前10条数据
sql2需要从这个表中检索出来时间为2010-05-26 11:55:00之后并且id号大于20000的前10条数据

两条sql写出来大概是这样子的：
sql1:select * from table where time <'2010-05-26 11:55:00' and id>20000 order by id limit 10;
sql2:select * from table where time >'2010-05-26 11:55:00' and id>20000 order by id limit 10;

并且已经知道表中的数据，在上面所示时间之前的数据要远远多于所示时间之后的数据。如图1所示：

图1 数据在时间线上的示意图

实测发现，sql1执行时间0.03s，sql2执行时间33s。

为何大于小于运行的速度相比如何巨大？下面来解答。

第一，用explain来观察两条sql的区别
结论：没什么区别

第二，研究order by
将sql2的order by id修改为order by id desc(排序方向颠倒)后，发现速度马上提到了0.03s的水平。
同样修改sql1的时候，速度马上降到了30s的水平。

进行多次测试，排除mysql本身的缓存干扰。

结论：
sql1的运行示意图如图2所示：

图2 第一条SQL语句快慢解释图

sql2的运行示意图如图3所示：

图2 第二条SQL语句快慢解释图

综合上面两个图，mySQL在where查询的时候，也许按照where的条件，按照主键的顺序，最后满足条件的，最后进到内存中去，再进行后面的order by时，asc如果在内存中比不在内存中的就要快得多。

未研究真正实现的代码，仅凭感觉验证。
一句话概括是：按照使用的索引，最后满足条件的数据将留在内存里供进一步排序。

doubanclaimed89ad216b01beaf
题注：感谢suchasplus兄弟在第一时间提示explain拼写错误~~~:)

对于经常使用mysql的兄弟们，对explain一定不会陌生。当你在一条SELECT语句前放上关键词EXPLAIN，MySQL解释它将如何处理SELECT，提供有关表如何联合和以什么次序的信息。
借助于EXPLAIN，你可以知道
1)你什么时候必须为表加入索引以得到一个使用索引找到记录的更快的SELECT。
2)你也能知道优化器是否以一个最佳次序联结表。为了强制优化器对一个SELECT语句使用一个特定联结次序，增加一个STRAIGHT_JOIN子句。
官方的关于explain的文档在http://dev.mysql.com/doc/refman/5.1/en/using-explain.html（英文），本文可作为官方文献的不完整通俗读物。

使用的方法

EXPLAIN tbl_name
或：
EXPLAIN [EXTENDED] SELECT select_options

前者可以得出一个表的字段结构等等，后者主要是给出相关的一些索引信息，而今天要讲述的重点是后者。

举例

mysql> explain select * from event;
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
| 1 | SIMPLE | event | ALL | NULL | NULL | NULL | NULL | 13 | |
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
1 row in set (0.00 sec)

各个属性的含义

id
select查询的序列号

select_type
select查询的类型，主要是区别普通查询和联合查询、子查询之类的复杂查询。

table
输出的行所引用的表。

type
联合查询所使用的类型。
type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
一般来说，得保证查询至少达到range级别，最好能达到ref。

possible_keys
指出MySQL能使用哪个索引在该表中找到行。如果是空的，没有相关的索引。这时要提高性能，可通过检验WHERE子句，看是否引用某些字段，或者检查字段不是适合索引。

key
显示MySQL实际决定使用的键。如果没有索引被选择，键是NULL。

key_len
显示MySQL决定使用的键长度。如果键是NULL，长度就是NULL。文档提示特别注意这个值可以得出一个多重主键里mysql实际使用了哪一部分。

ref
显示哪个字段或常数与key一起被使用。

rows
这个数表示mysql要遍历多少数据才能找到，在innodb上是不准确的。

Extra
如果是Only index，这意味着信息只用索引树中的信息检索出的，这比扫描整个表要快。
如果是where used，就是使用上了where限制。
如果是impossible where 表示用不着where，一般就是没查出来啥。
如果此信息显示Using filesort或者Using temporary的话会很吃力，WHERE和ORDER BY的索引经常无法兼顾，如果按照WHERE来确定索引，那么在ORDER BY时，就必然会引起Using filesort，这就要看是先过滤再排序划算，还是先排序再过滤划算。

常见的一些名词解释

Using filesort
MySQL需要额外的一次传递，以找出如何按排序顺序检索行。

Using index
从只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的列信息。

Using temporary
为了解决查询，MySQL需要创建一个临时表来容纳结果。

ref
对于每个来自于前面的表的行组合，所有有匹配索引值的行将从这张表中读取

ALL
完全没有索引的情况，性能非常地差劲。

index
与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小。

SIMPLE
简单SELECT(不使用UNION或子查询)

关于哥学社

哥学社是一个自由博客组织，以提高原创技术博客质量，为成员博客增加更有效评论，由来自腾讯、百度、盛大、人人网、新浪、奇虎、TOM等各大企业的哥们共同起草发起。

关于五四陈

54chen(陈臻)，人人网分布式存储研究人员，业余时间混迹于各技术组织且乐此不疲。目前关注实施PHP培训。对flex等前端技术有一点研究。
个人技术站点:http://www.54chen.com/ 。可以通过电子邮件 czhttp@gmail.com 联系到他。

本文提及的文章

http://dev.mysql.com/doc/refman/5.1/en/using-explain.html

http://dev.mysql.com/doc/refman/5.1/zh/optimization.html#explain

在开发人人网海量存储系统Nuclear的过程中，使用到mysql引擎，用了spring+dbcp+jdbc，在压力测试的过程中出现了问题。

在追踪java stack的过程中发现如下的问题：

java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:113)
at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:160)
at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:188)
- locked <0x00002aaab9b2b0d8> (a com.mysql.jdbc.util.ReadAheadInputStream)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2494)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3005)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2938)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3481)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:919)
at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1416)
at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:2883)
at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:476)
at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2576)
at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1757)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2167)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648)
- locked <0x00002aaab9d98790> (a java.lang.Object)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228)
- locked <0x00002aaab9d98790> (a java.lang.Object)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:648)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:591)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:641)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:670)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:702)
at com.renren.nuclear.storage.MySqlDumpEngine.getListByLeftRight(MySqlDumpEngine.java:198)

其中锁住了tcp的socket，在研究无果的情况下，试着搜了一下，发现已经有人在mysql bugs里提到：

http://bugs.mysql.com/bug.php?id=9515

分析产生bug的原因：

mysql建表的时候使用innoDB，表中有过千万的数据，每次取过多的数据，就会重现。

可能的原因：jdbc在做网络层的时候tcp的buffer不够所致io锁。

最简单的解决办法：

把原来的limit 1000改小，变成了limit 100。

[ 文章作者：陈臻 本文版本：v1.0 最后修改：2009.8.2 转载请注明原文链接：http://www.54chen.com/688-wordpress-nginx-php-cgi-mysql-memory-in-the-128m-to-install-and-optimize-the-vps-notes/ ]

选取CentOS，因为它是号称最安全及性能都相对较好的Linux系统。系统内存128m，系统用掉30m，有100m左右可用（如图1所示），swap已经有256M，硬盘为5G，除去系统后大约有4G可供捣腾。

图1。

首先，在空白的系统上使用下面的命令，安装gcc等一堆工具和后面php会用到的一些包：

yum -y install gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers

yum这一堆东西会有点慢，这里正好插播一下，mysql的编译在128的内存下非常慢，所以呆会儿我们会采取直接yum，php、nginx都下源码编译，经过以往的经验eAccelerator、Xcache和Zend Optimizer这三者，最好是用eAccelerator搭配Zend Optimizer能给php加速得到最佳效果，当然了，Zend Optimizer需要Zend Guard来搭配，而后者是收费的，伟大的中国人有伟大的破解。

我执行的时候耗时32分钟左右。

言归正传，继续：
wget http://sysoev.ru/nginx/nginx-0.7.61.tar.gz
wget http://www.php.net/get/php-5.2.10.tar.gz/from/this/mirror
wget http://blog.s135.com/soft/linux/nginx_php/phpfpm/php-5.2.10-fpm-0.5.11.diff.gz
wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.9.tar.gz [nginx rewrite使用]

【安装MySQL】
yum install -y mysql-server
启动MySQL:
service mysqld start
设置mysql数据库root帐号密码:
mysqladmin -u root password 'newpassword' [引号内填密码]
让mysql更安全：
mysql -u root -p [此时会要求你输入刚刚设置的密码，输入后回车即可]

mysql> DROP DATABASE test; [删除test数据库]
mysql> DELETE FROM mysql.user WHERE user = ''; [删除匿名帐户]
mysql>DELETE FROM mysql.user WHERE password = '';[删除无密码帐户]
mysql> FLUSH PRIVILEGES; [重载权限]

【优化MySQL】
此时的mysql直接吃掉20m左右的内存，如图2所示。我们要对其进行优化，关掉innodb。

图2。

vi /etc/my.cnf
在后面增加如下内容：

skip-innodb
[mysql]
no-auto-rehash

[mysqld]
user = mysql
port = 3306
open_files_limit = 600
back_log = 20
max_connections = 100
max_connect_errors = 200
table_cache = 60
external-locking = FALSE
max_allowed_packet = 16M
sort_buffer_size = 128K
join_buffer_size = 128K
thread_cache_size = 10
thread_concurrency = 8
query_cache_size = 0M
query_cache_limit = 2M
query_cache_min_res_unit = 2k
default_table_type = MyISAM
thread_stack = 192K
transaction_isolation = READ-UNCOMMITTED
tmp_table_size = 512K
max_heap_table_size = 32M
long_query_time = 1
log_long_format
server-id = 1
binlog_cache_size = 2M
max_binlog_cache_size = 4M
max_binlog_size = 512M
expire_logs_days = 7
key_buffer_size = 4M
read_buffer_size = 1M
read_rnd_buffer_size = 2M
bulk_insert_buffer_size = 2M
myisam_sort_buffer_size = 4M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover

[mysqldump]
quick
max_allowed_packet = 16M

【重启MySQL】
service mysqld restart
再看mysql吃掉的内存，已经降低了四分之一，如图3所示：
图3。

【安装php】
首先使用yum安装上mysql的开发包，供php扩展mysql使用：
yum -y install mysql-devel
安装patch工具：
yum -y install patch
tar zxvf php-5.2.10.tar.gz
gzip -cd php-5.2.10-fpm-0.5.11.diff.gz | patch -d php-5.2.10 -p1
cd php-5.2.10
./configure --prefix=/opt/php --with-config-file-path=/opt/php/etc --with-mysql=/usr/share/mysql --with-mysqli=/usr/bin/mysql_config --with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir --with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml --disable-rpath --enable-discard-path --enable-safe-mode --enable-bcmath --enable-shmop --enable-sysvsem --enable-inline-optimization --with-curl --with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm --enable-force-cgi-redirect --enable-mbstring --with-gd --enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets --with-ldap --with-ldap-sasl --without-pear
make && make install
把pear手动装上(这个是5.2.10的一个bug，后面可能已经打补丁了)：
curl http://pear.php.net/go-pear | /opt/php/bin/php
cp php.ini-dist /opt/php/etc/php.ini

【安装eaccelerator】
tar jxvf eaccelerator-0.9.5.3.tar.bz2
cd eaccelerator-0.9.5.3
/opt/php/bin/phpize
./configure --enable-eaccelerator=shared --with-php-config=/opt/php/bin/php-config
make && make install
mkdir -p /opt/eaccelerator_cache
vi /opt/php/etc/php.ini

添加下面的内容：
[eaccelerator]
zend_extension="/usr/local/webserver/php/lib/php/extensions/no-debug-non-zts-20060613/eaccelerator.so"
eaccelerator.shm_size="64"
eaccelerator.cache_dir="/usr/local/webserver/eaccelerator_cache"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="3600"
eaccelerator.shm_prune_period="3600"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

【安装Zend Optimizer】
要去zend.com上注册用户名后进download页面下载，这里太弱智了，不知道zend是否有专门的产品人员，这种注册下载有什么意义，只是一堆死账号而已。
下载ZendOptimizer-3.3.3-linux-glibc23-i386.tar.gz
tar -zxvf ZendOptimizer-3.3.3-linux-glibc23-i386.tar.gz
cd ZendOptimizer-3.3.3-linux-glibc23-i386
./install

运行过程中会要求你写些安装路径啥的，照着写就是。
如果出现类似下面的错误：
./install-tty: line 139: ./php: cannot execute binary file
那说明你下错了包了，这种情况是因为你32位的系统下了64位的包或者是反过来。

【安装nginx】
tar -zxvf pcre-7.9.tar.gz
cd pcre-7.9
./configure
make && make install
cd ..

tar zxvf nginx-0.7.61.tar.gz
cd nginx-0.7.61
./configure --user=www --group=www --prefix=/opt/nginx --with-http_stub_status_module --with-http_ssl_module
make && make install

增加www用户：
groupadd www
useradd -g www www

【优化php\nginx】
1.优化php-fpm.conf
vi /opt/php/etc/php-fpm.conf
修改log level为error:
error
修改max_children:
5
修改listen_address为unix socket方式运行：
/tmp/php-cgi.sock

2.优化nginx.conf
vi /opt/nginx/conf/nginx.conf
在events中增加：
use epoll;
在http中增加下面的代码，打开gzip：
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
在使用php的server中使用unix socket通信方式：
fastcgi_pass unix:/tmp/php-cgi.sock;

【设置开机启动】
/sbin/chkconfig --add mysqld [在服务清单中添加mysql服务]
/sbin/chkconfig mysqld on [设置mysql服务开机启动]

vi /etc/rc.locale
加入两行：
/opt/php/sbin/php-fpm start
/opt/nginx/sbin/nginx

【误区提示】
XEN更像物理服务器，会尽量把剩余的内存当成buffer和cache，所以看到下图的时候不要惊慌，其实内存都在cache里了。
图4

【wordpress专项优化】
使用wp-super-cache插件，将页面生成html，省去php的开销，性能有提升。
对照access log，刷新页面，看堵在什么地方

【几个建议】
合并css js个数 并且压缩 速度提升明显
wordpress没有任何插件的时候，效率是很不错的，但是有些不负责任的插件会导致整体看起来很慢，下面是一些常用的插件的问题：
1.twitter tools插件：用来从后端取twitter数据的，这个插件搞了一个js一个css在head里，并且都是通过php生成的，两个php请求，让首页很慢。建议去掉（可能会影响自动化？没来得及分析细节）。
2.wp-spamfree插件：用来做antispam的，这是一个动态生成的js，不知道为什么非常慢。建议换别的插件。

【结果展示】
在完成上述一系列的操作后，http://54chen.com 我是陈科学院的打开速度已经非常迅速了，基本上一秒钟就能全部显示。内存还有40m空闲，如图5所示：
图5

[ 文章作者：陈臻 本文版本：v1.0 最后修改：2009.4.27 转载请注明原文链接：http://www.54chen.com/c/560 ]

环境：
Windows XP
PHP Version 5.2.9
MySQL Server 5.1

第一步、创建一个表date_test（非定长、int时间）

CREATE TABLE `test`.`date_test` (
`id` INT NOT NULL AUTO_INCREMENT ,
`start_time` INT NOT NULL ,
`some_content` VARCHAR( 255 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = InnoDB;

第二步、创建第二个表date_test2（定长、int时间）

CREATE TABLE `test`.`date_test2` (
`id` INT NOT NULL AUTO_INCREMENT ,
`start_time` INT NOT NULL ,
`some_content` CHAR( 255 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = InnoDB;

第三步、创建第三个表date_test3（varchar、datetime时间）

CREATE TABLE `test`.`date_test3` (
`id` INT NOT NULL AUTO_INCREMENT ,
`start_time` DATETIME NOT NULL ,
`some_content` VARCHAR( 255 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = InnoDB;

第四步、创建第四个表date_test3（char、datetime时间）

CREATE TABLE `test`.`date_test4` (
`id` INT NOT NULL AUTO_INCREMENT ,
`start_time` DATETIME NOT NULL ,
`some_content` CHAR( 255 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = InnoDB;

ok，现在我们开始做测试，环境是php，先向各个表插入一百万条数据。插入的时候分200次，每次进库5000条。

表一执行记录：页面运行时间: 26.5997889042 秒，插入的时候发现一个有趣的现象：SELECT count( id ) FROM `date_test` WHERE 1 的结果是100w,而直接select * from `date_test`却是1,000,374条结果。（后来看到这是一个可能接近的值，请参看MySQL FAQ 3.11）。
表二执行记录：页面运行时间: 62.3908278942 秒，这次记录是1,000,066条。
表三执行记录：页面运行时间: 30.2576560974 秒，这次的是1,000,224条。
表四执行记录：页面运行时间: 67.5393900871 秒，这次的是：1,000,073条。

现在把四个表的start_time字段一一加上索引。

测试四个表的更新，分别update 100条记录，并记录时间:
表一：页面运行时间: 2.62180089951 秒（非定长，int时间）
表二：页面运行时间: 2.5475358963 秒（定长，int时间）
表三：页面运行时间: 2.45077300072 秒（varchar,datetime时间）
表四：页面运行时间: 2.82798409462 秒（char,datetime时间）

测试四个表的读取，分别select 100条随机记录，以主键id为条件查询，并记录时间：
表一：页面运行时间: 0.382651090622 秒（非定长，int时间）
表二：页面运行时间: 0.542181015015 秒（定长，int时间）
表三：页面运行时间: 0.334048032761 秒（varchar,datetime时间）
表四：页面运行时间: 0.506206989288 秒（char,datetime时间）

测试四个表的读取，分别select 10条随机记录，以star_time为条件查询，并记录时间：
表一：页面运行时间: 30.1972880363 秒（非定长，int时间）
表二：页面运行时间: 65.1926910877 秒（定长，int时间）
表三：页面运行时间: 39.7210869789 秒（varchar,datetime时间）
表四：页面运行时间: 70.4632740021 秒（char,datetime时间）

因为量比较小，所以我们默认即使是微小的变化，也是有意义的。

结论：

大数据量下，如果存在大量的select * from table where 时间>XX这样的查询，在MySQL5.1时使用int换datetime是有意义的。

 5.1.24版本的配置请看：http://www.masalife.com/archives/173

一、先修改服务器的配置文件

       1、Master服务器配置简单，修改my.cnf为:

       server-id       = 1

log-bin

set-variable=binlog-ignore-db=mysql

2、slave1的配置加入

server-id       = 2

master-host = 172.16.20.135

master-user = rep

master-password = cnrep

master-port = 3306

log-bin

set-variable=replicate-ignore-db=mysql

set-variable=replicate-do-db=AliSMS

set-variable=replicate-do-db=lcd

set-variable=replicate-do-db=loginmanager

set-variable=replicate-do-db=samis

set-variable=replicate-do-db=sareport

set-variable=replicate-do-db=syslog

set-variable=replicate-do-db=web_speed

log-slave-updates

3、slave2服务器的配置

server-id       = 3

master-host = 172.16.20.3

master-user = rep1

master-password = cnrep

master-port = 3306

set-variable=replicate-ignore-db=mysql

set-variable=replicate-do-db=AliSMS

set-variable=replicate-do-db=lcd

set-variable=replicate-do-db=loginmanager

set-variable=replicate-do-db=samis

set-variable=replicate-do-db=sareport

set-variable=replicate-do-db=syslog

set-variable=replicate-do-db=web_speed

二、重启master数据库

三、然后锁定master数据库的表：

mysql>FLUSH TABLES WITH READ LOCK;

四、在master数据库中添加用于slave1同步的用户，并赋予相关权限：

mysql>GRANT REPLICATION SLAVE ON *.* TO rep@sa_cfengine1 IDENTIFIED BY 'cnrep';

mysql>GRANT FILE,SELECT,REPLICATION SLAVE ON *.* TO rep@sa_cfengine1 IDENTIFIED BY 'cnrep';

五、在slave1数据库中添加用于slave2同步的用户，并赋予相关权限：

mysql>GRANT REPLICATION SLAVE ON *.* TO rep1@sa_cfengine2 IDENTIFIED BY 'cnrep';

mysql>GRANT FILE,SELECT,REPLICATION SLAVE ON *.* TO rep1@sa_cfengine2 IDENTIFIED BY 'cnrep';

六、同步数据库：

方法很多，可以打包之后scp，再解压，由于sa_cfengine1到mysql master服务器通道打通了，切sa_cfengine2到sa_cfengine1通道也打了，故直接scp整个数据库目录即可。

注意：此时要注意删除同步过来的日志文件，最好把与数据库无关的文件全删除（可以将非目录的文件全删了）。

七、重启salve1的mysql，起来之后锁定表

八、重启slave2的mysql，然后先后给slave1和master服务器的mysql表解锁

mysql> UNLOCK TABLES；

九、分别登录slave1和slave2的mysql，查看同步状态：

        mysql>SHOW SLAVE STATUS\G

*************************** 1. row ***************************

             Slave_IO_State: Waiting for master to send event

                Master_Host: 172.16.20.135

                Master_User: rep

                Master_Port: 3306

              Connect_Retry: 60

            Master_Log_File: mysql-bin.000051

        Read_Master_Log_Pos: 13856842

             Relay_Log_File: sa_cfengine1-relay-bin.000013

              Relay_Log_Pos: 624419

      Relay_Master_Log_File: mysql-bin.000051

           Slave_IO_Running: Yes

          Slave_SQL_Running: Yes

            Replicate_Do_DB: AliSMS,lcd,loginmanager,samis,sareport,syslog,web_speed

        Replicate_Ignore_DB: mysql,mysql

         Replicate_Do_Table:

     Replicate_Ignore_Table:

    Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

                 Last_Errno: 0

                 Last_Error:

               Skip_Counter: 0

        Exec_Master_Log_Pos: 13856842

            Relay_Log_Space: 624419

            Until_Condition: None

             Until_Log_File:

              Until_Log_Pos: 0

         Master_SSL_Allowed: No

         Master_SSL_CA_File:

         Master_SSL_CA_Path:

            Master_SSL_Cert:

          Master_SSL_Cipher:

             Master_SSL_Key:

      Seconds_Behind_Master: 0

1 row in set (0.01 sec)

注意标注为红色的地方，两个都是yes说明一切正常，否则要检查原因，可以看error log查找原因后做相应的处理。

十、测试：

       在master数据库中update在同步列表中的一个表的一个字段，如果slave服务器的做相应改变，则测试用过。

TINYINT
-128 - 127

TINYINT UNSIGNED
0 - 255

SMALLINT
-32768 - 32767

SMALLINT UNSIGNED
0 - 65535

MEDIUMINT
-8388608 - 8388607

MEDIUMINT UNSIGNED
0 - 16777215

INT 或 INTEGER
-2147483648 - 2147483647

INT UNSIGNED 或 INTEGER UNSIGNED
0 - 4294967295

BIGINT
-9223372036854775808 - 9223372036854775807

BIGINT UNSIGNED
0 - 18446744073709551615

FLOAT
-3.402823466E+38 - -1.175494351E-38
0
1.175494351E-38 - 3.402823466E+38

DOUBLE 或 DOUBLE PRECISION 或 REAL
-1.7976931348623157E+308 - -2.2250738585072014E-308
0
2.2250738585072014E-308 - 1.7976931348623157E+308

DECIMAL[(M,[D])] 或 NUMERIC(M,D)
由M(整个数字的长度,包括小数点,小数点左边的位数,小数点右边的位数,但不包括负号)和D(小数点右边的位数)来决定,M缺省为10,D缺省为0

DATE
1000-01-01 - 9999-12-31

DATETIME
1000-01-01 00:00:00 - 9999-12-31 23:59:59

TIMESTAMP
1970-01-01 00:00:00 - 2037年的某天(具体是哪天我也不知道,呵呵)

TIME
-838:59:59' to 838:59:59

YEAR[(2|4)]
缺省为4位格式,4位格式取值范围为1901 - 2155,0000,2位格式取值范围为70-69(1970-2069)

CHAR(M) [BINARY] 或 NCHAR(M) [BINARY]
M的范围为1 - 255,如果没有BINARY项,则不分大小写,NCHAR表示使用缺省的字符集.在数据库中以空格补足,但在取出来时末尾的空格将自动去掉.

[NATIONAL] VARCHAR(M) [BINARY]
M的范围为1 - 255.在数据库中末尾的空格将自动去掉.

TINYBLOB 或 TINYTEXT
255(2^8-1)个字符

BLOB 或 TEXT
65535(2^16-1)个字符

MEDIUMBLOB 或 MEDIUMTEXT
16777215 (2^24-1)个字符

LONGBLOB 或 LONGTEXT
4294967295 (2^32-1)个字符

ENUM('value1','value2',...)
可以总共有65535个不同的值

SET('value1','value2',...)
最多有64个成员