海浪家园

10.6 选择一种表类型

用MySQL，当前(版本 3.23.5)你能从一个速度观点在4可用表的格式之间选择。

静态MyISAM

这种格式是最简单且最安全的格式，它也是在磁盘格式最快的。速度来自于数据能在磁盘上被找的难易方式。当所定有一个索引和静态格式的东西时，它很简单，只是行长度乘以行数量。而且在扫描一张表时，用每次磁盘读取来读入常数个记录是很容易的。安全性来自于如果当写入一个静态MyISAM文件时，你的计算机崩溃，myisamchk能很容易指出每行在哪儿开始和结束，因此它通常能回收所有记录，除了部分被写入的那个。注意，在MySQL中，所有索引总能被重建。

动态MyISAM

这种格式有点复杂，因为每一行必须有一个头说明它有多长。当一个记录在更改时变长时，它也可以在多于一个位置上结束。你能使用OPTIMIZE table或myisamchk整理一张表。如果你在同一个表中有象某些VARCHAR或BLOB列那样存取/改变的静态数据，将动态列移入另外一个表以避免碎片可能是一个好主意。

压缩MyISAM

这是一个只读类型，用可选的myisampack工具生成。

10.3 使你的数据尽可能小

最基本的优化之一是使你的数据(和索引)在磁盘上(并且在内存中)占据的空间尽可能小。这能给出巨大的改进，因为磁盘读入较快并且通常也用较少的主存储器。如果在更小的列上做索引，索引也占据较少的资源。

你能用下面的技术使表的性能更好并且使存储空间最小：

尽可能地使用最有效(最小)的类型。MySQL有很多节省磁盘空间和内存的专业化类型。

如果可能使表更小，使用较小的整数类型。例如，MEDIUMINT经常比INT好一些。

如果可能，声明列为NOT NULL。它使任何事情更快而且你为每列节省一位。注意如果在你的应用序中你确实需要NULL，你应该毫无疑问使用它，只是避免缺省地在所有列上有它。

如果你没有任何变长列(VARCHAR、TEXT或BLOB列)，使用固定尺寸的记录格式。这比较快但是不幸地可能会浪费一些空间。见10.6 选择一种表类型。

每张桌子应该有尽可能短的主索引。这使一行的辨认容易而有效。

对每个表，你必须决定使用哪种存储/索引方法。见9.4 MySQL表类型。也可参见10.6 选择一种表类型。

只创建你确实需要的索引。索引对检索有好处但是当你需要快速存储东西时就变得糟糕。如果你主要通过搜索列的组合来存取一个表，以它们做一个索引。第一个索引部分应该是最常用的列。如果

你总是使用许多列，你应该首先以更多的副本使用列以获得更好的列索引压缩。

如果很可能一个索引在头几个字符上有唯一的前缀，仅仅索引该前缀比较好。MySQL支持在一个字符列的一部分上的索引。更短的索引更快，不仅因为他们占较少的磁盘空间而且因为他们将在索引缓存中给你更多的命中率并且因此有更少磁盘寻道。见10.2.3 调节服务器参数。

10.2.3 调节服务器参数
你能用这个命令得到mysqld服务器缺省缓冲区大小：

shell>; mysqld --help

这个命令生成一张所有mysqld选项和可配置变量的表。输出包括缺省值并且看上去象这样一些东西：

Possible variables for option --set-variable (-O) are:
back_log              current value: 5
connect_timeout       current value: 5
delayed_insert_timeout  current value: 300
delayed_insert_limit  current value: 100
delayed_queue_size    current value: 1000
flush_time            current value: 0
interactive_timeout   current value: 28800
join_buffer_size      current value: 131072
key_buffer_size       current value: 1048540
lower_case_table_names  current value: 0
long_query_time       current value: 10

MySQL中文参考手册
--------------------------------------------------------------------------------

10 从MySQL得到最大的性能

优化是一项复杂的任务，因为它最终需要对整个系统的理解。当用你的系统/应用的小知识做一些局部优化是可能的时候，你越想让你的系统更优化，你必须知道它也越多。

因此，本章将试图解释并给出优化MySQL的不同方法的一些例子。但是记住总是有某些(逐渐变难)是系统更快的方法留着去做。

10.1 优化概述
为了使一个系统更快的最重要部分当然是基本设计。你也需要知道你的系统将做这样的事情，那就是你的瓶颈。

最常见的瓶颈是：

磁盘寻道。磁盘花时间找到一个数据，用在1999年的现代磁盘其平均时间通常小于10ms，因此理论上我们能大约一秒寻道 1000 次。这个时间用新磁盘提高很慢并且很难对一个表优化。优化它的方法是将数据散布在多个磁盘上。

当磁盘在我们需要读数据的正确位置时，磁盘读/写。用1999年的现代，一个磁盘传输类似10-20Mb/s。这必寻道更容易优化，因为你能从多个磁盘并行地读。

CPU周期。当我们读数据进内存时，(或如果它已经在那里)我们需要处理它以达到我们的结果。当我们有相对内存较小的表时，这是最常见的限制因素，但是用小表速度通常不是问题。

内存带宽。当CPU需要超出适合cpu缓存的数据时，缓存带宽就成为内存的一个瓶颈。这是对大多数系统的一个不常见的瓶颈但是你应该知道它。

作者: Jun 日期: 2010年01月11日

这两天，一台VPS服务器的MYSQL进程的物理内存（>700MB）和虚拟内存(>1.4G)使用率非常高(上面仅仅跑了4个站)。

开始怀疑是某个网站程序设计上出了问题，找程序员商量了，没查出问题，汗。。。。

最后发现是一低级错误：



优化mysql数据库性能的十个参数

(1)、max_connections
允许的同时客户的数量。增加该值增加 mysqld 要求的文件描述符的数量。这个数字应该增加，否则，你将经常看到 too many connections 错误。

(2)、record_buffer
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，你可能想要增加该值。

(3)、key_buffer_size
索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小，增加它可得到更好处理的索引(对所有读和多重写)，到你能负担得起那样多。如果你使它太大，系统将开始换页并且真的变慢了。

　　eAccelerator 是一个开源并且免费的 PHP 加速器，优化器，编码器，同时也能够为 PHP提供动态内容缓存。它能够将 PHP 脚本缓存为已编译状态以达到提升 PHP 脚本运行性能的目的，因此传统的预编译几乎被消除。eAccelerator 也能够优化 PHP 脚本以提升 PHP脚本的执行速度。eAccelerator 可有效降低服务器负载并且提高 PHP 程序速度达 1-10 倍。TurckMMCache 是 eAccelerator 的前身。

      eAccelerator 包含一个 PHP 编码器和加载器。您可以使用编码器对 .php 脚本进行编码，从而能够以非源代码方式发布您的 PHP 程序。经过编码的 PHP 程序可以运行在任何安装有PHP 解析环境和 eAccelerator 的站点上，由于编码后的 PHP 程序存储为已编译代码，并且已编译版本中不包含程序的源代码，因此，经过 eAccelerator 编码的 PHP 程序是不能被还原恢复的。当然，一些内部脚本可以被某些不同的反编译引擎工具(如 disassemblers, debuggers等)进行还原恢复，但这并非是微不足道的。

　　eAccelerator 与 Zend Optimizer 加载器兼容。在 php.ini 中，Zend Optimizer 必须在eAccelerator 之后加载。如果您的站点不运行任何经由 Zend 编码器编码的 PHP 脚本，那么我们并不推荐您在安装 eAccelerator 的服务器上安装 Zend Optimizer。

　　eAccelerator 不能运行于 CGI 模式下，但它可以运行于像 lighttpd 类似的 Fast-CGI模式

一、PHP加速器介绍

        PHP加速器是一个为了提高PHP执行效率，从而缓存起PHP的操作码，这样PHP后面执行就不用解析转换了，可以直接调用PHP操作码，这样速度上就提高了不少。

        Apache中使用mod_php的请求、响应执行流程：

　　1、Apache接收请求。
2、Apache传递请求给mod_php。
3、mod_php定位磁盘文件，并加载到内存中。
4、mod_php编译源代码成为opcode树。
5、mod_php执行opcode树。

       PHP加速器相应的就是第四步，它的目的就是防止PHP每次请求都重复编译PHP代码，因为在高访问量的网站上，大量的编译往往没有执行速度快呢？所以这里面有个瓶颈就是PHP的重复编译既影响了速度又加载了服务器负载，为了解决此问题，PHP加速器就这样诞生了。

二、PHP加速器安装与配置

随着PHP流行,PHP的执行效率也越来越被大家关注,可以选择的缓存器也是越来越多,从老的php-memcache到eaccelerator还有新兴的xcache.为了挑选一个合适的缓存器决定自己实测一下,看看哪个缓存器的效率更高,由于php-memcache很少有人用了现在只测试eaccelerator和xcache.

硬件配置:
CPU:Intel 2140（双核心）
内存:2G DDR667
硬盘:80G（IDE接口,2M缓存）

软件版本
系统:Mandriva 2008 free,apache-2.2.6,php-5.2.4,ZendOptimizer-3.3.0,mysql-5.0.45.
测试对象的版本:eaccelerator-0.9.5.2,xcache-1.2.1

测试结论备忘
环境：ubuntu server 9.04
nginx+mysql+fastcgi

1、单独Zend Optimizer优化：
测试结果很不稳定，偏差很大，加速并不多。

2、单独eAccelerator（做为Zend扩展）优化：
测试结果稳定，偏差小，加速也明显。

3、eAccelerator和Zend Optimizer共存：
测试结果稳定，偏差小，加速明显。比单独eAccelerator优化好。

4、单独Xcache优化：
测试结果稳定，偏差小，加速不如单独eAccelerator。

5、Xcache和Zend Optimizer共存：
测试结果稳定，偏差小，加速不如单独eAccelerator。
Xcache就算关闭保护功能，速度也没提升多少。

table_cache指示表高速缓存的大小。当Mysql访问一个表时，如果在Mysql表缓冲区中还有空间，那么这个表就被打开并放入表缓冲区，这样做的好处是可以更快速地访问表中的内容。一般来说，可以通过查看数据库运行峰值时间的状态值Open_tables和Opened_tables，用以判断是否需要增加table_cache的值，即如果open_tables接近table_cache的时候，并且Opened_tables这个值在逐步增加，那就要考虑增加这个值的大小了。

  在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到512，如果机器有4G内存,则默认这个值是 2048，但这非意味着机器内存越大，这个值应该越大，因为table_cache加大后，使得mysql对SQL响应的速度更快了，不可避免的会产生更多的死锁（dead lock），这样反而使得数据库整个一套操作慢了下来，严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断，找到最适合你维护的库的 table_cache值，有人说：“性能优化是一门艺术”，这话一点没错。大凡艺术品，大都是经过千锤百炼，精雕细琢而成。

最近，帮一个朋友优化一个拥有20万主题，100万帖子，3万多会员，平均在线人数2000人的Discuz!论坛，采用Linux2.6+Apache2+mod_php5+MySQL5，服务器配置为双至强+4G内存，优化前，系统平均负载（load average）基本维持在10以上，MySQL的CPU占用率基本在90%以上，优化后，系统平均负载降到0.5以下，MySQL的CPU占用率很少有超过10%的时候。优化前YSlow得分只有35分，优化后YSlow得分86分。现将优化的过程和经验做一个记录：

首先，对Apache进行优化，编辑httpd.conf，设置HostnameLookups、KeepAlive、 MaxKeepAliveRequests以及KeepAliveTimeout四个参数，调整MaxSpareServers、 ServerLimit、MaxClients以及MaxRequestsPerChild参数，还可以考虑弃用prefork而采用worker MPM。设置mod_deflate及mod_expires模块，不过注意Discuz!不能对PHP文件开启Expires，否则会出现问题。另外还可以考虑开启mod_cache和mod_mem_cache模块。另外利用cronolog按天对日志进行轮循截断，如果日志特别大，也可以按小时截断。另外再加上Awstats对日志进行分析，并用gzip对日志进行压缩，自动删除1个月前的日志。

其次，对PHP进行优化，编辑php.ini，调整output_buffering、zlib.output_compression及 max_execution_time、max_input_time、memory_limit等参数，并安装Xcache和Zend Optimizer。

然后对MySQL进行优化。

Apache 是老牌子的网站服务器，论功能和插件，是无出其右，但是论性能，很多新手已经把 Apache 甩在后面，如 lighttpd, Nginx。在更换Web服务器软件这类激进的动作之前，你应该考虑一下：如果您拥有足够多的内存来应付现有的并发访问的话，建议你还是继续使用 Apache，但是作些性能上的调校是应该的。

关于 ServerLimit  和 MaxClients
MaxClients 参数决定了 Apache 最大并发访问数。

对于 mpm_prefork，如果 MaxClients 设置超过了 256，就需要对 ServerLimit 设置，ServerLimit 应该和 MaxClients 一样，至少不小于 MaxClient。

对于 mpm_worker，如果 MaxClients 除以 ThreadsPerChild  超过了 16，就要对 ServerLimit 进行设置。ServerLimit 乘以 ThreadsPerChild 要大于等于 MaxClients。

MaxClients 不是随意设定的
像 Apache 这样重量级的软件，内存消耗是很大的。MaxClients 的计算规则是 Apache 可占用的物理内存，除以单个 Apache进程的内存占用。

因此并发数直接取决于内存的大小。然而如果内存足够大，而配置文件没有跟上，岂不是吃亏？

虚拟主机服务商在运营过程中可能会受到黑客攻击，常见的攻击方式有SYN，DDOS等。通过更换IP，查找被攻击的站点可能避开攻击，但是中断服务的时间比较长。比较彻底的解决方法是添置硬件防火墙。不过，硬件防火墙价格比较昂贵。可以考虑利用Linux 系统本身提供的防火墙功能来防御。

抵御SYN SYN攻击是利用TCP/IP协议3次握手的原理，发送大量的建立连接的网络包，但不实际建立连接，最终导致被攻击服务器的网络队列被占满，无法被正常用户访问。
Linux内核提供了若干SYN相关的配置，用命令： sysctl -a | grep syn 看到：
net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syn_retries = 5

tcp_max_syn_backlog是SYN队列的长度，tcp_syncookies是一个开关，是否打开SYN Cookie 功能，该功能可以防止部分SYN攻击。tcp_synack_retries和tcp_syn_retries定义SYN 的重试次数。加大SYN队列长度可以容纳更多等待连接的网络连接数，打开SYN Cookie功能可以阻止部分 SYN攻击，降低重试次数也有一定效果。

搞了两天,综合网上优秀BLOG并且联系实际整理了下 Apache Mysql 的优化,虽然不一定适合每一个人,但里面的一些参数自己可以自己琢磨测试.不过Apache感觉不怎么样,爷爷的 15分钟在线 2000多IP就卡得不得了,每天90多W PV 都卡,看了下163他们的网络架构,不管是前端还是源段服务器都全是NGINX,看样子以后还得继续努力学习了,


Apache优化

KeepAlive On

KeepAliveTimeout 10


    StartServers          5
    MinSpareServers       10
    MaxSpareServers      20
    ServerLimit          1000
    MaxClients          1000
    MaxRequestsPerChild   10000


主要优化这几个参数,在服务器完全可以承受访问量的时候建议把KeepAlive设置为 on,但网上很多人设置了on但是KeepAliveTime设置为 3-5秒,我认为这样设置根本就没有效果,还不如KeepAlive设置为off,打开一个网页算快也要2秒,人家不可能看3秒又去打开新页面,所以这样设置个人觉得不科学,至少也要10秒,建议使用默认的15秒,如果服务器压力太大可以尝试KeepAlive设置off,以减少一些无效连接,

并发计算参考公式：

变量名说明 Qcache_free_blocks 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理，从而得到一个空闲块。 Qcache_free_memory 缓存中的空闲内存。 Qcache_hits 每次查询在缓存中命中时就增大。

Qcache_inserts 每次插入一个查询时就增大。命中次数除以插入次数就是不中比率；用 1 减去这个值就是命中率。在上面这个例子中，大约有 87% 的查询都在缓存中命中。 Qcache_lowmem_prunes 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况）。 Qcache_not_cached 不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句。 Qcache_queries_in_cache 当前缓存的查询（和响应）的数量。 Qcache_total_blocks 缓存中块的数量。

通常，间隔几秒显示这些变量就可以看出区别，这可以帮助确定缓存是否正在有效地使用。运行 FLUSH STATUS 可以重置一些计数器，如果服务器已经运行了一段时间，这会非常有帮助。

使用非常大的查询缓存，期望可以缓存所有东西，这种想法非常诱人。由于 mysqld 必须要对缓存进行维护，例如当内存变得很低时执行剪除，因此服务器可能会在试图管理缓存时而陷入困境。作为一条规则，如果 FLUSH QUERY CACHE 占用了很长时间，那就说明缓存太大了。