作者：吴炳锡 来源：http://wubx.net/ 联系方式： wubingxi#163.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
MySQL的默认配置比较保守。 有好的硬件还是需要有好的配置才可以发可以发挥MySQL的性能。
如果你是开发人员，为MySQL配置发愁时，可以来用一下 http://zhishutech.net/my-cnf-wizard.html
如果你是DBA初级人员，为MySQL配置纠时，可以来用一下： http://zhishutech.net/my-cnf-wizard.html
如果你是DBA高级人员，来一块优化http://zhishutech.net/my-cnf-wizard.html 这个吧。
让我们听到你的声音。
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
最近在一个性能测试中遇到机器的CPU频率不对。查了一下原来是irqbalance和cpuspeed搞出来问题。
irqbalance 理论上：
启用 irqbalance 服务，既可以提升性能，又可以降低能耗。
irqbalance 用于优化中断分配，它会自动收集系统数据以分析使用模式，并依据系统负载状况将工作状态置于 Performance mode 或 Power-save mode。
处于 Performance mode 时，irqbalance 会将中断尽可能均匀地分发给各个 CPU core，以充分利用 CPU 多核，提升性能。
处于 Power-save mode 时，irqbalance 会将中断集中分配给第一个 CPU，以保证其它空闲 CPU 的睡眠时间，降低能耗。
但实际中往往影响cpu的使用均衡，建议服务器环境中关闭。
cpuspeed这个也算是遇到一个大坑，如果bios中已经开启了max performance但cpu主频还是不对，那就是cpuspeed搞出来的鬼(笔记本可以保留这些服务用于省电)。
service irqbalance stop
service cpuspeed stop
chkconfig irqbalance off
chkconfig cpuspeed off
其实相对一个数据库服务器对Linux服务可以进行以下操作：
cd /etc/rc3.d/
mkdir ~/rc3
mv * ~/rc3/
chkconfig --level 3 crond
chkconfig --level 3 sshd on
chkconfig --level 3 rsyslog on
chkconfig --level 3 network on
ln -s /etc/rc.local S99local
最小化的开启服务，如果在需要其它可以手工再开启。
Good Luck.
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
今天一个朋友向我咨询怎么去优化 MySQL，我按着思维整理了一下，大概粗的可以分为21个方向。 还有一些细节东西（table cache, 表设计，索引设计，程序端缓存之类的）先不列了，对一个系统，初期能把下面做完也是一个不错的系统。
数据库能够高效的运行，最关建的因素需要内存足更大了，能缓存住数据，更新也可以在内存先完成。但不同的业务对内存需要强度不一样，一推荐内存要占到数据的15-25%的比例，特别的热的数据，内存基本要达到数据库的80%大小。
MySQL 5.6可以利用到64个核，而MySQL每个query只能运行在一个CPU上，所以要求更多的CPU，更快的CPU会更有利于并发。
在官方建议估计最推荐的是Solaris, 从实际生产中看CentOS, REHL都是不错的选择，推荐使用CentOS, REHL 版本为6以后的，当然Oracle Linux也是一个不错的选择。虽然从MySQL 5.5后对Windows做了优化，但也不推荐在高并发环境中使用windows.
更改文件句柄 ulimit –n 默认1024 太小
进程数限制 ulimit –u 不同版本不一样
禁掉NUMA numctl –interleave=all
默认的内存分配就是c的malloc 现在也出现许多优化的内存分配算法:
jemalloc and tcmalloc
从MySQL 5.5后支持声明内存储方法。
[mysqld_safe]
malloc-lib = tcmalloc
或是直接指到so文件
[mysqld_safe]
malloc-lib=/usr/local/lib/libtcmalloc_minimal.so
存储介质十分影响MySQL的随机读取，写入更新速度。新一代存储设备固态ssd及固态卡的出现也让MySQL 大放异彩，也是淘宝在去IOE中干出了一个漂亮仗。
推荐XFS, Ext4,如果还在使用ext2,ext3的同学请尽快升级别。 推荐XFS，这个也是今后一段时间Linux会支持一个文件系统。
文件系统强烈推荐: XFS
挂载XFS参数：
(rw, noatime,nodiratime,nobarrier)
挂载ext4参数：
ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)
如果使用SSD或是固态盘需要考虑：
• innodb_page_size = 4K
• Innodb_flush_neighbors = 0
正常请下请使用deadline 默认是noop
echo dealine >/sys/block/{DEV-NAME}/queue/scheduler
请使用带电的Raid，启用WriteBack， 对于加速redo log ,binary log, data file都有好处。
Query Cache在Innodb中有点鸡肋，Innodb的数据本身可以在Innodb buffer pool中缓存，Query Cache属于结果集缓存，如果开启Query Cache更新写入都要去检查query cache反而增加了写入的开销。
在MySQL 5.6中Query cache是被禁掉了。
现在一个数据对应5个以上App场景比较，但MySQL有个特性随着连接增多的情况下性能反而下降，所以对于连接超过200的以后场景请考虑使用thread pool. 这是一个伟大的发明。
连接可以用thread_cache_size缓存，观查属于比较属不如thread pool给力。数据库在连上分配的内存如下：
read_buffer_size +
read_rnd_buffer_size +
join_buffer_size +
sort_buffer_size +
binlog_cache_size +
thread_stack +
2 * net_buffer_length …
)
要把60-80%的内存分给innodb_buffer_pool_size. 这个不要超过数据大小了，另外也不要分配超过80%不然会利用到swap.
Redo Logs:
– innodb_flush_log_at_trx_commit = 1 // 最安全
– innodb_flush_log_at_trx_commit = 2 // 较好性能
– innodb_flush_log_at_trx_commit = 0 // 最好的情能
binlog :
binlog_sync = 1 需要group commit支持，如果没这个功能可以考虑binlog_sync=0来获得较佳性能。
数据文件：
innodb_flush_method = O_DIRECT
可以利用更多资源，在线alter操作有所提高。 目前也支持非中文的full text， 同时支持Memcache API访问。目前也是MySQL最优秀的一个引擎。
如果你还在MyISAM请考虑快速转换。
以前Percona 5.5和官方MySQL 5.5比拼性能时，胜出的一个Tips就是分配了超过4G的Redo log ,而官方MySQL5.5 redo log不能超过4G. 从 MySQL 5.6后可以超过4G了，通常建Redo log加起来要超过500M。 可以通过观查redo log产生量，分配Redo log大于一小时的量即可。
innodb_io_capactiy 在sas 15000转的下配置800就可以了，在ssd下面配置2000以上。
在MySQL 5.6:
innodb_lru_scan_depth = innodb_io_capacity / innodb_buffer_pool_instances
innodb_io_capacity_max = min(2000, 2 * innodb_io_capacity)
目前来看新的特性都是独立表空间支持:
truncate table 表空间回收
表空间传输
较好的去优化碎片等管理性能的增加，
整体上来看使用独立表空间是没用的。
innodb_thread_concurrency =并发这个参数在Innodb中变化也是最频繁的一个参数。不同的版本，有可能不同的小版本也有变动。一般推荐：
在使用thread pool 的情况下：
innodb_thread_concurrency = 0 就可以了。
如果在没有thread pool的情况下：
5.5 推荐：innodb_thread_concurrency =16 – 32
5.6 推荐innodb_thread_concurrency = 36
默认是 Repeatable read
推荐使用Read committed binlog格式使用mixed或是Row
较低的隔离级别 = 较好的性能
任环境离不开监控，如果少了监控，有可能就会陷入盲人摸象。 推荐zabbix+mpm构建监控。
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
数据库表设计这块学问比较多，我这里单从互联网角度出发同时结合Innodb的特性给出一些设计方法供大家参考。本文构建大概分两分部分:Innodb的特性及设计中如何利用这种特性。
Innodb特性：
如何利用这些特性：
从业务形态上来看：
建议数据在设计阶段就要考虑那些是大表，可以分为多少个业务，怎么能核心功能拆分。这块举个例子：大家经常听到的淘宝的用户库，商品库，收藏夹库，交易库，评论库等。及其它我们经常也能听到的：认证库，好友关系库等等。到业务形态上后，可以根据不同的形态选择不同的软件来做不要只看到mysql了，这块的设计可以把nosql类的东西也要考虑进来，最终设计数据库的模型。
数据库表的设计这块有可能都是各有建解，欢迎有不同意见的同学一块来讨论mail我的邮箱即可。
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
对于数据库来讲大多瓶颈都出现在IO问题上，所以现在SSD类的设备也才能大行其道。那数据库的IO这块有什么可以优化的吗？ 我这里大致谈一下我的看法，希望能达到一个抛砖引玉的效果。
这里谈一下数据库本身的配置方面
具体如下：
配置方面对于IO优化的原则：尽可能能缓存，减少读对数据库的随机IO的请求；同时减少写的随机IO的随时发生，利用各种buffer去缓存。下面来看一下这块的参数：
其它对IO有影响的参数(以5.6为准）
另外5.6的undo log也可以独立配置了，建议单独配置出来。
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
在MySQL数据库连接数很多,而且大多属于活跃的状态时MySQL机器基本上负载很高,属于基本上快要死去的状态了.
这时怎么办呢?
有可能两个办法.
第一先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果
非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务.
处理方法: set global innodb_thread_concurrency=16;
第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了.
DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的.
限制单用户连接数在500以下. 如:
set global max_user_connections=500;
(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因)
另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
这个参数主要防止对读取information_schema时造成大量读取磁盘进行信息统计(如果慢查询中出现关于information_schema中表时,也可以考虑禁用该参数)
处理依据:
当学校的一个食堂一分钟只能为两个打饭, 忽然来了100个时人来打饭,又没排队, 不出会现了打饭的师傅要用点时间
去选择为那个用户服务了, 人越多,场面就越乱, 难免出现用户大吼该他的场面, 最后有可能就出现不是打饭了,而时之间相互
打架了,打饭的师傅也将收到同时有90个以上的Server too busy. 如果能排一下队.最多也就50分钟能处理完了.
以前办法,应该可以让MySQLD不会挂掉.如果业务支撑受到限制,还是想办法处理一下.
问题:
高峰期的业务业务支撑数就是服务器的最终需求数吗?
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
对于使用MySQL的用户，对于这个变量大家一定不会陌生。前几年的MyISAM引擎优化中，这个参数也是一个重要的优化参数。但随着发展，这个参数也爆露出来一些问题。
机器的内存越来越大，人们也都习惯性的把以前有用的参数分配的值越来越大。这个参数加大后也引发了一系列问题。我们首先分析一下query_cache_size的工作原理：
一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当同样的一个SQL再次来到DB里调用时，DB在该表没发生变化的情况下把结果从缓存中返回给Client。
这里有一个关建点，就是DB在利用Query_cache工作时，要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时，Query_cache里的数据又怎么处理呢？首先要把Query_cache和该表相关的语句全部置为失效，然后在写入更新。那么如果Query_cache非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是Insert就会很慢，这样看到的就是Update或是Insert怎么这么慢了。
所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
我们知道Innodb的数据页是16K,而且是一个硬性的规定，系统里没更改的办法，希望将来MySQL也能也Oracle一样支持多种数据页的大小。
但实际应用中有时16K显的有点大了，特别是很多业务在Oracle或是SQL SERVER运行的挺好的情况下迁到了MySQL上发现IO增长太明显的情况下，
就会想到更改数据页大小了。
实际上innodb的数据页大小也是可以更改的，只是需要在源码层去更改，然后重新rebuild一下MySQL.
更改办法：
(以MySQL-5.1.38源码为例）
位置在storage/innobase/include/univ.i ，在univ.i中查找：UNIV_PAGE_SIZE
/*
DATABASE VERSION CONTROL
========================
*/
/* The universal page size of the database */
#define UNIV_PAGE_SIZE (2 * 8192) /* NOTE! Currently, this has to be a
power of 2 */
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 14
/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32
UNIV_PAGE_SIZE就是数据页大小，默认的是16K. 后面的备注里标明，该值是可以设置必须为2的次方。对于该值可以设置成4k,8k,16k,32K,64K，在大也没意义了。
同时更改了UNIV_PAGE_SIZE后需要更改 UNIV_PAGE_SIZE_SHIFT 该值是2的多少次方为UNIV_PAGE_SIZE，所以设置数据页分别情况如下：
#define UNIV_PAGE_SIZE_SHIFT 12 if UNIV_PAGE_SIZ=4K
#define UNIV_PAGE_SIZE_SHIFT 13 if UNIV_PAGE_SIZ=8K
#define UNIV_PAGE_SIZE_SHIFT 15 if UNIV_PAGE_SIZ=32K
例子：
更改innodb的数据页为8K,相应修改为：
/*
DATABASE VERSION CONTROL
========================
*/
/* The universal page size of the database */
#define UNIV_PAGE_SIZE 8192 /* NOTE! Currently, this has to be a
power of 2 */
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 13
/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32
重新编译，然后测试测试，再测试。Good luck!
作者：吴炳锡 来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
今天看一个水友说他的MySQL现在变的很慢。问什么情况时。说单表超过2个G的一个MyISAM。真垃圾的回答方式。
简单答复：换一个强劲的服务器。换服务器很管用的：）
………
最终让取到慢查询：
SELECT * FROM pw_gbook WHERE uid='N' ORDER BY postdate DESC LIMIT N,N;
如：
SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 1275480,20;
看到这个语句我都吐血了（BT的PHPWIND分页啊，这个语句是PHP初学者写出来的还正常，但PHPWIND那么成熟的社区了还有这样的问题）。
我这里简单说一下LIMIT的原理。这里以LIMIT N,M为基础：LIMIT首先要找查N+M行，然后从N行处，取M行。那么这样的SQL对一次查询1275500一个操作应该是一个昂贵的开销。对于LIMIT这类的优化，第一个目标就是让N变的尽可能的小或是不用。
怎么才能使这个N尽可能小呢。我们能做的其实就是用相对的值，给分页一个提示。如现在我们看的是第5页，看完看想看第6页，第6页同样显示是20条记录。我们就可以想到，以这个例子为准：我们可以肯定的是第6页的日值应小于第5页的，如果第5页的最小日值为：2009-11-4，那我们就可以用：
SELECT * FROM pw_gbook WHERE uid='48' and postdate<’2009-11-1’ ORDER BY postdate DESC LIMIT 20;
这样来查询第6页的内容。同样对于查看第4页的内容（假设第5页的最大日期为：2009-11-3）则第4页的内容为：
SELECT * FROM pw_gbook WHERE uid='48' and postdate>’2009-11-3’ ORDER BY postdate DESC LIMIT 20;
这是一个基本的思想。接下来讨论一下怎么展现的问题。
再说一下这种业务的SQL怎么实现：对于分页的展示可以用多用类型。这里说三种常用的类型：
第一种：显示“上一页” “下一页”这种类型
这种方式相对简单也就出现了我们看到那种SQL不思考的写法。合理的做法：
第一页：
SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 20;
第二页：根据第一页的postdate进行查询如：
SELECT * FROM pw_gbook WHERE uid='48' and postdate<’2009-11-3’ ORDER BY postdate DESC LIMIT 20;
为什么说这个简单呢，这个不存在跳页的问题。接下来这种就存在一个跳页的问题了。
第二种：显示 “ 1,2,3,4,5…”
第一页： 还是以第一页的方式实现：
SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 20;
第二页：和原来一样。如果跳页，如从第二页跳到第5页，这里有一个第二页的最小日期为：2009-11-3（假设值，可以由第二页的程序查询得到），第二到第5，差2页，每页20条记录，那么就可以用：
SELECT * FROM pw_gbook WHERE uid='48' and postdate<’2009-11-3’ ORDER BY postdate DESC LIMIT 40，20;
看到这里明白为什么大型网站的分页不是一下标识出来完了，让都能点了吧。也不会给你一个框让你输入一个页跳过去了。如果跳的页面过多，也就存在N值过大的问题了。所以要想办法必免。
第三种：显示 “1，2，3，4，5，…. 末页” 或是 “首页，<<100,101,102,103 >>末页”
这里有一个特殊的一地方：
别的页面的跳转的上面一样。这里就加一个末页，这里又分两种情况，如果知道最后一页是多少页，也就知道了前一页的最小日期（分页提示值），这样就可以用上面的方法查看最后一页的内容（会出现不足20条的现象），另一种，我就不知道最后是第几页，我就是想看看最后什么样子，那么就可以用（一定是显示20条）：
SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate ASC limit 20;
首页这里就不在说了。
具体怎么实现搞明白了，就可以做PHP代码的修改了。稍稍修改一下，就会带来意想不到的效果。
这里只是一个通用的分页处理方法。不同的业务有可能还有不同的方法处理。如果在条件可能和情况可以考用:between … and .. 带代替limit分页操作。
第三种方法：
简单的逻辑转换。
SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 1275480,20;
转换成：
SELECT * FROM pw_gbook WHERE id>1275480 and uid='48' ORDER BY postdate DESC LIMIT 20;