中小型网站架构分析及优化

先看网站架构图：

以上网站架构广泛运用中大型网站中，本文从架构每一层分析所用主流技术和解决手段，有助于初入网站运维朋友们，进一步对网站架构认识，从而自己形成一套架构概念。

第一层：CDN

国内网络分布主要南电信北联通，造成跨地区访问延迟大问题，对于有一定访问量网站来说，增加CDN（内容分发网络）层可有效改善此现象，也是网站加速的最好选择。CDN把网站页面缓存到全国分布的节点上，用户访问时从最近的机房获取数据，这样大大减少网络访问的路径。如果想自己搭建CDN，不建议这么做，因为什么呢？其实说白了，就是什么事别往运维上拦。CDN架构部署不复杂，影响效果的因素却很多，后期管理维护也比较复杂，想达到预期的效果确非易事，这是一个费力不讨好的活，最后老板还是感觉是你能力不足。建议找专做CDN的公司，费用也不贵，有抗流量攻击能力，效果也很好，运维也少很多事，何乐而不为呢！

第二层：反向代理（网页缓存）

如果CDN没有缓存要请求的数据则向这层发起请求，在代理服务器配置缓存功能（本地），代理服务器就查找本地缓存是否有CDN请求的数据，如果有就直接返回给CDN，如果没有则请求后端负载均衡器然后转发给WEB服务器返回数据给代理服务器，代理服务器再将结果给CDN。代理服务器一般缓存不经常变动的静态页面，如image、js、css、html等，主流的缓存软件有Squid、Varnish、Nginx。

第三层：负载均衡

访问量较大的网站都会用到负载均衡，因为这是解决单台服务器性能瓶颈的最好办法。反向代理将请求转发给负载均衡器，负载均衡器根据算法（轮训、负载情况选择后端等）交给后端WEB服务处理，WEB服务处理完成后直接返回数据给反向代理服务器。负载均衡合理分配请求给后端多台WEB服务器，减轻单台服务器并发负载，并保证服务可用性。主流的负载均衡软件有LVS、HAProxy、Nginx。

第四层：WEB服务

WEB服务是处理用户请求的，WEB服务处理效率，直接影响到访问速度，为避免这层因素造成访问慢，应对其进行调优，让WEB服务发挥到最佳状态。常见的WEB服务有Apache和Nginx。

Apache优化：

1).mod_deflate压缩模块

查看是否加载：

# apachectl –M |grep deflate

如果没有安装使用apxs编译进去：

# /usr/local/apache/bin/apxs –c –I –A apache源码目录/modules/mod_deflate.c

deflate配置参数：

<IfModulemod_deflate.c>
DeflateCompressionLevel6 #压缩等级（1-9），数值越大效率越高，消耗CPU也就越高
SetOutputFilterDEFLATE #启用压缩
AddOutputFilterByTypeDEFLATE textml text/plain text/xml #压缩类型
AddOutputFilterByTypeDEFLATE css js html htm xml php
</IfModule>

2).mod_expires缓存模块

查看是否加载：

# apachectl –M |grep expires

如果没有安装使用apxs编译进去：

# /usr/local/apache/bin/apxs –c –I –A apache源码目录/modules/mod_expires.c

再在httpd.conf启用模块：LoadModule expires_module modules/mod_expires.so

缓存机制有三种用法：全局、目录和虚拟主机

全局配置，在配置文件末尾添加：

<IfModulemod_expires.c>
ExpiresActiveon #启用有效期控制，会自动清除已过期的缓存，然后从服务器获取新的
ExpiresDefault "accessplus 1 days" #默认任意格式的文档都是1天后过期
ExpiresByTypetextml "access plus 12 months"
ExpiresByTypeimage/jpg "access plus 12 months" #jpg格式图片缓存12月
</IfModule>

3).工作模式选择及优化

apache有两种常见工作模式，worker和prefork，默认是worker，是混合型的MPM（多路处理模块），支持多进程和多线程，由线程来处理请求，所以可以处理更多请求，提高并发能力，系统资源开销也小于基于进程的MPM，由于线程使用进程内存空间，进程崩溃会导致其下线程崩溃。而prefork是非线程型MPM，进程占用系统资源也比worker多，由于进程处理连接，在工作效率上也比worker更稳定。可通过apache2 –l查看当前工作模式，在编译时使用—with-mpm参数指定工作模式。根据自己业务需求选择不同工作模式，再适当增加工作模式相关参数，可提高处理能力。

配置参数说明：

<IfModuleprefork.c>

StartServers 8 #默认启动8个httpd进程

MinSpareServers 5 #最小的空闲进程数

MaxSpareServers 20 #最大的空闲进程数，如果大于这个值，apache会自动kill一些进程

ServerLimit 256 #服务器允许进程数的上限

MaxClients 256 #同时最多发起多少个访问，超过则进入队列等待

MaxRequestsPerChild 4000 #每个进程启动的最大线程

</IfModule>

Nginx优化：

1).gzip压缩模块

http {

……

gzip on;

gzip_min_length 1k; #允许压缩的页面最小字节数，默认是0，多大都压缩，小于1k的可能适得其反

gzip_buffers 4 16k; #gzip申请内存的大小，按数据大小的4倍去申请内存

gzip_http_version 1.0; #识别http协议版本

gzip_comp_level 2; #压缩级别，1压缩比最小，处理速度最快，9压缩比最大，处理速度最慢

gzip_types text/plainapplication/x-javascripttext/css application/xml image/jpg; #压缩数据类型

gzip_vary on; #根据客户端的http头来判断，是否需要压缩

}

2).expires缓存模块

server {

location ~ .*\.(gif|jpg|png|bmp|swf)$ #缓存数据后缀类型

{

expires 30d; #使用expires缓存模块，缓存到客户端30天

}

location ~ .*\.( jsp|js|css)?$

{

expires 1d;

}

}

3).fastcgi优化

nginx不支持直接调用或者解析动态程序（php），必须通过fastcgi（通用网关接口）来启动php-fpm进程来解析php脚本。也就是说用户请求先到nginx，nginx再将动态解析交给fastcgi，fastcgi启动php-fpm解析php脚本。所以我们有必要对fastcgi和php-fpm进行适当的参数优化。

http {
……
fastcgi_cache_path/usr/localinx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;
# FastCGI缓存指定一个文件路径、目录结构等级、关键字区域存储时间和非活动删除时间
fastcgi_connect_timeout 300; #指定连接到后端FastCGI的超时时间
fastcgi_send_timeout 300; #指定向FastCGI传送请求的超时时间
fastcgi_read_timeout 300; #指定接收FastCGI应答的超时时间
fastcgi_buffer_size 64k; #指定读取FastCGI应答第一部分需要多大的缓冲区
fastcgi_buffers 4 64k; #指定本地需要用多少盒多大的缓冲区来缓冲FastCGI的应答请求
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k; #表示在写入缓存文件时使用多大的数据块，默认值是fastcgi_buffers的两倍
fastcgi_cache TEST; #开启fastcgi_cache缓存并指定一个TEST名称
fastcgi_cache_valid 200 302 1h; #指定200、302应答代码的缓存1小时
fastcgi_cache_valid 301 1d; #将301应答代码缓存1天
fastcgi_cache_valid any 1m; #将其他应答均缓存1分钟
{

php-fpm.conf配置参数：

pm =dynamic #两种控制子进程方式（static和dynamic）

pm.max_children= 5 #同一时间存活的最大子进程数

pm.start_servers= 2 #启动时创建的进程数

pm.min_spare_servers= 1 #最小php-fpm进程数

pm.max_spare_servers= 3 #最大php-fpm进程数

4).proxy_cache本地缓存模块

http {
……
proxy_temp_path /usr/localinx/proxy_cache/temp; #缓存临时目录
proxy_cache_path /usr/localinx/proxy_cache/cache levels=1:2 keys_zone=one:10m inactive=1d max_size=1g;
#缓存文件实际目录，levels定义层级目录，1:2说明1是一级目录，2是二级目录，keys_zone存储元数据，并分配10M内存空间。inctive表示1天没有被访问的缓存就删除，默认10分钟。max_size是最大分配磁盘空间
server {
listen 80;
server_name 192.168.1.10;
location / {
proxy_cache one; #调用缓存区
#proxy_cache_valid 200 304 12h; #可根据HTTP状态码设置不同的缓存时间
proxy_cache_valid any 10m; #缓存有效期为10分钟
}
#清除URL缓存，允许来自哪个网段的IP可以清除缓存（需要安装第三方模块"ngx_cache_purge"）,清除URL缓存方法：访问http://192.168.1.10/purge/文件名
location ~ /purge(/.*){
allow 127.0.0.1;
allow 192.168.1.0/24;
deny all;
proxy_cache_purge cache_one$host$1$is_args$args;
}
}

小结：

启用压缩模块可以节省一部分带宽，会增加WEB端CPU处理，但在上图网站架构中，WEB端启用压缩模块并没有起到作用，因为传输到上层走的是局域网。对于直接面向用户的架构还是要启用的。WEB也不用启用expires模块，因为有了反向代理服务器和CDN，所以到不了用户浏览器，开启起不到作用。

如果反向代理使用nginx做代理，可开启expires模块，将静态文件缓存到用户浏览器，浏览器发起请求时，先判断本地缓存是否有请求的数据，如果有再判断是否过期，如果不过期就直接浏览缓存数据，哪怕服务器资源已经改变，所以要根据业务情况合理设置过期时间。
5. 利用PHP缓存器提高代码执行效率

php程序在没有使用缓存器情况下，每次请求php页面，php都会对此页面进行代码编译，这就意味着重复的编译工作会增加服务器负载。有了缓存器就会把每次编译后的数据缓存到共享内存中，下次访问直接使用缓冲区已编译好的代码，从而避免重复的编译过程，以加快其执行效率。因此PHP网站使用缓存器是完全有必要的！主流的PHP缓存器有：eAccelerator、XCache

第五层：动静分离

动静分离，顾名思义，是将动态页面和静态页面分离到不同服务器上处理，比如使用web是nginx，可以让fastcgi部署到单独一台服务器，专门解析php动态页面，静态页面默认由nginx处理，并做好缓存策略。再比如一个商城网站，会有大量的图片，可以考虑增加文件服务器组，将请求图片和上传图片的都交给文件服务器处理。文件服务器主流使用NFS，存在单点故障，可以DRBD+HeartBeat+NFS部署高可用，如果单台压力过大，考虑使用分布式文件系统，如GlusterFS、MooseFS等。

DRBD+HeartBeat+NFS博文：http://lizhenliang.blog.51cto.com/7876557/1362539

第六层：数据库缓存

利用缓存技术，把热数据缓存到内存中，如果请求的数据在缓存中，就直接返回，否则去数据库中取，并更新把拿的数据更新到缓存系统，提高读性能，降低数据库压力。缓存实现有本地缓存和分布式缓存，本地缓存是将数据缓存到本地服务器内存中或者文件中。分布式缓存是将数据缓存到内存中，是分布式的，可以缓存海量数据，扩展性好。主流的分布式缓存系统有Memcached和Redis，Memcached性能稳定，速度很快，QPS可达8w左右。如果想数据持久化就选择用Redis，性能不低于Memcached。

第七层：数据库

这层在整个网站架构中起着主导型作用，直接决定用户体验，相对架构优化也比较复杂，具体请参考博文：http://lizhenliang.blog.51cto.com/7876557/1657465

运维角度浅谈MySQL数据库优化

 一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的，它是随着用户量的增加，基础架构才逐渐完善。这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案，暂且抛开前端应用不说，大致分为以下五个阶段：

1、数据库表设计

  项目立项后，开发部根据产品部需求开发项目，开发工程师工作其中一部分就是对表结构设计。对于数据库来说，这点很重要，如果设计不当，会直接影响访问速度和用户体验。影响的因素很多，比如慢查询、低效的查询语句、没有适当建立索引、数据库堵塞（死锁）等。当然，有测试工程师的团队，会做压力测试，找bug。对于没有测试工程师的团队来说，大多数开发工程师初期不会太多考虑数据库设计是否合理，而是尽快完成功能实现和交付，等项目有一定访问量后，隐藏的问题就会暴露，这时再去修改就不是这么容易的事了。

2、数据库部署

  该运维工程师出场了，项目初期访问量不会很大，所以单台部署足以应对在1500左右的QPS（每秒查询率）。考虑到高可用性，可采用MySQL主从复制+Keepalived做双击热备，常见集群软件有Keepalived、Heartbeat。

双机热备博文：http://lizhenliang.blog.51cto.com/7876557/1362313

3、数据库性能优化

  如果将MySQL部署到普通的X86服务器上，在不经过任何优化情况下，MySQL理论值正常可以处理2000左右QPS，经过优化后，有可能会提升到2500左右QPS，否则，访问量当达到1500左右并发连接时，数据库处理性能就会变慢，而且硬件资源还很富裕，这时就该考虑软件问题了。那么怎样让数据库最大化发挥性能呢？一方面可以单台运行多个MySQL实例让服务器性能发挥到最大化，另一方面是对数据库进行优化，往往操作系统和数据库默认配置都比较保守，会对数据库发挥有一定限制，可对这些配置进行适当的调整，尽可能的处理更多连接数。

具体优化有以下三个层面：

  3.1 数据库配置优化

  MySQL常用有两种存储引擎，一个是MyISAM，不支持事务处理，读性能处理快，表级别锁。另一个是InnoDB，支持事务处理（ACID），设计目标是为处理大容量数据发挥最大化性能，行级别锁。

  表锁：开销小，锁定粒度大，发生死锁概率高，相对并发也低。

  行锁：开销大，锁定粒度小，发生死锁概率低，相对并发也高。

  为什么会出现表锁和行锁呢？主要是为了保证数据的完整性，举个例子，一个用户在操作一张表，其他用户也想操作这张表，那么就要等第一个用户操作完，其他用户才能操作，表锁和行锁就是这个作用。否则多个用户同时操作一张表，肯定会数据产生冲突或者异常。

  根据以上看来，使用InnoDB存储引擎是最好的选择，也是MySQL5.5以后版本中默认存储引擎。每个存储引擎相关联参数比较多，以下列出主要影响数据库性能的参数。

  公共参数默认值：

1 2 3 4 5 6 7 8 9 10

max_connections = 151 #同时处理最大连接数，推荐设置最大连接数是上限连接数的80%左右    sort_buffer_size = 2M #查询排序时缓冲区大小，只对order by和group by起作用，可增大此值为16M query_cache_limit = 1M   #查询缓存限制，只有1M以下查询结果才会被缓存，以免结果数据较大把缓存池覆盖 query_cache_size = 16M   #查看缓冲区大小，用于缓存SELECT查询结果，下一次有同样SELECT查询将直接从缓存池返回结果，可适当成倍增加此值 open_files_limit = 1024  #打开文件数限制，如果show global status like 'open_files'查看的值等于或者大于open_files_limit值时，程序会无法连接数据库或卡死

  MyISAM参数默认值：

1 2 3 4

key_buffer_size = 16M #索引缓存区大小，一般设置物理内存的30-40% read_buffer_size = 128K   #读操作缓冲区大小，推荐设置16M或32M

  InnoDB参数默认值：

1 2 3 4 5 6 7 8 9 10

innodb_buffer_pool_size = 128M #索引和数据缓冲区大小，一般设置物理内存的60%-70% innodb_buffer_pool_instances = 1     #缓冲池实例个数，推荐设置4个或8个 innodb_flush_log_at_trx_commit = 1   #关键参数，0代表大约每秒写入到日志并同步到磁盘，数据库故障会丢失1秒左右事务数据。1为每执行一条SQL后写入到日志并同步到磁盘，I/O开销大，执行完SQL要等待日志读写，效率低。2代表只把日志写入到系统缓存区，再每秒同步到磁盘，效率很高，如果服务器故障，才会丢失事务数据。对数据安全性要求不是很高的推荐设置2，性能高，修改后效果明显。 innodb_file_per_table = OFF   #默认是共享表空间，共享表空间idbdata文件不断增大，影响一定的I/O性能。推荐开启独立表空间模式，每个表的索引和数据都存在自己独立的表空间中，可以实现单表在不同数据库中移动。 innodb_log_buffer_size = 8M   #日志缓冲区大小，由于日志最长每秒钟刷新一次，所以一般不用超过16M

  3.2 系统内核优化

  大多数MySQL都部署在linux系统上，所以操作系统的一些参数也会影响到MySQL性能，以下对linux内核进行适当优化。

1 2 3 4 5 6 7 8 9 10

net.ipv4.tcp_fin_timeout = 30 #TIME_WAIT超时时间，默认是60s net.ipv4.tcp_tw_reuse = 1     #1表示开启复用，允许TIME_WAIT socket重新用于新的TCP连接，0表示关闭 net.ipv4.tcp_tw_recycle = 1   #1表示开启TIME_WAIT socket快速回收，0表示关闭 net.ipv4.tcp_max_tw_buckets = 4096    #系统保持TIME_WAIT socket最大数量，如果超出这个数，系统将随机清除一些TIME_WAIT并打印警告信息 net.ipv4.tcp_max_syn_backlog = 4096 #进入SYN队列最大长度，加大队列长度可容纳更多的等待连接

  在linux系统中，如果进程打开的文件句柄数量超过系统默认值1024，就会提示“too many files open”信息，所以要调整打开文件句柄限制。

1 2 3 4

# vi /etc/security/limits.conf  #加入以下配置，*代表所有用户，也可以指定用户，重启系统生效 * soft nofile 65535 * hard nofile 65535 # ulimit -SHn 65535   #立刻生效

  3.3 硬件配置

  加大物理内存，提高文件系统性能。linux内核会从内存中分配出缓存区（系统缓存和数据缓存）来存放热数据，通过文件系统延迟写入机制，等满足条件时（如缓存区大小到达一定百分比或者执行sync命令）才会同步到磁盘。也就是说物理内存越大，分配缓存区越大，缓存数据越多。当然，服务器故障会丢失一定的缓存数据。

  SSD硬盘代替SAS硬盘，将RAID级别调整为RAID1+0，相对于RAID1和RAID5有更好的读写性能（IOPS），毕竟数据库的压力主要来自磁盘I/O方面。

4、数据库架构扩展

  随着业务量越来越大，单台数据库服务器性能已无法满足业务需求，该考虑加机器了，该做集群了~~~。主要思想是分解单台数据库负载，突破磁盘I/O性能，热数据存放缓存中，降低磁盘I/O访问频率。

  4.1 主从复制与读写分离

  因为生产环境中，数据库大多都是读操作，所以部署一主多从架构，主数据库负责写操作，并做双击热备，多台从数据库做负载均衡，负责读操作，主流的负载均衡器有LVS、HAProxy、Nginx。

  怎么来实现读写分离呢？大多数企业是在代码层面实现读写分离，效率比较高。另一个种方式通过代理程序实现读写分离，企业中应用较少，常见代理程序有MySQL Proxy、Amoeba。在这样数据库集群架构中，大大增加数据库高并发能力，解决单台性能瓶颈问题。如果从数据库一台从库能处理2000 QPS，那么5台就能处理1w QPS，数据库横向扩展性也很容易。

  有时，面对大量写操作的应用时，单台写性能达不到业务需求。如果做双主，就会遇到数据库数据不一致现象，产生这个原因是在应用程序不同的用户会有可能操作两台数据库，同时的更新操作造成两台数据库数据库数据发生冲突或者不一致。在单库时MySQL利用存储引擎机制表锁和行锁来保证数据完整性，怎样在多台主库时解决这个问题呢？有一套基于perl语言开发的主从复制管理工具，叫MySQL-MMM（Master-Master replication managerfor Mysql，Mysql主主复制管理器），这个工具最大的优点是在同一时间只提供一台数据库写操作，有效保证数据一致性。

  主从复制博文：http://lizhenliang.blog.51cto.com/7876557/1290431

  读写分离博文：http://lizhenliang.blog.51cto.com/7876557/1305083

 MySQL-MMM博文：http://lizhenliang.blog.51cto.com/7876557/1354576

  4.2 增加缓存

  给数据库增加缓存系统，把热数据缓存到内存中，如果缓存中有要请求的数据就不再去数据库中返回结果，提高读性能。缓存实现有本地缓存和分布式缓存，本地缓存是将数据缓存到本地服务器内存中或者文件中。分布式缓存可以缓存海量数据，扩展性好，主流的分布式缓存系统有memcached、redis，memcached性能稳定，数据缓存在内存中，速度很快，QPS可达8w左右。如果想数据持久化就选择用redis，性能不低于memcached。

  工作过程：

  

  4.3 分库

  分库是根据业务不同把相关的表切分到不同的数据库中，比如web、bbs、blog等库。如果业务量很大，还可将切分后的库做主从架构，进一步避免单个库压力过大。

  4.4 分表

  数据量的日剧增加，数据库中某个表有几百万条数据，导致查询和插入耗时太长，怎么能解决单表压力呢？你就该考虑是否把这个表拆分成多个小表，来减轻单个表的压力，提高处理效率，此方式称为分表。

  分表技术比较麻烦，要修改程序代码里的SQL语句，还要手动去创建其他表，也可以用merge存储引擎实现分表，相对简单许多。分表后，程序是对一个总表进行操作，这个总表不存放数据，只有一些分表的关系，以及更新数据的方式，总表会根据不同的查询，将压力分到不同的小表上，因此提高并发能力和磁盘I/O性能。

  分表分为垂直拆分和水平拆分：

  垂直拆分：把原来的一个很多字段的表拆分多个表，解决表的宽度问题。你可以把不常用的字段单独放到一个表中，也可以把大字段独立放一个表中，或者把关联密切的字段放一个表中。

  水平拆分：把原来一个表拆分成多个表，每个表的结构都一样，解决单表数据量大的问题。

  4.5 分区

  分区就是把一张表的数据根据表结构中的字段（如range、list、hash等）分成多个区块，这些区块可以在一个磁盘上，也可以在不同的磁盘上，分区后，表面上还是一张表，但数据散列在多个位置，这样一来，多块硬盘同时处理不同的请求，从而提高磁盘I/O读写性能，实现比较简单。

注：增加缓存、分库、分表和分区主要由程序猿来实现。

5、数据库维护

  数据库维护是运维工程师或者DBA主要工作，包括性能监控、性能分析、性能调优、数据库备份和恢复等。

  5.1 性能状态关键指标

  QPS，Queries Per Second：每秒查询数，一台数据库每秒能够处理的查询次数

  TPS，Transactions Per Second：每秒处理事务数

  通过show status查看运行状态，会有300多条状态信息记录，其中有几个值帮可以我们计算出QPS和TPS，如下：

  Uptime：服务器已经运行的实际，单位秒

  Questions：已经发送给数据库查询数

  Com_select：查询次数，实际操作数据库的

  Com_insert：插入次数

  Com_delete：删除次数

  Com_update：更新次数

  Com_commit：事务次数

  Com_rollback：回滚次数

  那么，计算方法来了，基于Questions计算出QPS：

1 2	mysql> show global status like  'Questions' ;    mysql> show global status like  'Uptime' ;

  QPS = Questions / Uptime

  基于Com_commit和Com_rollback计算出TPS：

1 2 3

mysql> show global status like  'Com_commit' ;    mysql> show global status like  'Com_rollback' ;    mysql> show global status like  'Uptime' ;

  TPS = (Com_commit + Com_rollback) / Uptime

  另一计算方式：基于Com_select、Com_insert、Com_delete、Com_update计算出QPS

1	mysql> show global status where Variable_name  in ( 'com_select' , 'com_insert' , 'com_delete' , 'com_update' );

  等待1秒再执行，获取间隔差值，第二次每个变量值减去第一次对应的变量值，就是QPS

  TPS计算方法：

1	mysql> show global status where Variable_name  in ( 'com_insert' , 'com_delete' , 'com_update' );

  计算TPS，就不算查询操作了，计算出插入、删除、更新四个值即可。

  经网友对这两个计算方式的测试得出，当数据库中myisam表比较多时，使用Questions计算比较准确。当数据库中innodb表比较多时，则以Com_*计算比较准确。

  5.2 开启慢查询日志

  MySQL开启慢查询日志，分析出哪条SQL语句比较慢，使用set设置变量，重启服务失效，可以在my.cnf添加参数永久生效。

1 2 3 4

mysql>  set  global slow-query-log=on   #开启慢查询功能 mysql>  set  global slow_query_log_file= '/var/log/mysql/mysql-slow.log' ;   #指定慢查询日志文件位置 mysql>  set  global log_queries_not_using_indexes=on;    #记录没有使用索引的查询 mysql>  set  global long_query_time=1;    #只记录处理时间1s以上的慢查询

  分析慢查询日志，可以使用MySQL自带的mysqldumpslow工具，分析的日志较为简单。

  # mysqldumpslow -t 3 /var/log/mysql/mysql-slow.log    #查看最慢的前三个查询

  也可以使用percona公司的pt-query-digest工具，日志分析功能全面，可分析slow log、binlog、general log。

  分析慢查询日志：pt-query-digest /var/log/mysql/mysql-slow.log

  分析binlog日志：mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql 

  pt-query-digest --type=binlog mysql-bin.000001.sql 

  分析普通日志：pt-query-digest --type=genlog localhost.log

  5.3 数据库备份

  备份数据库是最基本的工作，也是最重要的，否则后果很严重，你懂得！但由于数据库比较大，上百G，往往备份都很耗费时间，所以就该选择一个效率高的备份策略，对于数据量大的数据库，一般都采用增量备份。常用的备份工具有mysqldump、mysqlhotcopy、xtrabackup等，mysqldump比较适用于小的数据库，因为是逻辑备份，所以备份和恢复耗时都比较长。mysqlhotcopy和xtrabackup是物理备份，备份和恢复速度快，不影响数据库服务情况下进行热拷贝，建议使用xtrabackup，支持增量备份。

  Xtrabackup备份工具使用博文：http://lizhenliang.blog.51cto.com/7876557/1612800

  5.4 数据库修复

  有时候MySQL服务器突然断电、异常关闭，会导致表损坏，无法读取表数据。这时就可以用到MySQL自带的两个工具进行修复，myisamchk和mysqlcheck。

  myisamchk：只能修复myisam表，需要停止数据库

  常用参数：

  -f --force    强制修复，覆盖老的临时文件，一般不使用

  -r --recover  恢复模式

  -q --quik     快速恢复

  -a --analyze  分析表

  -o --safe-recover 老的恢复模式，如果-r无法修复，可以使用此参数试试

  -F --fast     只检查没有正常关闭的表

  快速修复weibo数据库:

  # cd /var/lib/mysql/weibo 

  # myisamchk -r -q *.MYI

  mysqlcheck：myisam和innodb表都可以用，不需要停止数据库，如修复单个表，可在数据库后面添加表名，以空格分割

  常用参数：

  -a  --all-databases  检查所有的库

  -r  --repair   修复表

  -c  --check    检查表，默认选项

  -a  --analyze  分析表

  -o  --optimize 优化表

  -q  --quik   最快检查或修复表

  -F  --fast   只检查没有正常关闭的表

  快速修复weibo数据库:

  mysqlcheck -r -q -uroot -p123 weibo 

  5.5 另外，查看CPU和I/O性能方法

  #查看CPU性能

  #参数-P是显示CPU数，ALL为所有，也可以只显示第几颗CPU

  #查看I/O性能

  #参数-m是以M单位显示，默认K

  #%util：当达到100%时，说明I/O很忙。

  #await：请求在队列中等待时间，直接影响read时间。

  I/O极限：IOPS（r/s+w/s）,一般RAID0/10在1200左右。（IOPS，每秒进行读写（I/O）操作次数）

  I/O带宽：在顺序读写模式下SAS硬盘理论值在300M/s左右，SSD硬盘理论值在600M/s左右。

  以上是本人使用MySQL三年来总结的一些主要优化方案，能力有限，有些不太全面，但这些基本能够满足中小型企业数据库需求。

  由于关系型数据库初衷设计限制，一些BAT公司海量数据放到关系型数据库中，在海量数据查询和分析方面已经达不到更好的性能。因此NoSQL火起来了，非关系型数据库，大数据量，具有高性能，同时也弥补了关系型数据库某方面不足，渐渐大多数公司已经将部分业务数据库存放到NoSQL中，如MongoDB、HBase等。数据存储方面采用分布式文件系统，如HDFS、GFS等。海量数据计算分析采用Hadoop、Spark、Storm等。这些都是与运维相关的前沿技术，也是在存储方面主要学习对象，小伙伴们共同加油吧！哪位博友有更好的优化方案，欢迎交流哦。

核心思路：减少请求层，尽可能让前端层返回用户请求的数据，减少后端服务器访问频率，最重要是数据库层。

原文：http://lizhenliang.blog.51cto.com/7876557/1664428