最近再做个mysql一从多主的配置，需要在一台机器上安装多个mysql。
起先是按照复制了多了mysql 同时起，在琢磨如何做启动脚本的时候发现support-files目录下有个mysqld_multi.server文件，一查发现原来是现成的多实例管理工具。
首先得新建个data目录给新的实例，可以把原来的data目录复制个新的 只需要mysql库，也可以用工具部属个

1

./scripts/mysql_install_db --basedir=/usr/local/mysql3307 --datadir=/mysql/mysql3307/data --user=mysql

然后修改下my.cnf
主要增加

1
2
3
4
5
6

[mysqld_multi]
mysqld = /usr/local/mysql/bin/mysqld_safe
mysqladmin = /usr/local/mysql/bin/mysqladmin
user = shutdown
password = 123456
log = /mysql/mysqld_multi.log

然后把原来的 [mysqld] 改为 [mysqld1]
在新增新的实例配置

1
2
3
4
5
6

[mysqld2]
port = 3307
socket = /tmp/mysql3307.sock
datadir = /storage/mysql/data3307
............
............

然后把 mysqld_multi.server 做成启动服务

1
2
3
4
5
6

cp ./support-files/mysqld_multi.server /etc/rc.d/init.d/mysqld
chown root:root /etc/rc.d/init.d/mysqld
chmod 755 /etc/rc.d/init.d/mysqld
chkconfig --add mysqld
chkconfig --level 3 mysqld on
chkconfig --level 5 mysqld on

启动和关闭全部mysql实例
启动：service mysqld start
关闭：service mysqld stop

对单台数据库的启动和关闭
启动： service mysqld start 1
关闭： service mysqld stop 1

也可以同时启动和关闭多个数据库实例
启动： service mysqld start 1-2
关闭： service mysqld stop 1-2

如果启动的时候提示出错信息：
WARNING: my_print_defaults command not found.
Please make sure you have this command available and
in your path. The command is available from the latest
MySQL distribution.
ABORT: Can’t find command ‘my_print_defaults’.
This command is available from the latest MySQL
distribution. Please make sure you have the command
in your PATH.

先添加
export PATH=/usr/local/mysql/bin:$PATH
然后在启动mysql

两种解决方法：

第一种：卸载KB967723补丁
登录服务器，进入控制面板 — 添加和删除程序 — （勾选上方的“显示更新”）在里面可以看到更新的KB967723这个补丁，然后就想卸载普通软件一样卸载，卸载中会提示你，如果卸载可能导致程序运行出错，没关系，选择“是”，继续卸载。卸载完成后重启数据库服务器。

第二种：修改注册表
本方法是微软给出的修改注册表修复该Bug的的方法，默认最大的临时 TCP 端口的数是 5000 适用于一节中包含的产品中。 在这些产品中添加一个新参数。 要提高临时端口的上限，请按照下列步骤操作：

1. 启动注册表编辑器。
2. 在的注册表中找到以下子项，然后单击 参数 ：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. 在 编辑 菜单上单击 新建 ，，，然后添加下面的注册表项：
数值名称： MaxUserPort
值类型: DWORD
值数据： 65534
有效范围： 5000-65534 (十进制)
默认值： 0×1388 (5000 十进制)
说明： 此参数将控制程序从系统请求任何可用的用户端口时使用的最大端口数。 通常，1024 的值和包含的 5000 之间分配临时的 （短) 端口。
4. 退出注册表编辑器，并重新启动计算机。

请注意 其他的 TCPTimedWaitDelay 注册表参数确定在多长时间关闭的端口等可重复使用已关闭的端口。

微软原文链接：http://support.microsoft.com/kb/q196271

MySQL(4.1以后版本) 服务器中有六个关键位置使用了字符集的概念，他们是：client 、connection、database、results、server 、system。MySQL有两个字符集概念：一个就是字符集本身，一个是字符集校验规则。字符集影响数据在传输和存储过程中的处理方式，而字符集校验则影响ORDER BY和GROUP BY这些排序方式。
1.和存储有关的
服务器字符集 (@@character_set_server)
库字符集 (@@character_set_database)
表字符集
字段字符集
character_set_server: 服务器安装时指定的默认字符集设定。
character_set_database: 数据库服务器中某个库使用的字符集设定，如果建库时没有指明，将使用服务器安装时指定的字符集设置。
character_system: 数据库系统使用的字符集设定。
在创建一个表的时候，每个字段只要不是binary，都会有一个字符集。如果不指定，那么在SHOW CREATE TABLE的时候，它是不会显示出来的。
建表时候，字段字符集的选取方式如下：
* if 字段指定的字符集
* else if 表指定的字符集
* else if @@character_set_database
* else @@character_set_server (如果没有设定，这个值为latin1)
2.和传输有关的
@@character_set_connection
@@character_set_results
@@character_set_client
character_set_connection: 连接数据库的字符集设置类型，如果php没有指明连接数据库使用的字符集类型就按照服务器端默认的字符设置
character_set_results: 数据库给客户端返回时使用的字符集设定，如果没有指明，使用服务器默认的字符集
character_set_client: 客户端使用的字符集，相当于网页中的字符集设置
3.字符集的校对规则
字符集的校对规则设定分别由上面的character_set_connection, character_set_database, character_set_server决定
collation_connection: 连接字符集的校对规则
collation_database: 默认数据库使用的校对规则。当默认数据库改变时服务器则设置该变量。如果没有默认数据库，变量的值同collation_server
collation_server: 服务器的默认校对规则
以上内容中character_set_client, character_set_connection, character_set_results 受客户端默认字符集影响，其中php编译mysql模块时的默认字符集同样也受到它链接的mysql动态库影响，从而影响到php的character_set_connection, character_set_client设定。当默认字符集不是utf8时，设置my.cnf
[mysqld]
default-character-set=utf8
default-collation=utf8_general_ci
default-character-set只能改变对存储层（server,database,table,column,system）的设定，对于客户端和服务器端的通讯层没有任何影响。
mysql> SHOW VARIABLES LIKE ‘character_set_%’;
+————————–+—————————————————————————+
| Variable_name | Value |
+————————–+—————————————————————————+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | utf8 |
| character_set_system | utf8
解决字符集通讯设置不匹配的方法：
(修改默认的character_set_client,character_set_connection,character_set_result)
1. 重新编译mysql和php,mysql加入编译参数 –default-character-set=utf8
2. PHP程序在查询数据库之前，执行mysql_query(”set names utf8;”);
3.修改my.cnf，在[mysqld]中加入init-connect=”set names utf8” (对于超级用户连接该选项无效)
4. 启动mysqld 加入参数 –skip-character-set-client-handshake 忽略客户端字符集

http://www.hiadmin.com/mysql字符集设定总结/

在 MySQL 中，只有一种 Join 算法，就是大名鼎鼎的 Nested Loop Join，他没有其他很多数据库所提供的 Hash Join，也没有 Sort Merge Join。顾名思义，Nested Loop Join 实际上就是通过驱动表的结果集作为循环基础数据，然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。如果还有第三个参与 Join，则再通过前两个表的 Join 结果集作为循环基础数据，再一次通过循环查询条件到第三个表中查询数据，如此往复。

还是通过示例和图解来说明吧，后面将通过我个人数据库测试环境中的一个 example（自行设计，非MySQL 自己提供） 数据库中的三个表的 Join 查询来进行示例。

注意：由于这里有些内容需要在MySQL 5.1.18之后的版本中才会体现出来，所以本测试的MySQL 版本为5.1.26

表结构：

使用Query如下：

看看我们的 Query 的执行计划：

我们可以看出，MySQL Query Optimizer 选择了 user_group 作为驱动表，首先利用我们传入的条件 user_id 通过 该表上面的索引 user_group_uid_ind 来进行 const 条件的索引 ref 查找，然后以 user_group 表中过滤出来的结果集的 group_id 字段作为查询条件，对 group_message 循环查询，然后再通过 user_group 和 group_message 两个表的结果集中的  group_message 的 id 作为条件 与 group_message_content 的 group_msg_id 比较进行循环查询，才得到最终的结果。没啥特别的，后一个引用前一个的结果集作为条件，实现过程可以通过下图表示：

下面的我们调整一下 group_message_content 去掉上面的 idx_group_message_content_msg_id 这个索引，然后再看看会是什么效果：

我们看到不仅仅 group_message_content 表的访问从 ref 变成了 ALL，此外，在最后一行的 Extra信息从没有任何内容变成为  Using where; Using join buffer，也就是说，对于从 ref 变成 ALL 很容易理解，没有可以使用的索引的索引了嘛，当然得进行全表扫描了，Using where 也是因为变成全表扫描之后，我们需要取得的 content 字段只能通过对表中的数据进行 where 过滤才能取得，但是后面出现的 Using join buffer 是一个啥呢？

我们知道，MySQL 中有一个供我们设置的参数 join_buffer_size ，这里实际上就是使用到了通过该参数所设置的 Buffer 区域。那为啥之前的执行计划中没有用到呢？

实际上，Join Buffer 只有当我们的 Join 类型为 ALL（如示例中），index，rang 或者是 index_merge 的时候 才能够使用，所以，在我们去掉 group_message_content 表的 group_msg_id 字段的索引之前，由于 Join 是 ref 类型的，所以我们的执行计划中并没有看到有使用 Join Buffer。

当我们使用了 Join Buffer 之后，我们可以通过下面的这张图片来表示 Join 完成过程：

作者：Sky.Jian

链接：http://www.jianzhaoyang.com/database/mysql_join_buffer_nested_loop_implement

总的来说，在 MySQL 中的ORDER BY有两种排序实现方式，一种是利用有序索引获取有序数据，另一种则是通过相应的排序算法，将取得的数据在内存中进行排序。

下面将通过实例分析两种排序实现方式及实现图解：
假设有 Table A 和 B 两个表结构分别如下：

1、利用有序索引进行排序，实际上就是当我们 Query 的 ORDER BY 条件和 Query 的执行计划中所利用的 Index 的索引键（或前面几个索引键）完全一致，且索引访问方式为 rang、 ref 或者 index 的时候，MySQL 可以利用索引顺序而直接取得已经排好序的数据。这种方式的 ORDER BY 基本上可以说是最优的排序方式了，因为 MySQL 不需要进行实际的排序操作。

假设我们在Table A 和 B 上执行如下SQL：

我们通过执行计划可以看出，MySQL实际上并没有进行实际的排序操作，实际上其整个执行过程如下图所示：

2、通过相应的排序算法，将取得的数据在内存中进行排序方式，MySQL 比需要将数据在内存中进行排序，所使用的内存区域也就是我们通过 sort_buffer_size 系统变量所设置的排序区。这个排序区是每个 Thread 独享的，所以说可能在同一时刻在 MySQL 中可能存在多个 sort buffer 内存区域。

第二种方式在 MySQL Query Optimizer 所给出的执行计划（通过 EXPLAIN 命令查看）中被称为 filesort。在这种方式中，主要是由于没有可以利用的有序索引取得有序的数据，MySQL只能通过将取得的数据在内存中进行排序然后再将数据返回给客户端。在 MySQL 中 filesort 的实现算法实际上是有两种的，一种是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行指针信息，然后在 sort buffer 中进行排序。另外一种是一次性取出满足条件行的所有字段，然后在 sort buffer 中进行排序。

在 MySQL4.1 版本之前只有第一种排序算法，第二种算法是从 MySQL4.1开始的改进算法，主要目的是为了减少第一次算法中需要两次访问表数据的 IO 操作，将两次变成了一次，但相应也会耗用更多的 sort buffer 空间。当然，MySQL4.1开始的以后所有版本同时也支持第一种算法，MySQL 主要通过比较我们所设定的系统参数 max_length_for_sort_data 的大小和 Query 语句所取出的字段类型大小总和来判定需要使用哪一种排序算法。如果 max_length_for_sort_data 更大，则使用第二种优化后的算法，反之使用第一种算法。所以如果希望 ORDER BY 操作的效率尽可能的高，一定要主义 max_length_for_sort_data 参数的设置。曾经就有同事的数据库出现大量的排序等待，造成系统负载很高，而且响应时间变得很长，最后查出正是因为 MySQL 使用了传统的第一种排序算法而导致，在加大了 max_length_for_sort_data 参数值之后，系统负载马上得到了大的缓解，响应也快了很多。

我们再看看 MySQL 需要使用 filesort 实现排序的实例。

假设我们改变一下我们的 Query，换成通过A.c2来排序，再看看情况：

MySQL 从 Table A 中取出了符合条件的数据，由于取得的数据并不满足 ORDER BY 条件，所以 MySQL 进行了 filesort 操作，其整个执行过程如下图所示：

在 MySQL 中，filesort 操作还有一个比较奇怪的限制，那就是其数据源必须是来源于一个 Table，所以，如果我们的排序数据如果是两个（或者更多个） Table 通过 Join所得出的，那么 MySQL 必须通过先创建一个临时表（Temporary Table），然后再将此临时表的数据进行排序，如下例所示：

这个执行计划的输出还是有点奇怪的，不知道为什么，MySQL Query Optimizer 将 “Using temporary” 过程显示在第一行对 Table A 的操作中，难道只是为让执行计划的输出少一行？

实际执行过程应该是如下图所示：

作者：Sky.Jian

链接：http://www.jianzhaoyang.com/database/mysql_order_by_implement

对于任何一个数据库管理系统来说，内存的分配使用绝对可以算的上是其核心之一了，所以很多希望更为深入了解某数据库管理系统的人，都会希望一窥究竟，我也不例外。

从内存的使用方式MySQL 数据库的内存使用主要分为以下两类

• 线程独享内存
• 全局共享内存

今天这篇文章暂时先分析 MySQL 中主要的 “线程独享内存” 的。

在 MySQL 中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。

线程栈信息使用内存(thread_stack)：主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。

排序使用内存(sort_buffer_size)：MySQL 用此内存区域进行排序操作（filesort），完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL 会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，所以sort_buffer_size参数对排序操作的性能影响绝对不可小视。排序操作的实现原理请参考：MySQL Order By 的实现分析。

Join操作使用内存(join_buffer_size)：应用程序经常会出现一些两表（或多表）Join的操作需求，MySQL在完成某些 Join 需求的时候（all/index join），为了减少参与Join的“被驱动表”的读取次数以提高性能，需要使用到 Join Buffer 来协助完成 Join操作（具体 Join 实现算法请参考：MySQL 中的 Join 基本实现原理）。当 Join Buffer 太小，MySQL 不会将该 Buffer 存入磁盘文件，而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作，然后清空 Join Buffer 中的数据，继续将剩余的结果集写入此 Buffer 中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加 IO 访问，降低效率。

顺序读取数据缓冲区使用内存(read_buffer_size)：这部分内存主要用于当需要顺序读取数据的时候，如无发使用索引的情况下的全表扫描，全索引扫描等。在这种时候，MySQL 按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，当 buffer 空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。

随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相对应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。总的来说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL 就需要产生随机读取，进而使用到 read_rnd_buffer_size 参数所设置的内存缓冲区。

连接信息及返回客户端前结果集暂存使用内存(net_buffer_size)：这部分用来存放客户端连接线程的连接信息和返回客户端的结果集。当 MySQL 开始产生可以返回的结果集，会在通过网络返回给客户端请求线程之前，会先暂存在通过 net_buffer_size 所设置的缓冲区中，等满足一定大小的时候才开始向客户端发送，以提高网络传输效率。不过，net_buffer_size 参数所设置的仅仅只是该缓存区的初始化大小，MySQL 会根据实际需要自行申请更多的内存以满足需求，但最大不会超过 max_allowed_packet 参数大小。

批量插入暂存使用内存(bulk_insert_buffer_size)：当我们使用如 insert … values(…),(…),(…)… 的方式进行批量插入的时候，MySQL 会先将提交的数据放如一个缓存空间中，当该缓存空间被写满或者提交完所有数据之后，MySQL 才会一次性将该缓存空间中的数据写入数据库并清空缓存。此外，当我们进行 LOAD DATA INFILE 操作来将文本文件中的数据 Load 进数据库的时候，同样会使用到此缓冲区。

临时表使用内存(tmp_table_size)：当我们进行一些特殊操作如需要使用临时表才能完成的 Order By，Group By 等等，MySQL 可能需要使用到临时表。当我们的临时表较小（小于 tmp_table_size 参数所设置的大小）的时候，MySQL 会将临时表创建成内存临时表，只有当 tmp_table_size 所设置的大小无法装下整个临时表的时候，MySQL 才会将该表创建成 MyISAM 存储引擎的表存放在磁盘上。不过，当另一个系统参数 max_heap_table_size 的大小还小于 tmp_table_size 的时候，MySQL 将使用 max_heap_table_size 参数所设置大小作为最大的内存临时表大小，而忽略 tmp_table_size 所设置的值。而且 tmp_table_size 参数从 MySQL 5.1.2 才开始有，之前一直使用 max_heap_table_size。

上面所列举的 MySQL 线程独享内存仅仅只是所有线程独享内存中的部分，并不是全部，选择的原则是可能对 MySQL 的性能产生较大的影响，且可以通过系统参数进行调节。

由于以上内存都是线程独享，极端情况下的内存总体使用量将是所有连接线程的总倍数。所以各位朋友在设置过程中一定要谨慎，切不可为了提升性能就盲目的增大各参数值，避免因为内存不够而产生 Out Of Memory 异常或者是严重的 Swap 交换反而降低整体性能。

作者：Sky.Jian
链接：http://www.jianzhaoyang.com/database/mysql-memory-thread-private

以前写过个4.0的，现在机器上都是5.0的了，也不知道兼容不兼容4.0的参数，所以干脆看着help重新写了个

我这的环境都是gbk所以下面是以gbk为例子
导出：

1

mysqldump --user="xxx" --password="xxx" --force --quick --skip-opt --create-options --add-drop-table --default-character-set=gbk db1 >db1.sql

其中–force 代表忽略错误，如果导出的数据要导入mysql 4.0的话加个参数–compatible=mysql40

导入：

1

mysql -u"xxx" -p"xxx" --default-character-set=gbk db1 <db1.sql

参数篇

作/译者：吴炳锡，来源：http://imysql.cn　＆　http://imysql.cn/blog/3208　转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

介绍：
　　InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。
　Innodb 的创始人：Heikki Tuuri
　Heikki Tuuri在Ｉｎｎｏｄｂ的Ｂｕｇ社区里也是很活跃的，如果遇到Ｂｕｇ也可以直接提到社区，得到作者的解答。

为什么要学习Ｉｎｎｏｄｂ的调优：
　　目前来说：InnoDB是为Mysql处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。在数据量大的网站或是应用中Innodb是倍受青睐的。
　　另一方面，在数据库的复制操作中Innodb也是能保证master和slave数据一致有一定的作用。

参数调优内容：
　　1. 内存利用方面
　　2. 日值控制方面
　　3.　文件IO分配，空间占用方面
　　4. 其它相关参数

１.内存利用方面：
首先介绍一个Innodb最重要的参数：
innodb_buffer_pool_size
　　这个参数和MyISAM的key_buffer_size有相似之处，但也是有差别的。这个参数主要缓存innodb表的索引，数据，插入数据时的缓冲。为Innodb加速优化首要参数。
　　该参数分配内存的原则：这个参数默认分配只有8M，可以说是非常小的一个值。如果是一个专用ＤＢ服务器，那么他可以占到内存的70%-80%。这个参数不能动态更改，所以分配需多考虑。分配过大，会使Swap占用过多，致使Mysql的查询特慢。如果你的数据比较小，那么可分配是你的数据大小＋１０％左右做为这个参数的值。例如：数据大小为５０Ｍ,那么给这个值分配innodb_buffer_pool_size＝６４Ｍ
设置方法：
innodb_buffer_pool_size=4G
这个参数分配值的使用情况可以根据show innodb status\G;中的
———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 4668764894;
去确认使用情况。

第二个：
innodb_additional_mem_pool：
作用：用来存放Innodb的内部目录
这个值不用分配太大，系统可以自动调。不用设置太高。通常比较大数据设置16Ｍ够用了，如果表比较多，可以适当的增大。如果这个值自动增加，会在error log有中显示的。
分配原则：
用show innodb status\G;去查看运行中的ＤＢ是什么状态（参考BUFFER POOL AND MEMORY段中），然后可以调整到适当的值。
———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 4668764894; in additional pool allocated 16777216
参考：in additional pool allocated 16777216
根据你的参数情况，可以适当的调整。
设置方法：
innodb_additional_mem_pool=16M

２.关于日值方面：
innodb_log_file_size
作用：指定日值的大小
分配原则：几个日值成员大小加起来差不多和你的innodb_buffer_pool_size相等。上限为每个日值上限大小为4G.一般控制在几个ＬＯＧ文件相加大小在２Ｇ以内为佳。具体情况还需要看你的事务大小，数据大小为依据。
说明：这个值分配的大小和数据库的写入速度，事务大小，异常重启后的恢复有很大的关系。
设置方法：
innodb_log_file_size=256M

innodb_log_files_in_group
作用：指定你有几个日值组。
分配原则：　一般我们可以用２－３个日值组。默认为两个。
设置方法：
innodb_log_files_in_group=3

innodb_log_buffer_size：
作用：事务在内存中的缓冲。
分配原则：控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Ｏｒａｃｌｅ等数据库了解这个，一般最大指定为３Ｍ比较合适。
参考：Innodb_os_log_written(show global status 可以拿到)
如果这个值增长过快，可以适当的增加innodb_log_buffer_size
另外如果你需要处理大理的ＴＥＸＴ，或是ＢＬＯＢ字段，可以考虑增加这个参数的值。
设置方法：
innodb_log_buffer_size=3M

innodb_flush_logs_at_trx_commit
作用：控制事务的提交方式
分配原则：这个参数只有３个值，０，１，２请确认一下自已能接受的级别。默认为１，主库请不要更改了。
性能更高的可以设置为０或是２，但会丢失一秒钟的事务。
说明：
这个参数的设置对Ｉｎｎｏｄｂ的性能有很大的影响，所以在这里给多说明一下。
当这个值为1时：innodb 的事务LOG在每次提交后写入日值文件，并对日值做刷新到磁盘。这个可以做到不丢任何一个事务。
当这个值为2时：在每个提交，日志缓冲被写到文件，但不对日志文件做到磁盘操作的刷新,在对日志文件的刷新在值为2的情况也每秒发生一次。但需要注意的是，由于进程调用方面的问题，并不能保证每秒１００％的发生。从而在性能上是最快的。但操作系统崩溃或掉电才会删除最后一秒的事务。
当这个值为0时：日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。mysqld进程的崩溃会删除崩溃前最后一秒的事务。

从以上分析，当这个值不为１时，可以取得较好的性能，但遇到异常会有损失，所以需要根据自已的情况去衡量。

设置方法：
innodb_flush_logs_at_trx_commit=1

3.　文件IO分配，空间占用方面
innodb_file_per_table
作用：使每个Innodb的表，有自已独立的表空间。如删除文件后可以回收那部分空间。
分配原则：只有使用不使用。但ＤＢ还需要有一个公共的表空间。
设置方法：
innodb_file_per_table=1

innodb_file_io_threads
作用：文件读写ＩＯ数，这个参数只在Windows上起作用。在LINUX上只会等于４
设置方法：
innodb_file_io_threads=4

innodb_open_files
作用：限制Innodb能打开的表的数据。
分配原则：如果库里的表特别多的情况，请增加这个。这个值默认是３００。
设置方法：
innodb_open_files=800
请适当的增加table_cache

4. 其它相关参数
这里说明一个比较重要的参数：
innodb_flush_method
作用：Ｉｎｎｏｄｂ和系统打交道的一个ＩＯ模型
分配原则：Windows不用设置。
Ｕｎｉｘ可以设置：fsync() or O_SYNC/O_DSYNC
如果系统可以禁止系统的Ｃａｃｈｅ那就把他禁了。
Ｌｉｎｕｘ可以选择：O_DIRECT
直接写入磁盘，禁止系统Ｃａｃｈｅ了
设置方法：
innodb_flush_method=O_DIRECT

innodb_max_dirty_pages_pct
作用：控制Innodb的脏页在缓冲中在那个百分比之下，值在范围1-100,默认为90.
这个参数的另一个用处：当Ｉｎｎｏｄｂ的内存分配过大，致使Ｓｗａｐ占用严重时，可以适当的减小调整这个值，使达到Ｓｗａｐ空间释放出来。建义：这个值最大在９０％，最小在１５％。太大，缓存中每次更新需要致换数据页太多，太小，放的数据页太小，更新操作太慢。
设置方法：
innodb_max_dirty_pages_pct＝90
动态更改需要有Ｓｕｐｅｒ权限：
set global innodb_max_dirty_pages_pct=50;

总结：
　　这里只算是列出了Ｉｎｎｏｄｂ部分的重要参数，不能认为是对Ｍｙｓｑｌ的整体调优。Ｍｙｓｑｌ的参数一般分为：全局参数，具体引擎的参数。全局参数方面请参考http://imysql.cn/2007_12_08_optimize_mysql_under_linux yejr的那个Ｍｙｓｑｌ调优的ＰＰＴ。

看了http://item.feedsky.com/~feedsky/phpv/~1232318/176981487/1235221/1/item.html
的这篇文章，整理了下觉得这些对我很有帮助，记录一下

MySQL的字符集处理是这样的：

1）发送请求
客户端(character_set_client）=》数据库连接(character_set_connection)=》存储(table,column)
2）返回请求
存储(table,column)=》数据库连接(character_set_connection )=》客户端(character_set_results)

在每一个非初始节点，都会做一次从上一个结点到当前节点的字符集转换操作。举个例子，有如下环境：
* character_set_connection utf-8
* character_set_results gbk
* character_set_client gb2312
* 有表A，字段字符集全部为BIG5

发送请求的时候，首先数据从gbk转换为utf-8，再转换为BIG5，然后再存储。
返回请求的时候，首先数据从BIG5转换为utf-8，再转换为gb2312，然后再发送给客户端。

如果完全不需要对数据进行排序，like或者全文检索，那么请停止使用char，varchar，text之类的吧。 binary，varbinary，BLOB才是正确的选择。binary之类的在存储，取出的时候都不会进行字符集转换，而在排序时候，只根据二进制内 容排序，所以在效率上高出char，varchar，text很多

另外提一下PHP里的设置字符集。大家请不要再使用mysql_query(”set names utf8″)这样的语句了。mysql_set_charset()才 是最完整的字符集设置方式。后者比前者多一个设置，就是把struct MySQL的charset成员也设置了。这个成员变量在escape的时候起着很重要的作用，特别是对于GBK这种运行把“\”作为字符一部分的编码格式。如果你只使用mysql_query(”set names XXX”)，那么在某些字符集，会有重大的安全漏洞，导致mysql_real_escape_string变得和addslashes一样不安全。

从 hi!admin 抄来的一份配置.注释得非常好.

#BEGIN CONFIG INFO
#DESCR: 4GB RAM, 只使用InnoDB, ACID, 少量的连接, 队列负载大
#TYPE: SYSTEM
#END CONFIG INFO

#
# 此mysql配置文件例子针对4G内存
# 主要使用INNODB
#处理复杂队列并且连接数量较少的mysql服务器
#
# 将此文件复制到/etc/my.cnf 作为全局设置,
# mysql-data-dir/my.cnf 作为服务器指定设置
# (@localstatedir@ for this installation) 或者放入
# ~/.my.cnf 作为用户设置.
#
# 在此配置文件中, 你可以使用所有程序支持的长选项.
# 如果想获悉程序支持的所有选项
# 请在程序后加上”–help”参数运行程序.
#
# 关于独立选项更多的细节信息可以在手册内找到
#

#
# 以下选项会被MySQL客户端应用读取.
# 注意只有MySQL附带的客户端应用程序保证可以读取这段内容.
# 如果你想你自己的MySQL应用程序获取这些值
# 需要在MySQL客户端库初始化的时候指定这些选项

#
[client]
#password = [your_password]
port = @MYSQL_TCP_PORT@
socket = @MYSQL_UNIX_ADDR@

# *** 应用定制选项 ***

#
# MySQL 服务端
#
[mysqld]

# 一般配置选项
port = @MYSQL_TCP_PORT@
socket = @MYSQL_UNIX_ADDR@

# back_log 是操作系统在监听队列中所能保持的连接数,
# 队列保存了在MySQL连接管理器线程处理之前的连接.
# 如果你有非常高的连接率并且出现”connection refused” 报错,
# 你就应该增加此处的值.
# 检查你的操作系统文档来获取这个变量的最大值.
# 如果将back_log设定到比你操作系统限制更高的值,将会没有效果
back_log = 50

# 不在TCP/IP端口上进行监听.
# 如果所有的进程都是在同一台服务器连接到本地的mysqld,
# 这样设置将是增强安全的方法
# 所有mysqld的连接都是通过Unix sockets 或者命名管道进行的.
# 注意在windows下如果没有打开命名管道选项而只是用此项
# (通过 “enable-named-pipe” 选项) 将会导致mysql服务没有任何作用!
#skip-networking

# MySQL 服务所允许的同时会话数的上限
# 其中一个连接将被SUPER权限保留作为管理员登录.
# 即便已经达到了连接数的上限.
max_connections = 100

# 每个客户端连接最大的错误允许数量,如果达到了此限制.
# 这个客户端将会被MySQL服务阻止直到执行了”FLUSH HOSTS” 或者服务重启
# 非法的密码以及其他在链接时的错误会增加此值.
# 查看 “Aborted_connects” 状态来获取全局计数器.
max_connect_errors = 10

# 所有线程所打开表的数量.
# 增加此值就增加了mysqld所需要的文件描述符的数量
# 这样你需要确认在[mysqld_safe]中 “open-files-limit” 变量设置打开文件数量允许至少4096
table_cache = 2048

# 允许外部文件级别的锁. 打开文件锁会对性能造成负面影响
# 所以只有在你在同样的文件上运行多个数据库实例时才使用此选项(注意仍会有其他约束!)
# 或者你在文件层面上使用了其他一些软件依赖来锁定MyISAM表
#external-locking

# 服务所能处理的请求包的最大大小以及服务所能处理的最大的请求大小(当与大的BLOB字段一起工作时相当必要)
# 每个连接独立的大小.大小动态增加
max_allowed_packet = 16M

# 在一个事务中binlog为了记录SQL状态所持有的cache大小
# 如果你经常使用大的,多声明的事务,你可以增加此值来获取更大的性能.
# 所有从事务来的状态都将被缓冲在binlog缓冲中然后在提交后一次性写入到binlog中
# 如果事务比此值大, 会使用磁盘上的临时文件来替代.
# 此缓冲在每个连接的事务第一次更新状态时被创建
binlog_cache_size = 1M

# 独立的内存表所允许的最大容量.
# 此选项为了防止意外创建一个超大的内存表导致永尽所有的内存资源.
max_heap_table_size = 64M

# 排序缓冲被用来处理类似ORDER BY以及GROUP BY队列所引起的排序
# 如果排序后的数据无法放入排序缓冲,
# 一个用来替代的基于磁盘的合并分类会被使用
# 查看 “Sort_merge_passes” 状态变量.
# 在排序发生时由每个线程分配
sort_buffer_size = 8M

# 此缓冲被使用来优化全联合(full JOINs 不带索引的联合).
# 类似的联合在极大多数情况下有非常糟糕的性能表现,
# 但是将此值设大能够减轻性能影响.
# 通过 “Select_full_join” 状态变量查看全联合的数量
# 当全联合发生时,在每个线程中分配
join_buffer_size = 8M

# 我们在cache中保留多少线程用于重用
# 当一个客户端断开连接后,如果cache中的线程还少于thread_cache_size,
# 则客户端线程被放入cache中.
# 这可以在你需要大量新连接的时候极大的减少线程创建的开销
# (一般来说如果你有好的线程模型的话,这不会有明显的性能提升.)
thread_cache_size = 8

# 此允许应用程序给予线程系统一个提示在同一时间给予渴望被运行的线程的数量.
# 此值只对于支持 thread_concurrency() 函数的系统有意义( 例如Sun Solaris).
# 你可可以尝试使用 [CPU数量]*(2..4) 来作为thread_concurrency的值
thread_concurrency = 8

# 查询缓冲常被用来缓冲 SELECT 的结果并且在下一次同样查询的时候不再执行直接返回结果.
# 打开查询缓冲可以极大的提高服务器速度, 如果你有大量的相同的查询并且很少修改表.
# 查看 “Qcache_lowmem_prunes” 状态变量来检查是否当前值对于你的负载来说是否足够高.
# 注意: 在你表经常变化的情况下或者如果你的查询原文每次都不同,
# 查询缓冲也许引起性能下降而不是性能提升.
query_cache_size = 64M

# 只有小于此设定值的结果才会被缓冲
# 此设置用来保护查询缓冲,防止一个极大的结果集将其他所有的查询结果都覆盖.
query_cache_limit = 2M

# 被全文检索索引的最小的字长.
# 你也许希望减少它,如果你需要搜索更短字的时候.
# 注意在你修改此值之后,
# 你需要重建你的 FULLTEXT 索引
ft_min_word_len = 4

# 如果你的系统支持 memlock() 函数,你也许希望打开此选项用以让运行中的mysql在在内存高度紧张的时候,数据在内存中保持锁定并且防止可能被swapping out
# 此选项对于性能有益
#memlock

# 当创建新表时作为默认使用的表类型,
# 如果在创建表示没有特别执行表类型,将会使用此值
default_table_type = MYISAM

# 线程使用的堆大小. 此容量的内存在每次连接时被预留.
# MySQL 本身常不会需要超过64K的内存
# 如果你使用你自己的需要大量堆的UDF函数
# 或者你的操作系统对于某些操作需要更多的堆,
# 你也许需要将其设置的更高一点.
thread_stack = 192K

# 设定默认的事务隔离级别.可用的级别如下:
# READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE
transaction_isolation = REPEATABLE-READ

# 内部(内存中)临时表的最大大小
# 如果一个表增长到比此值更大,将会自动转换为基于磁盘的表.
# 此限制是针对单个表的,而不是总和.
tmp_table_size = 64M

# 打开二进制日志功能.
# 在复制(replication)配置中,作为MASTER主服务器必须打开此项
# 如果你需要从你最后的备份中做基于时间点的恢复,你也同样需要二进制日志.
log-bin=mysql-bin

# 如果你在使用链式从服务器结构的复制模式 (A->B->C),
# 你需要在服务器B上打开此项.
# 此选项打开在从线程上重做过的更新的日志,
# 并将其写入从服务器的二进制日志.
#log_slave_updates

# 打开全查询日志. 所有的由服务器接收到的查询 (甚至对于一个错误语法的查询)
# 都会被记录下来. 这对于调试非常有用, 在生产环境中常常关闭此项.
#log

# 将警告打印输出到错误log文件. 如果你对于MySQL有任何问题
# 你应该打开警告log并且仔细审查错误日志,查出可能的原因.
#log_warnings

# 记录慢速查询. 慢速查询是指消耗了比 “long_query_time” 定义的更多时间的查询.
# 如果 log_long_format 被打开,那些没有使用索引的查询也会被记录.
# 如果你经常增加新查询到已有的系统内的话. 一般来说这是一个好主意,
log_slow_queries

# 所有的使用了比这个时间(以秒为单位)更多的查询会被认为是慢速查询.
# 不要在这里使用”1″, 否则会导致所有的查询,甚至非常快的查询页被记录下来(由于MySQL 目前时间的精确度只能达到秒的级别).
long_query_time = 2

# 在慢速日志中记录更多的信息.
# 一般此项最好打开.
# 打开此项会记录使得那些没有使用索引的查询也被作为到慢速查询附加到慢速日志里
log_long_format

# 此目录被MySQL用来保存临时文件.例如,
# 它被用来处理基于磁盘的大型排序,和内部排序一样.
# 以及简单的临时表.
# 如果你不创建非常大的临时文件,将其放置到 swapfs/tmpfs 文件系统上也许比较好
# 另一种选择是你也可以将其放置在独立的磁盘上.
# 你可以使用”;”来放置多个路径
# 他们会按照roud-robin方法被轮询使用.
#tmpdir = /tmp

# *** 复制有关的设置

# 唯一的服务辨识号,数值位于 1 到 2^32-1之间.
# 此值在master和slave上都需要设置.
# 如果 “master-host” 没有被设置,则默认为1, 但是如果忽略此选项,MySQL不会作为master生效.
server-id = 1

# 复制的Slave (去掉master段的注释来使其生效)
#
# 为了配置此主机作为复制的slave服务器,你可以选择两种方法:
#
# 1) 使用 CHANGE MASTER TO 命令 (在我们的手册中有完整描述) -
# 语法如下:
#
# CHANGE MASTER TO MASTER_HOST=, MASTER_PORT= ,
# MASTER_USER=, MASTER_PASSWORD= ;
#
# 你需要替换掉 , , 等被尖括号包围的字段以及使用master的端口号替换 (默认3306).
#
# 例子:
#
# CHANGE MASTER TO MASTER_HOST=’125.564.12.1′, MASTER_PORT=3306,
# MASTER_USER=’joe’, MASTER_PASSWORD=’secret’;
#
# 或者
#
# 2) 设置以下的变量. 不论如何, 在你选择这种方法的情况下, 然后第一次启动复制(甚至不成功的情况下,
# 例如如果你输入错密码在master-password字段并且slave无法连接),
# slave会创建一个 master.info 文件,并且之后任何对于包含在此文件内的参数的变化都会被忽略
# 并且由 master.info 文件内的内容覆盖, 除非你关闭slave服务, 删除 master.info 并且重启slave 服务.
# 由于这个原因,你也许不想碰一下的配置(注释掉的) 并且使用 CHANGE MASTER TO (查看上面) 来代替
#
# 所需要的唯一id号位于 2 和 2^32 – 1之间
# (并且和master不同)
# 如果master-host被设置了.则默认值是2
# 但是如果省略,则不会生效
#server-id = 2
#
# 复制结构中的master – 必须
#master-host =
#
# 当连接到master上时slave所用来认证的用户名 – 必须
#master-user =
#
# 当连接到master上时slave所用来认证的密码 – 必须
#master-password = #
# master监听的端口.
# 可选 – 默认是3306
#master-port =

# 使得slave只读.只有用户拥有SUPER权限和在上面的slave线程能够修改数据.
# 你可以使用此项去保证没有应用程序会意外的修改slave而不是master上的数据
#read_only

#*** MyISAM 相关选项

# 关键词缓冲的大小, 一般用来缓冲MyISAM表的索引块.
# 不要将其设置大于你可用内存的30%,
# 因为一部分内存同样被OS用来缓冲行数据
# 甚至在你并不使用MyISAM 表的情况下, 你也需要仍旧设置起 8-64M 内存由于它同样会被内部临时磁盘表使用.
key_buffer_size = 32M

# 用来做MyISAM表全表扫描的缓冲大小.
# 当全表扫描需要时,在对应线程中分配.
read_buffer_size = 2M

# 当在排序之后,从一个已经排序好的序列中读取行时,行数据将从这个缓冲中读取来防止磁盘寻道.
# 如果你增高此值,可以提高很多ORDER BY的性能.
# 当需要时由每个线程分配
read_rnd_buffer_size = 16M

# MyISAM 使用特殊的类似树的cache来使得突发插入
# (这些插入是,INSERT … SELECT, INSERT … VALUES (…), (…), …, 以及 LOAD DATA
# INFILE) 更快. 此变量限制每个进程中缓冲树的字节数.
# 设置为 0 会关闭此优化.
# 为了最优化不要将此值设置大于 “key_buffer_size”.
# 当突发插入被检测到时此缓冲将被分配.
bulk_insert_buffer_size = 64M

# 此缓冲当MySQL需要在 REPAIR, OPTIMIZE, ALTER 以及 LOAD DATA INFILE 到一个空表中引起重建索引时被分配.
# 这在每个线程中被分配.所以在设置大值时需要小心.
myisam_sort_buffer_size = 128M

# MySQL重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
# 如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)
myisam_max_sort_file_size = 10G

# 如果被用来更快的索引创建索引所使用临时文件大于制定的值,那就使用键值缓冲方法.
# 这主要用来强制在大表中长字串键去使用慢速的键值缓冲方法来创建索引.
myisam_max_extra_sort_file_size = 10G

# 如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.
# 这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.
myisam_repair_threads = 1

# 自动检查和修复没有适当关闭的 MyISAM 表.
myisam_recover

# 默认关闭 Federated
skip-federated

# *** BDB 相关选项 ***

# 如果你运行的MySQL服务有BDB支持但是你不准备使用的时候使用此选项. 这会节省内存并且可能加速一些事.
skip-bdb

# *** INNODB 相关选项 ***

# 如果你的MySQL服务包含InnoDB支持但是并不打算使用的话,
# 使用此选项会节省内存以及磁盘空间,并且加速某些部分
#skip-innodb

# 附加的内存池被InnoDB用来保存 metadata 信息
# 如果InnoDB为此目的需要更多的内存,它会开始从OS这里申请内存.
# 由于这个操作在大多数现代操作系统上已经足够快, 你一般不需要修改此值.
# SHOW INNODB STATUS 命令会显示当先使用的数量.
innodb_additional_mem_pool_size = 16M

# InnoDB使用一个缓冲池来保存索引和原始数据, 不像 MyISAM.
# 这里你设置越大,你在存取表里面数据时所需要的磁盘I/O越少.
# 在一个独立使用的数据库服务器上,你可以设置这个变量到服务器物理内存大小的80%
# 不要设置过大,否则,由于物理内存的竞争可能导致操作系统的换页颠簸.
# 注意在32位系统上你每个进程可能被限制在 2-3.5G 用户层面内存限制,
# 所以不要设置的太高.
innodb_buffer_pool_size = 2G

# InnoDB 将数据保存在一个或者多个数据文件中成为表空间.
# 如果你只有单个逻辑驱动保存你的数据,一个单个的自增文件就足够好了.
# 其他情况下.每个设备一个文件一般都是个好的选择.
# 你也可以配置InnoDB来使用裸盘分区 – 请参考手册来获取更多相关内容
innodb_data_file_path = ibdata1:10M:autoextend

# 设置此选项如果你希望InnoDB表空间文件被保存在其他分区.
# 默认保存在MySQL的datadir中.
#innodb_data_home_dir =

# 用来同步IO操作的IO线程的数量. This value is
# 此值在Unix下被硬编码为4,但是在Windows磁盘I/O可能在一个大数值下表现的更好.
innodb_file_io_threads = 4

# 如果你发现InnoDB表空间损坏, 设置此值为一个非零值可能帮助你导出你的表.
# 从1开始并且增加此值知道你能够成功的导出表.
#innodb_force_recovery=1

# 在InnoDb核心内的允许线程数量.
# 最优值依赖于应用程序,硬件以及操作系统的调度方式.
# 过高的值可能导致线程的互斥颠簸.
innodb_thread_concurrency = 16

# 如果设置为1 ,InnoDB会在每次提交后刷新(fsync)事务日志到磁盘上,
# 这提供了完整的ACID行为.
# 如果你愿意对事务安全折衷, 并且你正在运行一个小的食物, 你可以设置此值到0或者2来减少由事务日志引起的磁盘I/O
# 0代表日志只大约每秒写入日志文件并且日志文件刷新到磁盘.
# 2代表日志写入日志文件在每次提交后,但是日志文件只有大约每秒才会刷新到磁盘上.
innodb_flush_log_at_trx_commit = 1

# 加速InnoDB的关闭. 这会阻止InnoDB在关闭时做全清除以及插入缓冲合并.
# 这可能极大增加关机时间, 但是取而代之的是InnoDB可能在下次启动时做这些操作.
#innodb_fast_shutdown

# 用来缓冲日志数据的缓冲区的大小.
# 当此值快满时, InnoDB将必须刷新数据到磁盘上.
# 由于基本上每秒都会刷新一次,所以没有必要将此值设置的太大(甚至对于长事务而言)

innodb_log_buffer_size = 8M

# 在日志组中每个日志文件的大小.
# 你应该设置日志文件总合大小到你缓冲池大小的25%~100%
# 来避免在日志文件覆写上不必要的缓冲池刷新行为.
# 不论如何, 请注意一个大的日志文件大小会增加恢复进程所需要的时间.
innodb_log_file_size = 256M

# 在日志组中的文件总数.
# 通常来说2~3是比较好的.
innodb_log_files_in_group = 3

# InnoDB的日志文件所在位置. 默认是MySQL的datadir.
# 你可以将其指定到一个独立的硬盘上或者一个RAID1卷上来提高其性能
#innodb_log_group_home_dir

# 在InnoDB缓冲池中最大允许的脏页面的比例.
# 如果达到限额, InnoDB会开始刷新他们防止他们妨碍到干净数据页面.
# 这是一个软限制,不被保证绝对执行.
innodb_max_dirty_pages_pct = 90

# InnoDB用来刷新日志的方法.
# 表空间总是使用双重写入刷新方法
# 默认值是 “fdatasync”, 另一个是 “O_DSYNC”.
#innodb_flush_method=O_DSYNC

# 在被回滚前,一个InnoDB的事务应该等待一个锁被批准多久.
# InnoDB在其拥有的锁表中自动检测事务死锁并且回滚事务.
# 如果你使用 LOCK TABLES 指令, 或者在同样事务中使用除了InnoDB以外的其他事务安全的存储引擎
# 那么一个死锁可能发生而InnoDB无法注意到.
# 这种情况下这个timeout值对于解决这种问题就非常有帮助.
innodb_lock_wait_timeout = 120

[mysqldump]
# 不要在将内存中的整个结果写入磁盘之前缓存. 在导出非常巨大的表时需要此项
quick

max_allowed_packet = 16M

[mysql]
no-auto-rehash

# 仅仅允许使用键值的 UPDATEs 和 DELETEs .
#safe-updates

[isamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[myisamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
# 增加每个进程的可打开文件数量.
# 警告: 确认你已经将全系统限制设定的足够高!
# 打开大量表需要将此值设高
open-files-limit = 8192

今天在把博客的系统换成64位装mysql时提示：
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
之前装32位习惯了yum -y install compat-libstdc++-33 后发现还是这样，才想起来是64位
重新yum -y install compat-libstdc++-33.x86_64 在安装就ok了
所以安装64位系统这些lib库可留心下把64位的也装了。

原文地址：http://www.chedong.com/blog/archives/001451.html
官网：https://launchpad.net/mysql-tuning-primer
加path那段我自己写的，不然报错跟输错密码一样，郁闷的让我想了半天密码

年初的时候收藏过一篇关于mysqlreport的报表解读，和内置的show status,和show variables相比mysqlreport输出一个可读性更好的报表；但Sundry MySQL提供的脚本相比mysqlreport更进一步：除了报表还进一步提供了修改建议。安装和使用非常简单：

wget http://www.day32.com/MySQL/tuning-primer.sh
chmod +x tuning-primer.sh

先要把mysql的bin目录加进path

export PATH=/usr/local/mysql/bin:$PATH

./tuning-primer.sh

然后根据提示看把，按照问题重要程度分别用黄色/红色字符标记问题

最近迁移的机器多了，碰到的问题也就多。这个pureftpd+mysql就把我折腾了1天
症状就是登陆ftp后输完用户名和密码，ftp链接立刻就断开了
[00:14:19] [R] 正在连接到 10.130.128.146 -> IP=10.130.128.146 PORT=21 (次尝试 # 5)
[00:14:19] [R] 已连接到 10.130.128.146
[00:14:19] [R] 220---------- Welcome to Pure-FTPd ----------
[00:14:19] [R] 220-You are user number 1 of 25 allowed.
[00:14:19] [R] 220-Local time is now 00:13. Server port: 21.
[00:14:19] [R] 220-This is a private system - No anonymous login
[00:14:19] [R] 220 You will be disconnected after 15 minutes of inactivity.
[00:14:19] [R] USER user89
[00:14:19] [R] 331 User user89 OK. Password required
[00:14:19] [R] PASS (hidden)
[00:14:19] [R] 连接失败 (连接丢失)

注意这提示并非用户名密码错误。用户验证已经通过了。结果噩梦开始了，其实解决很简单，只要mysql里取出来的用户uid&gid和用户主目录的uid&gid对应就行。我一开始想到过这个问题，结果editplus里开了2个conf，我改的一个，结果上传的另一个….我的天，我晚上在家从头开始配的时候竟然犯了同样的错误，绕了一大圈弯路，最后关配置文件打算用puredb才发现这个问题。

具体修改pureftpd-mysql.conf
# Query to execute in order to fetch the system user name or uid
# MYSQLGetUID SELECT Uid FROM users WHERE User="\L"
# Optional : default UID - if set this overrides MYSQLGetUID
MYSQLDefaultUID 501
# Query to execute in order to fetch the system user group or gid
# MYSQLGetGID SELECT Gid FROM users WHERE User="\L"
# Optional : default GID - if set this overrides MYSQLGetGID
MYSQLDefaultGID 501

我这所有用户目录所有者都是www:www，所以对照下etc/passwd里面www的uid和gid直接定义了MYSQLDefaultUID和MYSQLDefaultGID。不取mysql的

这里推荐个不错的pureftpd教程
Pure-FTPd + LDAP + MySQL + PGSQL + Virtual-Users + Quota How To

http://netkiller.8800.org/article/ftpserver/

汗。。。看来最近迁移的服务器太多搞得头晕了，竟然是这种低级错误。看来国庆长假要好好休息了。

今天在做服务器搬迁，新的主机使用的mysql5.0，一开始直接把data目录复制了过去，结果发现所有char相关字段长度全部变成原来的一半。无奈只好用dump了
我这的环境都是gbk所以下面是以gbk为例子
导出：

1

mysqldump -u xxx -pxxx --skip-extended-insert --default-character-set=gbk db1 > d:\db1.sql

导入：

1

mysql.exe -u xxx -pxxx --default-character-set=gbk db1 < d:\db1.sql

由于4.0是没有编码设置，所以在新的5.0上面要设置mysql的conf把default-character-set=gbk，character-set-server=gbk

这样就能解决一般经常碰到的乱码问题了

当然导入过程中可能会有一些错误提示，根据提示修改下导出的sql文件就行。一般比如group这类特殊字段名要改成`group`才能正确导入到5.0。建议使用notepad++来编辑sql文件

Q：列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因？给一些必须在MYSQL中排序的实例？

A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：

• 1、 考虑整个网站的可伸缩性和整体性能，在应用层（PHP）中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB 很容易到瓶颈。
• 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
• 3、 PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效；
• 4、 PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗；
• 5、 PHP不存在表的锁定问题；
• 6、 MYSQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。

至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。

列出一些 PHP 中执行排序更优的情况：

• 1、 数据源不在 MYSQL 中，存在硬盘、内存或者来自网络的请求等；
• 2、 数据存在 MYSQL 中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快；
• 3、 数据源来自于多个 MYSQL 服务器，此时从多个 MYSQL 中取出数据，然后在PHP中排序更快；
• 4、 除了 MYSQL 之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入 MYSQL 后再排序；

列出一些必须在 MYSQL 中排序的实例：

• 1、 MYSQL 中已经存在这个排序的索引；
• 2、 MYSQL 中数据量较大，而结果集需要其中很小的一个子集；比如 1000000 行数据，取TOP 10；
• 3、 对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在 MYSQL 中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MYSQL即可，便于多次使用。
• 4、 不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache 的关系，不再适合 PHP 中排序了；此时把数据复制、导入或者存在 MYSQL ，并用 INDEX 优化，是优于 PHP 的。不过，用 Java，甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。]

从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。

–EOF–

之前做过一次论坛宠物的ORDER BY RAND()的优化，这篇文章只是深入的去读解优化的原理和具体步骤。觉得讲的不错分享一下。

原文地址：http://jan.kneschke.de/projects/mysql/order-by-rand

翻译：ShiningRay

译者序
之前有位朋友提到从MySQL随机取1条记录其实只要SELECT * FROM table ORDER BY RAND() LIMIT 1即可。其实这个语句有很大的性能问题，对于大表的效率是非常低下的。我们可以看一下MySQL对其的解释：

EXPLAIN SELECT *
FROM `money_logs`
ORDER BY RAND( )
LIMIT 1
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE table ALL NULL NULL NULL NULL 173784 Using temporary; Using filesort

这个SQL语句无法使用任何索引，还必须使用临时表和文件排序，在一个15万条记录的MyISAM表需要花大约0.3秒。已经是相当慢的了。如何优化，请往下看：

第一个例子我们先假设ID是从1开始并且1和ID的最大值之间没有任何空档。

将工作移入应用程序
第一个想法：如果我们可以事先在应用程序中计算出ID，那么就可以简化整个工作。

SELECT MAX(id) FROM random;
## 在应用程序中生成随机id
SELECT name FROM random WHERE id = 由于MAX(id) == COUNT(id) 我们只要生成从1到MAX(id)之间一个随机数，并将其传给数据库并取回随机行。

上面第一个SELECT基本上是一个可以被优化掉的空操作。第二个是一个针对常量的eq_ref查询，同样也很快。

将任务放入数据库
不过有必要将其放入应用程序吗？难道我们不能在数据库里完成？

# 生成一个随机 ID
> SELECT RAND() * MAX(id) FROM random;
+——————+
| RAND() * MAX(id) |
+——————+
| 689.37582507297 |
+——————+
# 喔，这是一个浮点数，不过我们需要整数

> SELECT CEIL(RAND() * MAX(id)) FROM random;
+————————-+
| CEIL(RAND() * MAX(id)) |
+————————-+
| 1000000 |
+————————-+
# 好多了。不过性能如何？

> EXPLAIN
SELECT CEIL(RAND() * MAX(id)) FROM random;
+—-+————-+——-+——-+——+————-+
| id | select_type | table | type | rows | Extra |
+—-+————-+——-+——-+——+————-+
| 1 | SIMPLE | random | index | 1000000 | Using index |
+—-+————-+——-+——-+——+————-+
## 一个索引扫描？我们没有对MAX()进行优化

> EXPLAIN
SELECT CEIL(RAND() * (SELECT MAX(id) FROM random));
+—-+————-+——-+——+——+——————————+
| id | select_type | table | type | rows | Extra |
+—-+————-+——-+——+——+——————————+
| 1 | PRIMARY | NULL | NULL | NULL | No tables used |
| 2 | SUBQUERY | NULL | NULL | NULL | Select tables optimized away |
+—-+————-+——-+——+——+——————————+
## 一个简单的子查询给我们将性能找了回来。OK，现在我们知道如何生成随机ID了，不过如何获取记录行？

> EXPLAIN
SELECT name
FROM random
WHERE id = (SELECT CEIL(RAND() *
(SELECT MAX(id)
FROM random));
+—-+————-+——–+——+—————+——+———+——+———+——————————+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+——+—————+——+———+——+———+——————————+
| 1 | PRIMARY | random | ALL | NULL | NULL | NULL | NULL | 1000000 | Using where |
| 3 | SUBQUERY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away |
+—-+————-+——–+——+—————+——+———+——+———+——————————+
> show warnings;
+——-+——+——————————————+
| Level | Code | Message |
+——-+——+——————————————+
| Note | 1249 | Select 2 was reduced during optimization |
+——-+——+——————————————+哦，不！不要走这条路。虽然它很直观，但是也是最容易犯的错。理由是：在WHERE子句中的SELECT会针对外部SELECT取出的每一行执行一次。这可能会是0到4091行，看你的运气了。

我们必须用一种方法确保随机ID只被生成一次：

SELECT name
FROM random JOIN
(SELECT CEIL(RAND() *
(SELECT MAX(id)
FROM random)) AS id
) AS r2
USING (id);
+—-+————-+————+——–+——+——————————+
| id | select_type | table | type | rows | Extra |
+—-+————-+————+——–+——+——————————+
| 1 | PRIMARY | | system | 1 | |
| 1 | PRIMARY | random | const | 1 | |
| 2 | DERIVED | NULL | NULL | NULL | No tables used |
| 3 | SUBQUERY | NULL | NULL | NULL | Select tables optimized away |
+—-+————-+————+——–+——+——————————+内部的 SELECT 生成了一个常数临时（TEMPORARY）表并且联接（JOIN）只选择了一行。完美。

没有排序、没有应用程序介入，查询的大部分都被优化了。

在数字中加入空档
为了使最终的解决方案通用化，我们必须考虑空档的可能性，如当你删除(DELETE)了记录行。

SELECT name
FROM random AS r1 JOIN
(SELECT (RAND() *
(SELECT MAX(id)
FROM random)) AS id)
AS r2
WHERE r1.id >= r2.id
ORDER BY r1.id ASC
LIMIT 1;
+—-+————-+————+——–+——+——————————+
| id | select_type | table | type | rows | Extra |
+—-+————-+————+——–+——+——————————+
| 1 | PRIMARY | | system | 1 | |
| 1 | PRIMARY | r1 | range | 689 | Using where |
| 2 | DERIVED | NULL | NULL | NULL | No tables used |
| 3 | SUBQUERY | NULL | NULL | NULL | Select tables optimized away |
+—-+————-+————+——–+——+——————————+JOIN现在加入了所有大于等于我们随机数的ID，并且当直接匹配不存在的时候，只选择最临近的记录。不过一旦找到了某一行，我们就立刻停止（LIMIT 1）。同时我们根据索引（ORDER BY id ASC）读取记录。由于我们使用了>=而非=，所以我们可以削去CEIL同时还能获取同样的结果，节省了一点点开销。

平均分布
一旦ID的分布不再是平均的了，那么我们对行的选择也不是完全随机的了。

> select * from holes;
+—-+———————————-+———-+
| id | name | accesses |
+—-+———————————-+———-+
| 1 | d12b2551c6cb7d7a64e40221569a8571 | 107 |
| 2 | f82ad6f29c9a680d7873d1bef822e3e9 | 50 |
| 4 | 9da1ed7dbbdcc6ec90d6cb139521f14a | 132 |
| 8 | 677a196206d93cdf18c3744905b94f73 | 230 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa | 481 |
+—-+———————————-+———-+RAND函数生成诸如9到15之间的ID都会让id 16被选择。

目前还没有针对这个问题的真正的解决方案，不过你的数据是大部分不变的话可以添加一个将行号映射到ID的映射表：

> create table holes_map ( row_id int not NULL primary key, random_id int not null);
> SET @id = 0;
> INSERT INTO holes_map SELECT @id := @id + 1, id FROM holes;
> select * from holes_map;
+——–+———–+
| row_id | random_id |
+——–+———–+
| 1 | 1 |
| 2 | 2 |
| 3 | 4 |
| 4 | 8 |
| 5 | 16 |
+——–+———–+row_id现在则是没有空档的，我们就可以再次运行我们的随机查询了：

SELECT name FROM holes
JOIN (SELECT r1.random_id
FROM holes_map AS r1
JOIN (SELECT (RAND() *
(SELECT MAX(row_id)
FROM holes_map)) AS row_id)
AS r2
WHERE r1.row_id >= r2.row_id
ORDER BY r1.row_id ASC
LIMIT 1) as rows ON (id = random_id);1000次查找之后，我们可以看到一个平均分布：

> select * from holes;
+—-+———————————-+———-+
| id | name | accesses |
+—-+———————————-+———-+
| 1 | d12b2551c6cb7d7a64e40221569a8571 | 222 |
| 2 | f82ad6f29c9a680d7873d1bef822e3e9 | 187 |
| 4 | 9da1ed7dbbdcc6ec90d6cb139521f14a | 195 |
| 8 | 677a196206d93cdf18c3744905b94f73 | 207 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa | 189 |
+—-+———————————-+———-+使用触发器维护有空档的表
让我们就用前面的几个表:

DROP TABLE IF EXISTS r2;
CREATE TABLE r2 (
id SERIAL,
name VARCHAR(32) NOT NULL UNIQUE
);

DROP TABLE IF EXISTS r2_equi_dist;
CREATE TABLE r2_equi_dist (
id SERIAL,
r2_id bigint unsigned NOT NULL UNIQUE
);
一旦我们在r2中改动了某些东西，我们希望r2_equi_dist也被更新。

DELIMITER $$
DROP TRIGGER IF EXISTS tai_r2$$
CREATE TRIGGER tai_r2
AFTER INSERT ON r2 FOR EACH ROW
BEGIN
DECLARE m BIGINT UNSIGNED DEFAULT 1;

SELECT MAX(id) + 1 FROM r2_equi_dist INTO m;
SELECT IFNULL(m, 1) INTO m;
INSERT INTO r2_equi_dist (id, r2_id) VALUES (m, NEW.id);
END$$
DELIMITER ;

DELETE FROM r2;

INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );

SELECT * FROM r2;
+—-+———————————-+
| id | name |
+—-+———————————-+
| 1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
| 2 | a09a3959d68187ce48f4fe7e388926a9 |
| 3 | 4e1897cd6d326f8079108292376fa7d5 |
| 4 | 29a5e3ed838db497aa330878920ec01b |
+—-+———————————-+
SELECT * FROM r2_equi_dist;
+—-+——-+
| id | r2_id |
+—-+——-+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
+—-+——-+
INSERT很简单，但在DELETE时我们需要更新equi-dist-id来维持id的连续。

DELIMITER $$
DROP TRIGGER IF EXISTS tad_r2$$
CREATE TRIGGER tad_r2
AFTER DELETE ON r2 FOR EACH ROW
BEGIN
DELETE FROM r2_equi_dist WHERE r2_id = OLD.id;
UPDATE r2_equi_dist SET id = id – 1 WHERE r2_id > OLD.id;
END$$
DELIMITER ;

DELETE FROM r2 WHERE id = 2;

SELECT * FROM r2;
+—-+———————————-+
| id | name |
+—-+———————————-+
| 1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
| 3 | 4e1897cd6d326f8079108292376fa7d5 |
| 4 | 29a5e3ed838db497aa330878920ec01b |
+—-+———————————-+
SELECT * FROM r2_equi_dist;
+—-+——-+
| id | r2_id |
+—-+——-+
| 1 | 1 |
| 2 | 3 |
| 3 | 4 |
+—-+——-+
UPDATE就非常直观了。我们只要维护一下外键约束：

DELIMITER $$
DROP TRIGGER IF EXISTS tau_r2$$
CREATE TRIGGER tau_r2
AFTER UPDATE ON r2 FOR EACH ROW
BEGIN
UPDATE r2_equi_dist SET r2_id = NEW.id WHERE r2_id = OLD.id;
END$$
DELIMITER ;

UPDATE r2 SET id = 25 WHERE id = 4;

SELECT * FROM r2;
+—-+———————————-+
| id | name |
+—-+———————————-+
| 1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
| 3 | 4e1897cd6d326f8079108292376fa7d5 |
| 25 | 29a5e3ed838db497aa330878920ec01b |
+—-+———————————-+
SELECT * FROM r2_equi_dist;
+—-+——-+
| id | r2_id |
+—-+——-+
| 1 | 1 |
| 2 | 3 |
| 3 | 25 |
+—-+——-+
一次多行
如果你想一次取回多行，你可以：

执行多次查询
写一个存储过程执行查询并将结果存入一个临时表
进行一个UNION
存储过程
存储过程为你提供了通用语言中很有用的一些结构：

循环
控制结构
过程
…
这个任务中我们只需要一个LOOP:

DELIMITER $$
DROP PROCEDURE IF EXISTS get_rands$$
CREATE PROCEDURE get_rands(IN cnt INT)
BEGIN
DROP TEMPORARY TABLE IF EXISTS rands;
CREATE TEMPORARY TABLE rands ( rand_id INT );

loop_me: LOOP
IF cnt < 1 THEN
LEAVE loop_me;
END IF;

INSERT INTO rands
SELECT r1.id
FROM random AS r1 JOIN
(SELECT (RAND() *
(SELECT MAX(id)
FROM random)) AS id)
AS r2
WHERE r1.id >= r2.id
ORDER BY r1.id ASC
LIMIT 1;

SET cnt = cnt – 1;
END LOOP loop_me;
END$$
DELIMITER ;

CALL get_rands(4);
SELECT * FROM rands;
+———+
| rand_id |
+———+
| 133716 |
| 702643 |
| 112066 |
| 452400 |
+———+
下面的问题留给读者解决：

使用动态SQL并传入临时表的名字
在表上使用一个UNIQUE索引并捕获UNIQUE键冲突来消除结果集中可能的重复记录。
性能
现在让我们看看性能方面发生了什么变化。我们有三个不同的查询来解决这个问题。

Q1. ORDER BY RAND()
Q2. RAND() * MAX(ID)
Q3. RAND() * MAX(ID) + ORDER BY ID
Q1预期消耗N * log2(N)，Q2和Q3接近常数。

下标是评测的结果，针对N行的表（从一千行到一百万行），每个查询执行1000次。

100 1.000 10.000 100.000 1.000.000
Q1 0:00.718s 0:02.092s 0:18.684s 2:59.081s 58:20.000s
Q2 0:00.519s 0:00.607s 0:00.614s 0:00.628s 0:00.637s
Q3 0:00.570s 0:00.607s 0:00.614s 0:00.628s 0:00.637s如你所见，普通的ORDER BY RAND()从仅100行的表开始便落后于优化过的查询了。

关于这些查询更详细的分析可以在analyzing-complex-queries查阅.

本工具产生的配置文件仅作参考用途，对此带来的后果不符任何责任，请注意使用。

看这里

http://imysql.cn/my_cnf_generator

thread_concurrency
数量设置为CPU核心数量的两倍.
thread_cache_size
按照内存大小来设置, 1G=8, 2G=16, 3G=32, >3G=64
wait_timeout
超时时间,如果连接数比较大,可以减少此参数的值,我使用的是10
max_connections
最大连接数,mysql实际允许连接数的值是max_connections+1,按照系统库不同而有不同性能.一般是500~1000,MySQL AB提供的linux静态库可以达到4000.
query_cache_size
查询缓冲,默认是0,所以必须打开以提高mysql性能,其本身需要40K来保存结构数据.所以不能设置的太小,初期可以设置成32M,然后根据实际运行情况另行调整
query_cache_type
指定查询缓冲的类型,0是关闭,1是缓冲除了使用SELECT SQL_NO_CACHE语句指明了不需要缓冲的数据意外的所有查询,2是只缓冲SELECT SQL_CACHE指定的查询.一般设置为1.
query_cache_limit
允许进入查询缓冲区的最小数据大小,默认值是1MB,可以修改的小一点以满足更多查询的需求.但是如果设置的过于小,则会导致很多新的小查询的结果将原有的查询结果交换出去.增加系统的颠簸.

相关命令
查询mysql服务器相关状态数据
>SHOW STATUS;

查询mysql服务器相关配置选项
>SHOW VARIABLES;

整理查询缓冲区里的碎片
>flush query cache;

删除查询缓冲区里的所有内容
>reset query cache;

设置mysql参数
>SET GLOBAL;

查询mysql当前执行的sql语句
>show processlist;

变量 含义
Qcache_queries_in_cache
在缓存中已注册的查询数目
Qcache_inserts
被加入到缓存中的查询数目
Qcache_hits
缓存采样数数目
Qcache_lowmem_prunes
因为缺少内存而被从缓存中删除的查询数目
Qcache_not_cached
没有被缓存的查询数目 (不能被缓存的，或由于 QUERY_CACHE_TYPE)
Qcache_free_memory
查询缓存的空闲内存总数
Qcache_free_blocks
查询缓存中的空闲内存块的数目
Qcache_total_blocks
查询缓存中的块的总数目

MySQL查询优化
>SHOW STATUS LIKE ‘Qcache%’;
查询出Cache状态
如果Qcache_lowmem_prunes非常大,说明因为内存不足而被交换出cache的数据很多.如果增加内存.可以保证较小的交换次数以及较高的命中率
例如现在我们查询的结果如下

设置为64M cache内存后
>set global query_cache_size=67108864;

自由内存块看起来变小了
是因为现在自由内存块.是一个整块.而以前的内存块都是分散的小块
而因为重建了cache区
Qcache_queries_in_cache变量变小了.因为此操作重新建立了cache内存区.所有数据重新缓存
在运行一两天后我们再看此数据.如果变大了.说明增大cache内存区域是有效的.如果和以前数据差不多
说明增加的内存并没有实际起到多大的作用.

有人会觉得如果我将cache内存设置的非常大
然后将cache_limit设置成0
那么所有查询都会被缓存了
理论上是这样.但是一台数据库服务器的查询非常多.
如果连查询单条数据都要缓存.
那么内存再大也会不够的.到时候老的内容就会被交换出去
当cache内存使用满的时候,就会不停的有新查询进来将老查询替换出去.
这样导致两个结果.一个是内存颠簸.效率反而下降.
第二个是cache内存的小碎块增多,内存利用率降低
如果是只有内容很少的小库,并且查询率不高.是可以使用这种方法提高响应速度
但是如果是实际生产环境,数据量会比较大.还是需要按照最佳比例来配置.
而不同的应用不同的数据量会有不同的搭配,这点大家不要看网上的优化配置随便的填写
还是要时时的查看mysql的状态进行调整.即便是这个月调整好的优化参数
到了下个月业务不同,数据量增加,也会需要调整的.

随机取一条数据的一般来讲用SELECT * FROM `table` ORDER BY RAND() LIMIT 1是最方便的，但是order by rand()有个致命的缺点，就是表的索引完全没有作用，在高负载和表数据量大的情况下很容易把mysql拖死。最近在优化论坛无心宠物插件的时候一直卡在了order by rand()。

无心宠物在取怪的时候用了一条order by rand()来选取打怪的怪物。表的数据量不大，但是负载很高，在优化前mysql并发最低值不低于4000经常在5000-6000徘徊。在对sql语句：
select * from {$tablepre}wxnpcdata where (mapid=’$mapid’ and pktime<”.($timestamp-4).”)  or mapid=0 order by rand() limit 1

修改为

SELECT * FROM cdb_wxnpcdata AS t1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(npcid) FROM cdb_wxnpcdata where (mapid=’$mapid’ and pktime<”.($timestamp-4).”)  or mapid=0)-(SELECT MIN(npcid) FROM cdb_wxnpcdata where (mapid=’$mapid’ and pktime<”.($timestamp-4).”)  or mapid=0))+(SELECT MIN(npcid) FROM cdb_wxnpcdata where (mapid=’$mapid’ and pktime<”.($timestamp-4).”)  or mapid=0)) AS id) AS t2 WHERE t1.npcid >= t2.id and (mapid=’$mapid’ and pktime<”.($timestamp-4).”)  or mapid=0 ORDER BY t1.npcid LIMIT 1;

之后mysql负载立刻降到1800左右徘徊，最高2000出头。效果立杆见影

对应SELECT * FROM `table` ORDER BY RAND() LIMIT 1的修改方法是

SELECT *
FROM `table` AS t1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(id) FROM `table`)-(SELECT MIN(id) FROM `table`))+(SELECT MIN(id) FROM `table`)) AS id) AS t2
WHERE t1.id >= t2.id
ORDER BY t1.id LIMIT 1;

`平时上班基本没有定的下心的时候，晚上么时间不够，加上eswc很久没有双休了，今天终于有机会尝试了一下
环境：centos 5.1/apache 2.2.8/php 5.2.6/mysql 5.0.66a-enterprise-gpl
装了个干净的Discuz 6.1 关闭缓存 测试板块帖子列表显示页面 forumdisplay.php?fid=2&page=1

测试采用本机webbench
首先尝试关闭xcache和TCMalloc情况下的负载能力
采用1客户端10秒
webbench -c 1 -t 10 http://xxx/forumdisplay.php?fid=2\&page=1
成绩如下
Speed=1758 pages/min, 305745 bytes/sec.
Requests: 293 susceed, 0 failed.
Speed=1692 pages/min, 294267 bytes/sec.
Requests: 282 susceed, 0 failed.
Speed=1764 pages/min, 306789 bytes/sec.
Requests: 294 susceed, 0 failed.
Speed=1764 pages/min, 306789 bytes/sec.
Requests: 294 susceed, 0 failed.
Speed=1596 pages/min, 277571 bytes/sec.
Requests: 266 susceed, 0 failed.
 
采用5客户端10秒
webbench -c 5 -t 10 http://xxx/forumdisplay.php?fid=2\&page=1
成绩如下
Speed=2796 pages/min, 486271 bytes/sec.
Requests: 466 susceed, 0 failed.
Speed=3012 pages/min, 523837 bytes/sec.
Requests: 502 susceed, 0 failed.
Speed=2916 pages/min, 507141 bytes/sec.
Requests: 486 susceed, 0 failed.
Speed=2976 pages/min, 517576 bytes/sec.
Requests: 496 susceed, 0 failed.
Speed=2976 pages/min, 517576 bytes/sec.
Requests: 496 susceed, 0 failed.
 

下面只打开xcache和关闭TCMalloc情况下的负载能力
采用1客户端10秒
webbench -c 1 -t 10 http://xxx/forumdisplay.php?fid=2\&page=1
成绩如下
Speed=6270 pages/min, 1090457 bytes/sec.
Requests: 1045 susceed, 0 failed.
Speed=6216 pages/min, 1081066 bytes/sec.
Requests: 1036 susceed, 0 failed.
Speed=6222 pages/min, 1082109 bytes/sec.
Requests: 1037 susceed, 0 failed.
Speed=6318 pages/min, 1098805 bytes/sec.
Requests: 1053 susceed, 0 failed.
Speed=6012 pages/min, 1045587 bytes/sec.
Requests: 1002 susceed, 0 failed.

采用5客户端10秒
webbench -c 5 -t 10 http://xxx/forumdisplay.php?fid=2\&page=1
成绩如下
Speed=13368 pages/min, 2324918 bytes/sec.
Requests: 2228 susceed, 0 failed.
Speed=13992 pages/min, 2433442 bytes/sec.
Requests: 2332 susceed, 0 failed.
Speed=14130 pages/min, 2457442 bytes/sec.
Requests: 2355 susceed, 0 failed.
Speed=14034 pages/min, 2439853 bytes/sec.
Requests: 2339 susceed, 0 failed.
Speed=14304 pages/min, 2486660 bytes/sec.
Requests: 2384 susceed, 0 failed.

最后全打开xcache和TCMalloc情况下的负载能力
由于TCMalloc主要是提升mysql在高负载的情况下的性能，所以1客户端就不测试了。我们直接测试5客户端

采用5客户端10秒
webbench -c 5 -t 10 http://xxx/forumdisplay.php?fid=2\&page=1
成绩如下
Speed=14052 pages/min, 2443877 bytes/sec.
Requests: 2342 susceed, 0 failed.
Speed=13914 pages/min, 2417196 bytes/sec.
Requests: 2319 susceed, 0 failed.
Speed=13806 pages/min, 2400200 bytes/sec.
Requests: 2301 susceed, 0 failed.
Speed=13914 pages/min, 2419876 bytes/sec.
Requests: 2319 susceed, 0 failed.
Speed=14028 pages/min, 2439703 bytes/sec.
Requests: 2338 susceed, 0 failed.

从结果来看，确实xcache对于提高php的性能是相当显著的，但是并不是提高了就能直接用的，从测试的数据来看，在1客户端打开xcache后虽然性能从1700一跃到了6200，这个结果我想每个人看了都会热血沸腾，但是php的性能提高了必然的给mysql的压力就高了，从图中可以看到mysql的压力从62同样的也一跃到达了289。整个系统的负载虽然没变多少，但是很明显的，在打开xcache的情况下，整体性能得到了大幅度的提升。很明显在应用系统对mysql压力不大的情况下安装xcache会给处理性能带来质的飞跃。但是如果本身压力是在mysql的情况下盲目的上xcache反而会得不偿失。

google-perftools的TCMalloc很明显对与此次的测试压力完全没有发挥优势，TCMalloc是 Thread-Caching Malloc的缩写，相对于与标准的glibc库的malloc相比，在高并发的 mysql上面可以有效的降低系统负载。只是测试的负载太低，看来只能直接上生产系统看效果了。

• 设置建议:

对于单台运行的WEB服务器,建议加上:
skip-locking
skip-name-resolve
skip-networking

在PHP链接数据库时使用”LOCALHOST”.这样MySQL 客户端库将覆盖之并尝试连接到本地套接字.(
我们可以从PHP.INI中

 ; Default socket name for local MySQL connects.  If empty, uses the built-in
; MySQL defaults.
mysql.default_socket = /tmp/mysql.sock

看出 默认情况下 UNIX 将访问/tmp/mysql.sock)

• 以下是部分选项解释:

my.cnf默认是不存在的.你可以在/usr/local/share/mysql/下看到:

1. my-huge.cnf
2. my-innodb-heavy-4G.cnf
3. my-large.cnf
4. my-medium.cnf
5. my-small.cnf

等文件.将其中合适你机器配置的文件拷贝到/etc/my.cnf或mysql data目录/my.cnf(/var/db/mysql)下或~/.my.cnf.文件内都有详细的说明

[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
# 避免MySQL的外部锁定，减少出错几率增强稳定性。

skip-name-resolve
禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！

back_log = 384
指定MySQL可能的连接数量。当MySQL主线程在很短的时间内接收到非常多的连接请求，该参数生效，主线程花费很短的时间检查连接并且启动一个新线程。
back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的限制。
试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。

key_buffer_size = 256M
# key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。
对于内存在4GB左右的服务器该参数可设置为256M或384M。
注意：该参数值设置的过大反而会是服务器整体效率降低！

max_allowed_packet = 4M
thread_stack = 256K
table_cache = 128K
sort_buffer_size = 6M
查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占！如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。

read_buffer_size = 4M
读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享！

join_buffer_size = 8M
联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享！

myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
指定MySQL查询缓冲区的大小。可以通过在MySQL控制台执行以下命令观察：

 # > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';

如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况；
如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。

tmp_table_size = 256M
max_connections = 768
指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示，则需要增大该参数值。

max_connect_errors = 10000000
wait_timeout = 10
指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。

thread_concurrency = 8
该参数取值为服务器逻辑CPU数量×2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4 × 2 ＝ 8

skip-networking
开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！

同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法，因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。

安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的配制文件了。

一般的情况下，my-medium.cnf这个配制文件就能满足我们的大多需要；一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的参数，有３个配置参数是最重要的，即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只对MyISAM表起作用，

key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。一般我们设为16M,实际上稍微大一点的站点　这个数字是远远不够的，通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）。 或者如果你装了phpmyadmin 可以通过服务器运行状态看到,笔者推荐用phpmyadmin管理mysql，以下的状态值都是本人通过phpmyadmin获得的实例分析:

这个服务器已经运行了20天

key_buffer_size – 128M
key_read_requests – 650759289
key_reads – 79112
比例接近1:8000 健康状况非常好

另外一个估计key_buffer_size的办法　把你网站数据库的每个表的索引所占空间大小加起来看看以此服务器为例:比较大的几个表索引加起来大概125M 这个数字会随着表变大而变大。

从4.0.1开始，MySQL提供了查询缓冲机制。使用查询缓冲，MySQL将SELECT语句和查询结果存放在缓冲区中，今后对于同样的SELECT语句（区分大小写），将直接从缓冲区中读取结果。根据MySQL用户手册，使用查询缓冲最多可以达到238%的效率。

通过调节以下几个参数可以知道query_cache_size设置得是否合理

Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks
Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况,同时Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，此时需要增加缓冲大小Qcache_hits的值不大，则表明你的查询重复率很低，这种情况下使用查询缓冲反而会影响效率，那么可以考虑不用查询缓冲。此外，在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多query_cache_type指定是否使用查询缓冲

我设置:

query_cache_size = 32M
query_cache_type= 1
得到如下状态值:

Qcache queries in cache 12737 表明目前缓存的条数
Qcache inserts 20649006
Qcache hits 79060095 　看来重复查询率还挺高的
Qcache lowmem prunes 617913　有这么多次出现缓存过低的情况
Qcache not cached 189896 　　
Qcache free memory 18573912　　目前剩余缓存空间
Qcache free blocks 5328 这个数字似乎有点大　碎片不少
Qcache total blocks 30953
如果内存允许32M应该要往上加点

table_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache，并且opened_tables在不断增长，那么你就需要增加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得）。注意，不能盲目地把table_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。

对于有1G内存的机器，推荐值是128－256。

笔者设置table_cache = 256

得到以下状态:

Open tables 256
Opened tables 9046
虽然open_tables已经等于table_cache，但是相对于服务器运行时间来说,已经运行了20天，opened_tables的值也非常低。因此，增加table_cache的值应该用处不大。如果运行了6个小时就出现上述值 那就要考虑增大table_cache。

如果你不需要记录2进制log 就把这个功能关掉，注意关掉以后就不能恢复出问题前的数据了，需要您手动备份，二进制日志包含所有更新数据的语句，其目的是在恢复数据库时用它来把数据尽可能恢复到最后的状态。另外，如果做同步复制( Replication )的话，也需要使用二进制日志传送修改情况。

log_bin指定日志文件，如果不提供文件名，MySQL将自己产生缺省文件名。MySQL会在文件名后面自动添加数字引，每次启动服务时，都会重新生成一个新的二进制文件。此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以指定记录的数据库；使用binlog-ignore-db可以指定不记录的数据库。注意的是：binlog-do-db和binlog-ignore-db一次只指定一个数据库，指定多个数据库需要多个语句。而且，MySQL会将所有的数据库名称改成小写，在指定数据库时必须全部使用小写名字，否则不会起作用。

关掉这个功能只需要在他前面加上#号

#log-bin
开启慢查询日志( slow query log ) 慢查询日志对于跟踪有问题的查询非常有用。它记录所有查过long_query_time的查询，如果需要，还可以记录不使用索引的记录。下面是一个慢查询日志的例子：

开启慢查询日志，需要设置参数log_slow_queries、long_query_times、log-queries-not-using-indexes。

log_slow_queries指定日志文件，如果不提供文件名，MySQL将自己产生缺省文件名。long_query_times指定慢查询的阈值，缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的参数，它指示记录不使用索引的查询。笔者设置long_query_time=10

笔者设置:

sort_buffer_size = 1M
max_connections=120
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
interactive_timeout=120
thread_concurrency = 4
参数说明:

back_log

要求MySQL能有的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求，这就起作用，然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接，你需要增加它，换句话说，这值对到来的TCP/IP连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的限制。 Unix listen(2)系统调用的手册页应该有更多的细节。检查你的OS文档找出这个变量的最大值。试图设定back_log高于你的操作系统的限制将是无效的。

max_connections

并发连接数目最大，120 超过这个值就会自动恢复，出了问题能自动解决

thread_cache

没找到具体说明，不过设置为32后 20天才创建了400多个线程 而以前一天就创建了上千个线程 所以还是有用的

thread_concurrency

#设置为你的cpu数目x2,例如，只有一个cpu,那么thread_concurrency=2
#有2个cpu,那么thread_concurrency=4
skip-innodb
#去掉innodb支持
代码:

# Example MySQL config file for medium systems.
#
# This is for a system with little memory (32M – 64M) where MySQL plays
# an important part, or systems up to 128M where MySQL is used together with
# other programs (such as a web server)
#
# You can copy this file to
# /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /var/lib/mysql) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the “–help” option.

# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 128M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
net_buffer_length = 16K
myisam_sort_buffer_size = 1M
max_connections=120
#addnew config
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
skip-innodb
skip-bdb
skip-name-resolve
join_buffer_size=512k
query_cache_size = 32M
interactive_timeout=120
long_query_time=10
log_slow_queries= /usr/local/mysql4/logs/slow_query.log
query_cache_type= 1
# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 4

#end new config
# Don’t listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the “enable-named-pipe” option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
#log-bin

# required unique id between 1 and 2^32 – 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) –
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=, MASTER_PORT=,
# MASTER_USER=, MASTER_PASSWORD= ;
#
# where you replace , , by quoted strings and
# by the master’s port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST=’125.564.12.1′, MASTER_PORT=3306,
# MASTER_USER=’joe’, MASTER_PASSWORD=’secret’;
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables’ values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 – 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id = 2
#
# The replication master for this slave – required
#master-host =
#
# The username the slave will use for authentication when connecting
# to the master – required
#master-user =
#
# The password the slave will authenticate with when connecting to
# the master – required
#master-password =
#
# The port the master is listening on.
# optional – defaults to 3306
#master-port =
#
# binary logging – not required for slaves, but recommended
#log-bin

# Point the following paths to different dedicated disks
#tmpdir = /tmp/
#log-update = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 – 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout
补充

优化table_cachetable_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache，并且opened_tables在不断增长，那么你就需要增加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得）。注意，不能盲目地把table_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。对于有1G内存的机器，推荐值是128－256。

案例1：该案例来自一个不是特别繁忙的服务器table_cache – 512open_tables – 103opened_tables – 1273uptime – 4021421 (measured in seconds)该案例中table_cache似乎设置得太高了。在峰值时间，打开表的数目比table_cache要少得多。

案例1：健康状况key_buffer_size – 402649088 (384M)key_read_requests – 597579931key_reads – 56188案例2：警报状态key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads – 53832731案例1中比例低于1:10000，是健康的情况；案例2中比例达到1:11，警报已经拉响。

1.在$CATALINA_HOME/conf/server.xml中添加配置信息，声明连接池的具体信息，添加内容如下：
　　
　　<!–声明连接池–>
　　
　　<Resource name=”jdbc/mysql” auth=”Container” type=”javax.sql.DataSource”/>
　　
　　<!– 对连接池的参数进行设置 –>
　　
　　<ResourceParams name=”jdbc/mysql”>
　　
　　<parameter>
　　
　　<name>factory</name>
　　
　　<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>maxWait</name>
　　
　　<value>5000</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>maxActive</name>
　　
　　<value>20</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>username</name>
　　
　　<value>shopadm</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>password</name>
　　
　　<value>123</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>url</name>
　　
　　<value>jdbc:mysql://localhost/shopdb?useUnicode=true&charact-erEncoding=gb2312</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>driverClassName</name>
　　
　　<value>com.mysql.jdbc.Driver</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>maxIdle</name>
　　
　　<value>10</value>
　　
　　</parameter>
　　
　　</ResourceParams>
　　
　　2. 在$CATALINA_HOME/conf/web.xml的</web-app>前添加如下信息：
　　
　　<resource-ref>
　　
　　<description>DB Connection</description>
　　
　　<res-ref-name>jdbc/mysql</res-ref-name>
　　
　　<res-type>javax.sql.DataSource</res-type>
　　
　　<res-auth>Container</res-auth>
　　
　　</resource-ref>
　　
　　其中<res-ref-name>中的参数名必须和server.xml中声明的连接名一样。
　　
　　3. 在$CATALINA_HOME/conf/catalina/localhost目录下找到需要进行数据库连接的当前程序的配置信息，比如这里是shopping.xml，在这个文件中添加如下信息：
　　
　　<Context …>
　　
　　…
　　
　　<ResourceLink name=”jdbc/mysql” global=”jdbc/mysql” type=”javax.sql.DataSource”/>
　　
　　…
　　
　　</Context>
　　
　　大功告成！
　　
　　在此基础上，参考Tomcat官方网站的用户手册，摸索出另外一种配置连接池的方法，这个方法不需要对server.xml进行修改，只要对需要使用到连接池的程序的配置文档进行修改就可以了。方法如下：
　　
　　1.$CATALINA_HOME/conf/catalina/localhost目录下找到需要数据库连接池的程序的配置文档，此处是shopping.xml。在<Context> </Context>之间添加如下信息，声明一个数据库连接池：
　　
　　<Resource name=”jdbc/mysql” auth=”Container” type=”javax.sql.DataSource”/>
　　
　　<ResourceParams name=”jdbc/mysql”>
　　
　　<parameter>
　　
　　<name>factory</name>
　　
　　<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>maxWait</name>
　　
　　<value>5000</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>maxActive</name>
　　
　　<value>20</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>password</name>
　　
　　<value>123</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>url</name>
　　
　　<value>jdbc:mysql://localhost/shopdb?useUnicode=true&characterEncoding=gb2312</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>driverClassName</name>
　　
　　<value>com.mysql.jdbc.Driver</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>maxIdle</name>
　　
　　<value>10</value>
　　
　　</parameter>
　　
　　<parameter>
　　
　　<name>username</name>
　　
　　<value>shopadm</value>
　　
　　</parameter>
　　
　　</ResourceParams>
　　
　　这里的参数和上一种方法中添加到server.xml里的信息几乎是完全一样的。
　　
　　2.在对应程序的WEB-INF下建立一个web.xml文档，添加如下信息：
　　
　　<?xml version=”1.0″ encoding=”ISO-8859-1″?>
　　
　　<web-app xmlns=”http://java.sun.com/xml/ns/j2ee”
　　
　　xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
　　
　　xsi:schemaLocation=”http://java.sun.com/xml/ns/j2ee
　　
　　http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd”
　　
　　version=”2.4″>
　　
　　<resource-ref>
　　
　　<description>DB Connection</description>
　　
　　<res-ref-name>jdbc/mysql</res-ref-name>
　　
　　<res-type>javax.sql.DataSource</res-type>
　　
　　<res-auth>Container</res-auth>
　　
　　</resource-ref>
　　
　　</web-app>

文摘出处：http://www.paulgao.com.cn/index.php?catid=5&blogid=1

LAMP 架构服务器性能优化建议
（03/11/2004，R1版）

　　出处：http://www.paulgao.com.cn，欢迎转载。
　　关键词：LINUX、APACHE、PHP、MYSQL、服务器、性能优化、配置优化。

　　维护“手机之家”（http://www.imobile.com.cn)的服务器有快两年了，也有些经验心得，写在这里给大家分享。

　　服务器配置如下：redhat linux 9.0、apache 1.3.29、php 4.3.4、mysql 3.23.58，以下建议均在以上平台上跑的很好，当然也跟你的应用有关系，具体实施要根据实际效果来进行。

　　1、众所周知的方法就是使用 Zend Optimizer（简称 ZO，最新版本为 2.5.1） 或者 Zend Performance Suite（简称 ZPS，其中包含 ZO，最新版本为 3.6.0）对 PHP 进行加速。相关软件可到张微波的主页来下载哦，地址为：http://www.5ilinux.com/blog/archives/000093.html。

　　2、apache配置优化（httpd.conf）
1)修改“Timeout”的值为 30-60，如果你得程序没有执行时间需要很长的话，可以修改到 10-15；
2)修改“KeepAlive”的值为“Off”，这个很有效果，也很有争议，我自己的看法是很有效果，而且并没有影响速度，大家可以自行试验；
3)修改“MaxRequestsPerChild”的值为“2048”，这个还在试验中，一是因为怕有内存泄漏，二是因为 apache 进程会因为随着服务时间的延长，会变得越来越胖（我这里的实际情况是某些 apache 进程会狂吃内存到18MB，晕啊：），不过这设置有没有效果，还在试验中；
4)在不使用 .htaccess 的情况下，将其“”部分设置为“None”方式，如果你使用 PHPMYADMIN 进行管理的话，可以使用 PHPMYADMIN 的 COOKIE 权限控制方式。

　　3、卸载不必要的模块，不管是静态编译还是 DSO 模式，以便节省内存占用。具体模块可以参照 apache 的手册，这里就不多说了。PHP 也是同样，我基本上已经把不用的模块都卸载了：）

　　4、使用 mod_gzip 进行加速，很简单，就不多说了。

　　5、如果你的服务器还是负载很高的话，更极端的方式就是在 httpd.conf 里面将日志停掉了，不过一般要保留 errorlog 才好，以便排错，而且要记得，不是把“CustomLog”注释掉就行了，而要使用“CustomLog /dev/null common”这样的方式才好。

　　6、如果你的 PHP 程序使用 Session 对话的话，可以在 php.ini 里面将“session.save_path”设置为“session.save_path = /dev/shm”，因为 /dev/shm 是 linux 系统独有的 TMPFS 文件系统，是以内存为主要存储方式的文件系统，比 RAMDISK 要好，因为可以使用 DISKSWAP 作为补充，而且是系统自带，不需要另行配置，想想吧，从磁盘IO操作到内存操作，速度会快多少？：）你也可以把你所需要的临时文件都写在 /dev/shm 下，只是别忘了，重启就没有啦，我是只存放目标文件的，呵呵。额外的说明资料请看“使用虚拟内存（virtual memory，VM）文件系统和绑定安装”（http://www-900.ibm.com/developerWorks/cn/linux/filesystem/l-fs3/index.shtml）。

　　7、MYSQL 的优化（/etc/my.cnf）
1)确认在“[mysqld]”部分加入了“skip-innodb”和“skip-bdb”参数；
2)确认在“[mysqld]”部分加入了“skip-name-resolve”和“skip-locking”参数；
3)如果不需要的话，可以将二进制日志（binlog）停掉，方法是将“log-bin”注释掉；
4)在内存允许的情况下，对一些参数进行重新配置，目标在于将大部分操作集中于内存中，尽量不进行磁盘操作，对于我的 MYSQL 服务器我是如下修改的，基于 2G 内存情况：

[mysqld]
set-variable = key_buffer=512M
set-variable = max_allowed_packet=4M
set-variable = table_cache=1024
set-variable = thread_cache=64
set-variable = join_buffer_size=32M
set-variable = sort_buffer=32M
set-variable = record_buffer=32M
set-variable = max_connections=512
set-variable = wait_timeout=120
set-variable = interactive_timeout=120
set-variable = max_connect_errors=30000
set-variable = long_query_time=1
set-variable = max_heap_table_size=256M
set-variable = tmp_table_size=128M
set-variable = thread_concurrency=8
set-variable = myisam_sort_buffer_size=128M

你可以根据“show status”命令返回的状态进行微调。我主要注意以下变量的数值，越小越好，最好为零：）
Created_tmp_disk_tables
Created_tmp_tables
Created_tmp_files
Slow_queries

　　8、在启动脚本中使用“–log-slow-queries=/home/logs/mysql_slow.log”参数，以便进行 SQL 语句的优化工作，这个其实是很很重要的工作。记得一定要在 my.cnf 中设置“set-variable = long_query_time=1”才行。

　　9、另外可以使用 4.0.xx 版本的 MYSQL，4.0.xx 版本除了一些性能提升以外，还有 QueryCache 方法，就是在 SQL 语句查询结果没有变动之前，将其结果进行缓存，下次再进行同样的 SQL 语句查询就可以直接反回结果，当然也是以牺牲内存为前提：）

　　10、额外的，对于 LINUX EXT3 文件系统还有一个小技巧可用，就是在修改 /etc/fstab 中的参数，比如“/dev/sdb2 /home ext3 defaults 1 2”改为“/dev/sdb2 /home ext3 noatime 1 2”，“noatime”的意思就是不修改 accesstime，对于磁盘文件读写频繁的服务器也应该可以降低一些效果。不过最好不要远程操作，不然因为修改失误，服务器不能启动了，可别怪我：）

　　好了，基本上我用过的方法已经说过一遍了，有些方法是取自于一些很好的文章，由于未作保留，所以无法写出出处，只能泛泛的表示感谢了。其中有些方法也适用于 Windows 平台，大家可以根据自己的服务器、应用情况去进行应用，大家也可一说说自己的办法，比如改用 ZEUS 来做 webserver，我也在找更多的办法来提升服务器性能，比如基于 LINUX KERNEL v2.4 以上内核的一些性能优化方法，从 network 到 swap（因为内核升级，所以一些老版本内核的方法已经不能再使用了：）。我也会进一步更新这篇文章，让大家能够更好的进行服务器的性能提升工作～

　　另外欢迎来访问国内数一数二的手机网站，手机之家，地址见下，呵呵～

高春辉
mailto:paulgao@yeah.net
手机之家网站(http://www.imobile.com.cn)

1。mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份数据库中。实现mysql数据库的热备份。
2。要想实现双机的热备首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都要高于3.2，还有一个基本的原则就是作为从数据库的数据库版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。

3。设置主数据库服务器：
a.首先查看主服务器的版本是否是支持热备的版本。然后查看my.cnf(类unix)或者my.ini(windows)中mysqld配置块的配置有没有log-bin(记录数据库更改日志)，因为mysql的复制机制是基于日志的复制机制，所以主服务器一定要支持更改日志才行。然后设置要写入日志的数据库或者不要写入日志的数据库。这样只有您感兴趣的数据库的更改才写入到数据库的日志中。
server-id=1 //数据库的id这个应该默认是1就不用改动
log-bin=log_name //日志文件的名称，这里可以制定日志到别的目录 如果没有设置则默认主机名的一个日志名称
binlog-do-db=db_name //记录日志的数据库
binlog-ignore-db=db_name //不记录日志的数据库
以上的如果有多个数据库用”,”分割开

然后设置同步数据库的用户帐号
mysql> GRANT REPLICATION SLAVE ON *.*
-> TO ‘repl’@'%.mydomain.com’ IDENTIFIED BY ‘slavepass’;

4.0.2以前的版本, 因为不支持REPLICATION 要使用下面的语句来实现这个功能

mysql> GRANT FILE ON *.*
-> TO ‘repl’@'%.mydomain.com’ IDENTIFIED BY ‘slavepass’;

设置好主服务器的配置文件后重新启动数据库

b.锁定现有的数据库并备份现在的数据
锁定数据库
mysql> FLUSH TABLES WITH READ LOCK;
备份数据库有两种办法一种是直接进入到mysql的data目录然后打包你需要备份数据库的文件夹，第二种是使用mysqldump的方式来备份数据库但是要加上”–master-data ” 这个参数，建议使用第一种方法来备份数据库
c.查看主服务器的状态
mysql> show master statusG;
+—————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+—————+———-+————–+——————+
| mysql-bin.003 | 73 | test | manual,mysql |
+—————+———-+————–+——————+
记录File 和 Position 项目的值，以后要用的。

d.然后把数据库的锁定打开
mysql> UNLOCK TABLES;

4。设置从服务器
a.首先设置数据库的配置文件
server-id=n //设置数据库id默认主服务器是1可以随便设置但是如果有多台从服务器则不能重复。
master-host=db-master.mycompany.com //主服务器的IP地址或者域名
master-port=3306 //主数据库的端口号
master-user=pertinax //同步数据库的用户
master-password=freitag //同步数据库的密码
master-connect-retry=60 //如果从服务器发现主服务器断掉，重新连接的时间差
report-host=db-slave.mycompany.com //报告错误的服务器

b.把从主数据库服务器备份出来的数据库导入到从服务器中
c.然后启动从数据库服务器，如果启动的时候没有加上”–skip-slave-start”这个参数则进入到mysql中
mysql> slave stop; //停止slave的服务
d.设置主服务器的各种参数
mysql> CHANGE MASTER TO
-> MASTER_HOST=’master_host_name’, //主服务器的IP地址
-> MASTER_USER=’replication_user_name’, //同步数据库的用户
-> MASTER_PASSWORD=’replication_password’, //同步数据库的密码
-> MASTER_LOG_FILE=’recorded_log_file_name’, //主服务器二进制日志的文件名(前面要求记住的参数)
-> MASTER_LOG_POS=recorded_log_position; //日志文件的开始位置(前面要求记住的参数)
e.启动同步数据库的线程
mysql> slave start;

查看数据库的同步情况吧。如果能够成功同步那就恭喜了！

查看主从服务器的状态

mysql> SHOW PROCESSLISTG //可以查看mysql的进程看看是否有监听的进程

如果日志太大清除日志的步骤如下
如果日志太大清除日志的步骤如下
    1.锁定主数据库 mysql> FLUSH TABLES WITH READ LOCK;
    2.停掉从数据库的slave mysql> slave stop;
    3.查看主数据库的日志文件名和日志文件的position
show master status;
+—————+———-+————–+——————+ | File | Position | Binlog_do_db | Binlog_ignore_db | +—————+———-+————–+——————+ | louis-bin.001 | 79 | | mysql | +—————+———-+————–+——————+
    4.解开主数据库的锁 mysql> unlock tables;
    5.更新从数据库中主数据库的信息 mysql> CHANGE MASTER TO ->         MASTER_HOST=’master_host_name’, //主服务器的IP地址 ->     MASTER_USER=’replication_user_name’, //同步数据库的用户 -> MASTER_PASSWORD=’replication_password’, //同步数据库的密码 -> MASTER_LOG_FILE=’recorded_log_file_name’, //主服务器二进制日志的文件名(前面要求记住的参数) -> MASTER_LOG_POS=recorded_log_position; //日志文件的开始位置(前面要求记住的参数)
6.启动从数据库的slave mysql> slave start;