数据库分区分表以及读写分离

(一)

数据库结构的优化有多种方法，主要的有两种：

一是利用存储过程来代替常用的SQL查询语句，减少sql语句解析编译的过程。

     另一种是使用数据库管理系统中的分区表方法进。使用存储过程的优化方法有执行速度快的优点，但是其本身不利于调试、没有办法使用数据库缓存机制等缺点，所以在系统安全性和性能要求更高的情况下，建议使用分区表的方法。但要注意：并不是只要数据量够多就需要通过数据库分区表来提高查询效率，而是要在数据是分段的前提下，我们才需要考虑到是否需要使用分区表。

分区的好处：

1) 增强可用性：如果表的某个分区出现故障，表在其他分区的数据仍然可用；

2) 维护方便：如果表的某个分区出现故障，需要修复数据，只修复该分区即可；

3) 均衡I/O：可以把不同的分区映射到磁盘以平衡I/O，改善整个系统性能；

4) 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索速度。

数据库的表分区有两种方式，水平表分区和垂直表分区。

　水平分区：目的是将一个表分为多个表。每个表包含的列数(表字段)都是相同的，但是记录数(数据行)会减少。比如，我们可以将一个包含1亿行记录的数据库表，按照水平分区的方式，分成12个小表，每个小表分别表示这一年份内从1月到12月的数据。这样，任何需要查询特定月份数据的查询只需查询相应月份的表，而避免从存储在1个大表中的所有月份的数据进行查询。根据SQL语句的执行效率，毫无疑问，从小表中的查询效率会远远高于从大表中查询的效率。

    垂直分区：该方式则与水平分区方式相反，从纵向进行分区，是将一个原始表分成多个只包含较少列的表。在日常的应用中，水平分区可以说是最常用的分区方式。

1、Partition 技术介绍
    ORACLE的分区是一种处理超大型表、索引等的技术。通过将大表和索引按照分区规则分成可以管理的若干小块，从而避免了对每个表作为一个大的、单独的对象进行管理，为大量数据提供了可伸缩的性能。分区通过将操作分配给更小的存储单元，减少了需要进行管理操作的时间，并通过增强的并行处理提高了性能，通过屏蔽故障数据的分区，还增加了可用性。
2、数据库分区设计优化方案
2.1确定哪些大表需要进行分区：

    使用分区技术时，并不是对数据库中的所有表都进行分区，而只针对数据量比较大的一些大表才进行分区。根据分区的定义可知：分区其实就是将一个大数据段按规则划分成若干个小数据段，如果表对象本身很小，就失去了分区的意义。根据经验，数据量大于1000万的表才需要做分区。
SQL>select owner,table_name,num_rows
from dba_tables
where num_rows>10000000
and partitioned='NO';
说明：在使用以上语句统计需要做分区的大表时，必须先收集数据库系统的统计信息。否则num_rows的数据不准确，无法正确表达出表对象的记录数。
2.2讨论分区类型及分区字段的选择:
    这一步至关重要，分区类型和分区字段的选择严重影响到数据表的访问性能。选择了错误的分区类型或分区字段给数据库性能带来的负面影响会比不做分区更大，因此在决定分区类型和分区字段时一定要与项目组讨论，按照业务需求及业务逻辑共同制定。
根据经验，选择分区类型的步骤：
1)先确定该表中哪个字段在select语句的谓词中使用最频繁，此字段将做为分区字段。
    因为分区的目的是将一个大表的数据段按规则分离成若干个小数据段，索引也分离为若干小索引段，在数据访问时，根据索引只需要访问其中的一个小索引段，最后访问其中的一个数据段，从而减小了需要访问的数据量，达到优化的目的。如果select语句的谓词中不包括分区字段，则必须访问完整个索引段，最后访问所有的小数据段，才能定位出需要访问的数据。
2)根据分区字段的特点，确定分区类型。
    如果该字段有明确的顺序先后关系，则该表合适做范围分区。如:时间，如果该字段没有明确的范围顺序关系，则是具有唯一值或若干值，则该表合适做列表分区。如:部门、分公司，如果该字段既无明确的范围顺序关系，也无具体值，而是些流水号，则该表合适做散列分区。如:批处理号、流水号。
2.3数据表空间及索引表空间设计
    表对象和索引对象的第一个规则是把表和索引分离。把表和相应的索引建立在不同的表空间中，最好在不同的磁盘上。这样可以避免在数据管理和查询时出现的许多I/O冲突。

    在此优化方案中，我们将为每个分区创建一个对应的表空间，让表分区存放在不同的表空间中，达到不同分区间数据访问的分离。同时为每个索引分区也创建独立的索引分区表空间。

3、分区类型

一、范围分区详细说明

范围分区就是对数据表中的某个值的范围进行分区，根据某个值的范围，决定将该数据存储在哪个分区上。如根据序号分区，根据时间等来进行分区。根据序号，比如小于2000000的放在part01, 2000000~4000000的放在part02。。。

create table AAA
(
 id number primary key,
 indate date not null
)
partition by range(indate)
(
 partition part_01 values less than(to_date('2006-01-01','yyyy-mm-dd'))tablespace space01,
 partition part_02 values less than(to_date('2010-01-01','yyyy-mm-dd'))tablespace space02,
 partition part_03 values less than(maxvalue)tablespace space03
);

space01\ space02\ space03为建立的三个表空间，相当于把建立的一个大的表分在了3个不同的表空间的分区上了。

 

二、Hash分区（散列分区）详细说明

   散列分区为通过指定分区编号来均匀分布数据的一种分区类型，因为通过在I/O设备上进行散列分区，使得这些分区大小一致。也就是只命名分区名称，这样均匀进行数据分布。

 

三、复合分区详细说明

   有时候我们需要根据范围分区后，每个分区内的数据再散列地分布在几个表空间中，这样我们就要使用复合分区。复合分区是先使用范围分区，然后在每个分区内再使用散列分区的一种分区方法。

partition by range(indate)subpartition by hash(id) 
subpartitions 3 store in (space01, space02, space03) 
( 
partition part_01 values less than(to_date(’2006-01-01’,’yyyy-mm-dd’)), 
partition part_02 values less than(to_date(’2010-01-01’,’yyyy-mm-dd’)), 
partition part_03 values less than(maxvalue) 
 );

 

四、分区表操作

1、插入记录：insert into AAA values(1 ,sysdate);

2、查询分区表记录：select * from AAA partition(part_01);

3、更新分区表的记录：update AAA partition(part_01) t set indate=’’where id=1; 但是当更新的时候指定了分区，而根据查询的记录不在该分区中时，将不会更新数据

4、删除分区表记录：delete from AAA partition(part_02) t where id=4; 如果指定了分区，而条件中的数据又不在该分区中时，将不会删除任何数据。

5、增加一个分区：alter table AAA add partition part_04 values less than(to_date(’2012-01-01’,’yyyy-mm-dd’)) tablespace dinya_spa ce03; 增加一个分区的时候，增加的分区的条件必须大于现有分区的最大值，否则系统将提示ORA-14074 partition bound must collate higher than that of the last partition 错误。

6、合并一个分区：alter table AAA merge partitions part_01,part_02 into partition part_02; ,如果在合并的时候把合并后的分区定为part_01的时候，系统将提示ORA-14275 cannot reuse lower-bound partition as resulting partition 错误。

7、删除分区：alter table AAA drop partition part_01; 删除分区表的一个分区后，查询该表的数据时显示，该分区中的数据已全部丢失，所以执行删除分区动作时要慎重，确保先备份数据后再执行，或将分区合并。

 

五、建立索引

    分区表和一般表一样可以建立索引，分区表可以创建局部索引和全局索引。当分区中出现许多事务并且要保证所有分区中的数据记录的唯一性时采用全局索引。

1.       局部索引分区的建立：create index idx_t on AAA(id) 
 local 
( 
partition idx_1 tablespace space01, 
partition idx_2 tablespace space02, 
partition idx_3 tablespace space03 
);

2.       全局索引建立时global 子句允许指定索引的范围值，这个范围值为索引字段的范围值：create index idx_t on AAA(id)
global partition by range(id) 
( 
partition idx_1 values less than (1000) tablespace space01, 
partition idx_2 values less than (10000) tablespace space02, 
partition idx_3 values less than (maxvalue) tablespace space03 
);

当然也可以不指定索引分区名直接对整个表建立索引:

create index idx_t on AAA(id);

数据库的垂直切分和水平切分

数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。

数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。 举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。

综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率

数据库的读写分离

 读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

       为什么要分库、分表、读写分？

       单表的数据量限制，当单表数据量到一定条数之后数据库性能会显著下降。数据多了之后，对数据库的读、写就会很多。分库减少单台数据库的压力。接触过几个分库分表的系统，都是通过主键进行散列分裤分表的。这类数据比较特殊，主键就是唯一的获取该条信息的主要途径。比如：京东的订单、财付通的交易记录等。。。该类数据的用法，就是通过订单号、交易号来查询该笔订单、交易。

        还有一类数据，比如用户信息，每个用户都有系统内部的一个userid，与userid对应的还有用户看到的登录名。那么如果分库分表的时候单纯通过userid进行散列分库，那么根据登录名来获取用户的信息，就无法知道该用户处于哪个数据库中。

       或许有朋友会说，我们可以维护一个email----userid的映射关系，根据email先查询到userid，在根据userid的分库分表规则到对应库的对应表来获取用户的记录信息。这么做是可以的，但是这个映射关系的条数本身也是个瓶颈，原则上是没有减少单表内数据的条数，算是一个单点。并且要维护这个映射关系和用户信息的一致性（修改登录名、多登录名等其他特殊需求），最大一个原因，其实用户信息是一个读大于写的库，web2.0都是以用户为中心，所有信息都和用户信息相关联，所以对用户信息拆分还是有一定局限性的。

       对于这类读大于写并且数据量增加不是很明显的数据库，推荐采用读写分离+缓存的模式，试想一下一个用户注册、修改用户信息、记录用户登录时间、记录用户登录IP、修改登录密码，这些是写操作。但是以上这些操作次数都是很小的，所以整个数据库的写压力是很小的。唯一一个比较大的就是记录用户登录时间、记录用户登录IP这类信息，只要把这些经常变动的信息排除在外，那么写操作可以忽略不计。所以读写分离首要解决的就是经常变化的数据的拆分，比如：用户登录时间、记录用户登录IP。这类信息可以单独独立出来，记录在持久化类的缓存中（可靠性要求并不高，登陆时间、IP丢了就丢了，下次来了就又来了）

        以oracle为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操作，同步更新cache，每次读取先读cache在读DB。写库就一个，读库可以有多个，采用dataguard来负责主库和多个读库的数据同步。

总结：

    Oracle数据库的分区技术可以改善查询性能，仅搜索自己关心的分区，提高检索速度。同时可以把不同的分区分离至不同的磁盘上，以平衡I/0
，改善整个系统的性能。除此之外，在数据维护方面，分区技术也有很大的优势。在进行历史数据转储时，只需要将需要转储的数据分区export备份出来转储至磁带中。而不需要将整张表全部export备份出来。在历史数据清理时可以将历史数据所在的分区truncate或drop，而不影响表的其他数据，同时释放空间。


(二)
现象：zabbix邮件报警，故障PROBLEM,服务 Free disk space isless than 20% on volume :xxx.xxx.xxx.xxx发生:/data故障!

　　分析过程及解决方案：通常出现这种问题都应该磁盘剩余空间过低，使用df –lh检查，发现磁盘空间已使用82%。再进一步通过du –sh对可以的目录进行检查，发现是mysql的binlog占用空间过大。清理binlog的方法如下：

　　1) 设置日志保留时长expire_logs_days自动删除

　　查看当前日志保存天数：

　　show variables like '%expire_logs_days%';

　　这个默认是0，也就是logs不过期，可通过设置全局的参数，使他临时生效：

　　set global expire_logs_days=7;

　　设置了只保留7天BINLOG, 下次重启mysql这个参数默认会失败，所以需在my.cnf中设置

　　expire_logs_days = 7

　　2) 手动删除BINLOG (purge binary logs)

　　用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件

　　PURGE {MASTER | BINARY} LOGS TO 'log_name'

　　PURGE {MASTER | BINARY} LOGS BEFORE 'date'

　　例如：

　　PURGE MASTER LOGS TO 'mysql-bin.010';

　　PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00';

　　PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);

（三）

mysql-proxy实现读写分离

文章来自整理:http://blog.jobbole.com/94606/
其中Amoeba for MySQL也是实现读写分离

环境描述:
操作系统：CentOS6.5 32位
主服务器Master：192.168.179.146
从服务器Slave：192.168.179.147
调度服务器MySQL-Proxy：192.168.179.142
由于电脑配置不行，安装了三台虚拟机，就卡死了，只能将就一下,由于是一主
一从，所以，导致读写都在master上，有机会，再弄两台slave来测试
一.mysql主从复制，参考：http://www.cnblogs.com/lin3615/p/5679828.html

二、mysql-proxy实现读写分离
1、安装mysql-proxy
实现读写分离是有lua脚本实现的，现在mysql-proxy里面已经集成，无需再安装

下载：http://dev.mysql.com/downloads/mysql-proxy/ 一定要下载对应的版本

tar zxvf mysql-proxy-0.8.5-linux-glibc2.3-x86-32bit.tar.gz
mv mysql-proxy-0.8.5-linux-glibc2.3-x86-32bit /usr/local/mysql-proxy

2、配置mysql-proxy，创建主配置文件

cd /usr/local/mysql-proxy
mkdir lua #创建脚本存放目录
mkdir logs #创建日志目录
cp share/doc/mysql-proxy/rw-splitting.lua ./lua #复制读写分离配置文件
cp share/doc/mysql-proxy/admin-sql.lua ./lua #复制管理脚本
vi /etc/mysql-proxy.cnf   #创建配置文件
[mysql-proxy]
user=root #运行mysql-proxy用户
admin-username=lin3615 #主从mysql共有的用户
admin-password=123456 #用户的密码
proxy-address=192.168.179.142:4040 #mysql-proxy运行ip和端口，不加端口，默认4040
proxy-read-only-backend-addresses=192.168.179.147 #指定后端从slave读取数据
proxy-backend-addresses=192.168.179.146 #指定后端主master写入数据
proxy-lua-script=/usr/local/mysql-proxy/lua/rw-splitting.lua #指定读写分离配置文件位置
admin-lua-script=/usr/local/mysql-proxy/lua/admin-sql.lua #指定管理脚本
log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log #日志位置
log-level=info #定义log日志级别，由高到低分别有(error|warning|info|message|debug)
daemon=true    #以守护进程方式运行
keepalive=true #mysql-proxy崩溃时，尝试重启
#保存退出！
chmod 660 /etc/mysql-porxy.cnf

3、修改读写分离配置文件

vim /usr/local/mysql-proxy/lua/rw-splitting.lua
if not proxy.global.config.rwsplit then
 proxy.global.config.rwsplit = {
  min_idle_connections = 1, #默认超过4个连接数时，才开始读写分离，改为1
  max_idle_connections = 1, #默认8，改为1
  is_debug = false
 }
end

4、启动mysql-proxy

/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/etc/mysql-proxy.cnf
netstat -tupln | grep 4000 #已经启动

killall -9 mysql-proxy #关闭mysql-proxy使用

5、测试读写分离
(1).在主服务器创建proxy用户用于mysql-proxy使用，从服务器也会同步这个操作

mysql> grant all on *.* to 'lin3615'@'192.168.179.142' identified by '123456';

(2).使用客户端连接mysql-proxy

mysql -u lin3615 -h 192.168.179.142 -P 4040 -p123456

接下来就按基本的 curd执行即可,由于只有一台slave，测试时，每次读写都是从master，电脑性能无法开四台虚拟机，所以有机会，再测试多台 slave，看下是否ＯＫ

读写分离，延迟是个大问题

在slave服务器上执行 show slave status,
可以看到很多同步的参数,要注意的参数有：
Master_Log_File:slave中的I/O线程当前正在读取的master服务器二进制式日志文件名.
Read_Master_Log_Pos:在当前的 master服务器二进制日志中，slave中的I/O线程已经读取的位置
Relay_Log_File:SQL线程当前正在读取与执行中继日志文件的名称
Relay_Log_Pos:在当前的中继日志中，SQL线程已读取和执行的位置
Relay_Master_Log_File:由SQL线程执行的包含多数近期事件的master二进制日志文件的名称
Slave_IO_Running:I/O线程是否被启动并成功连接到master
Slave_SQL_Running:SQL线程是否被启动
Seconds_Behind_Master:slave服务器SQL线程和从服务器I/O线程之间的差距，单位为秒计

slave同步延迟情况出现：
1.Seconds_Behind_Master不为了，这个值可能会很大
2.Relay_Master_Log_File和Master_Log_File显示bin-log的编号相差很大，说明bin-log在slave上没有及时同步，所以近期执行的 bin-log和当前I/O线程所读的 bin-log相差很大
3.mysql的 slave数据库目录下存在大量的 mysql-relay-log日志，该日志同步完成之后就会被系统自动删除，存在大量日志，说明主从同步延迟很厉害

mysql主从同步延迟原理
mysql主从同步原理
主库针对读写操作，顺序写 binlog，从库单线程去主库读"写操作的binlog",从库取到 binlog在本地原样执行(随机写),来保证主从数据逻辑上一致.
mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生 binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率比较高，下一步问题来了，slave的 slave_sql_running线程将主库的 DDL和DML操作在 slave实施。DML，DDL的IO操作是随即的，不能顺序的，成本高很多，还有可能slave上的其他查询产生 lock，由于 slave_sql_running也是单线程的，所以 一个 DDL卡住了，需求需求执行一段时间，那么所有之后的DDL会等待这个 DDL执行完才会继续执行，这就导致了延迟.由于master可以并发，Slave_sql_running线程却不可以，所以主库执行 DDL需求一段时间，在slave执行相同的DDL时，就产生了延迟.

主从同步延迟产生原因
当主库的TPS并发较高时，产生的DDL数量超过Slave一个 sql线程所能承受的范围，那么延迟就产生了，当然还有就是可能与 slave的大型 query语句产生了锁等待
首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高
次要原因：读写 binlog带来的性能影响，网络传输延迟
主从同步延迟解决方案
架构方面
1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展分散压力
2.单个库读写分离，一主多从，主写从读，分散压力。
3.服务的基础架构在业务和mysql之间加放 cache层
4.不同业务的mysql放在不同的机器
5.使用比主加更了的硬件设备作slave
反正就是mysql压力变小，延迟自然会变小

硬件方面：
采用好的服务器

mysql主从同步加速
1、sync_binlog在slave端设置为0
2、–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。
3、直接禁用slave端的binlog
4、slave端，如果使用的存储引擎是innodb，innodb_flush_log_at_trx_commit =2

从文件系统本身属性角度优化
master端
修改linux、Unix文件系统中文件的etime属性， 由于每当读文件时OS都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响I/O性能。可以通过设置文件系统的mount属性，组织操作系统写atime信息，在linux上的操作为：
打开/etc/fstab，加上noatime参数
/dev/sdb1 /data reiserfs noatime 1 2
然后重新mount文件系统
#mount -oremount /data

主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置是需要的
而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率
1、sync_binlog=1 o
MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。
默认，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。
但是binlog虽然是顺序IO，但是设置sync_binlog=1，多个事务同时提交，同样很大的影响MySQL和IO性能。
虽然可以通过group commit的补丁缓解，但是刷新的频率过高对IO的影响也非常大。对于高并发事务的系统来说，
“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
所以很多MySQL DBA设置的sync_binlog并不是最安全的1，而是2或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。
默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。

2、innodb_flush_log_at_trx_commit （这个很管用）
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。
日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。

3、ls(1) 命令可用来列出文件的 atime、ctime 和 mtime。
atime 文件的access time 在读取文件或者执行文件时更改的
ctime 文件的create time 在写入文件，更改所有者，权限或链接设置时随inode的内容更改而更改
mtime 文件的modified time 在写入文件时随文件内容的更改而更改
ls -lc filename 列出文件的 ctime
ls -lu filename 列出文件的 atime
ls -l filename 列出文件的 mtime
stat filename 列出atime，mtime，ctime
atime不一定在访问文件之后被修改
因为：使用ext3文件系统的时候，如果在mount的时候使用了noatime参数那么就不会更新atime信息。
这三个time stamp都放在 inode 中.如果mtime,atime 修改,inode 就一定会改, 既然 inode 改了,那ctime也就跟着改了.
之所以在 mount option 中使用 noatime, 就是不想file system 做太多的修改, 而改善读取效能

4.进行分库分表处理，这样减少数据量的复制同步操作