之前一位童鞋发的：
5版邮件,在用户量很大的情况下,如果做了分布式,如果在后端mysql上执行:
mysql> show global status like ‘Thread%‘;
Threads_cached 0
Threads_connected 793
Threads_created
2397086
Threads_running 260
看到 Threads_created
的值特别大,Threads_cached为0,而且此时mysql连接数和负载特别高的情况下,一定在my.cnf中加上如下参数:
thread_cache_size 128
先停掉各个前端,然后再重启后端mysql.
会发现各个前端机mysql的连接数总和会远小于后端mysql的连接数,因为连接都被cached掉了.
Mysql优化笔记：
从慢查询、连接数、Key_buffer_size、临时表、Open
Table情况、进程使用情况、查询缓存、排序使用情况、文件打开数、表锁情况、表扫描情况
这些方面去优化
====================================================================================
1. 慢查询：
慢查询个数: mysql> show global status like
‘%slow_queries‘;
慢查询日志开关： mysql> show global variables like
‘%log_slow_queries‘;
(1) 开启慢查询日志：
my.cnf
long_query_time = 5 //
执行超过多久的sql会被log下来，这里是5秒
log-slow-queries = /var/log/slowquery.log
//设置把日志写在那里
log-queries-not-using-indexes //纪录没使用索引的sql
配置后重启
mysql。
(2) 分析日志： mysqldumpslow
-s，是order的顺序，主要有c,t,l,r和ac,at,al,ar，分别是按照query次数，时间，lock的时间和返回的记录数来排序，前面加了a的时倒序。
-t，是top
n的意思，即为返回前面多少条的数据
-g，后边可以写一个正则匹配模式，大小写不敏感的
mysqldumpslow -s c -t 20 /var/log/slowquery.log
//访问次数最多的20个sql语句
mysqldumpslow -s t -t 20 /var/log/slowquery.log
//执行时间最多的20个sql语句
mysqldumpslow -s r -t 20 /var/log/slowquery.log
//返回记录集最多的20个sql
mysqldumpslow -t 10 -s t -g "left join"
/var/log/slowquery.log //这按照时间返回前10条里面含有左连接的sql语句。
=================================================================================
2. 连接数
最大连接数配置： show global variables like
‘max_connections‘;
曾用最大连接数： show global status like
‘max_used_connections‘;
当前连接数： show global status like
‘Threads_connected‘;
曾用来处理连接的线程数： show global status like
‘Threads_created‘;
max_used_connections / max_connections * 100% （理想值 ≈ 85%）
修改最大连接数配置：
mysql> set GLOBAL max_connections=1000;
mysql>
flush privileges
也可以修改/etc/my.cnf中的max_connections：
max_connections =
1000
max_used_connections： The maximum number of connections that have been in
use simultaneously since the server started.
从MYSQL本次开机以来，历史数据中的最大同时的并发联接数。
Threads_created： The number of threads
created to handle connections.
========================================================================================
3. key_buffer_size
key_buffer_size是对MyISAM表性能影响最大的一个参数,Innodb表不适用。
mysql> show global variables like ‘key_buffer_size‘;
mysql>
show global status where Variable_name in (‘Key_read_requests‘,‘Key_reads‘) ;
Key_read_requests 737517278
Key_reads 276013
mysql> select 276013/737517278*100;
0.0374
一共有737517278个索引读取请求，有276013个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：
key_cache_miss_rate
＝ Key_reads / Key_read_requests * 100% =
0.0374%
如果未命中概率过大，可以适当加大key_buffer_size
mysql> show global status where Variable_name in
(‘key_blocks_used‘,‘key_blocks_unused‘);
Key_blocks_unused 131673
Key_blocks_used 217227
mysql> select
217227/(131673+217227)*100;
62.2605
Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数
Key_blocks_used
/ (Key_blocks_unused + Key_blocks_used) * 100% ≈ 62.2605% （理想值 ≈ 80%）
========================================================================================
临时表
mysql> show global status like ‘created_tmp%‘;
Created_tmp_disk_tables 1
Created_tmp_files 16
Created_tmp_tables 1145
每次创建临时表，Created_tmp_tables增加;如果是在磁盘上创建临时表，Created_tmp_disk_tables
也增加;Created_tmp_files表示MySQL服务创建的临时文件文件数：
Created_tmp_disk_tables / Created_tmp_tables * 100% ＝ 0.0873% （理想值<=
25%）
mysql> show variables where Variable_name in (‘tmp_table_size‘,
‘max_heap_table_size‘);
max_heap_table_size 16777216
tmp_table_size 33554432
可适当增加 tmp_table_size
========================================================================================
open table 的情况
mysql> show global status like ‘open%tables%‘;
Open_tables 512
Opened_tables 2008
mysql> show
variables like ‘%table_cache%‘;
table_cache 512
mysql> select 512/2008*100;
25.4980
mysql> select
512/512*100;
100.0000
Open_tables 表示打开表的数量，Opened_tables表示打开过的表数量。
如果Opened_tables数量过大，说明配置中
table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小.
Open_tables / Opened_tables * 100% = 38.5196% 理想值 （>=
85%）
Open_tables / table_cache * 100% = 99.6094% 理想值 (<= 95%)
========================================================================================
进程使用情况
mysql> show global status like ‘Thread%‘;
Threads_cached
7
Threads_connected 112
Threads_created 2397
Threads_running 24
mysql> show variables like ‘thread_cache_size‘;
thread_cache_size
64
如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁（前提是缓存数未达上限）。
Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明
MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值。
========================================================================================
查询缓存(query cache)
mysql> show global status like ‘qcache%‘;
Qcache_free_blocks 4119
Qcache_free_memory 11911976
Qcache_hits 873527
Qcache_inserts 1267423
Qcache_lowmem_prunes 713698
Qcache_not_cached 895888
Qcache_queries_in_cache 11301
Qcache_total_blocks 27096
Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY
CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。
Qcache_free_memory：缓存中的空闲内存。
Qcache_hits：每次查询在缓存中命中时就增大
Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的
free_blocks和free_memory可以告诉您属于哪种情况）
Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是
SELECT
语句或者用了now()之类的函数。
Qcache_queries_in_cache：当前缓存的查询（和响应）的数量。
Qcache_total_blocks：缓存中块的数量。
我们再查询一下服务器关于query_cache的配置：
mysql> show variables like ‘query_cache%‘;
query_cache_limit 1048576
query_cache_min_res_unit
4096
query_cache_size 33554432
query_cache_type ON
query_cache_wlock_invalidate
OFF
query_cache_limit：超过此大小的查询将不缓存
query_cache_min_res_unit：缓存块的最小大小
query_cache_size：查询缓存大小
query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存
select sql_no_cache
查询
query_cache_wlock_invalidate：当有其他客户端正在对MyISAM表进行写操作时，如果查询在query
cache中，是否返回cache结果还是等写操作完成再读表获取结果。
query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。
mysql> select 4119 / 27096 *100；
15.2015
查询缓存碎片率 =
Qcache_free_blocks / Qcache_total_blocks * 100%
如果查询缓存碎片率超过20%，可以用FLUSH
QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。
mysql> select (33554432-11911976) / 33554432 *100；
64.4995
查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size
* 100%
查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小；查询缓存利用率在80％以上而且Qcache_lowmem_prunes
> 50的话说明query_cache_size可能有点小，要不就是碎片太多。
查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服务器
查询缓存碎片率 ＝ 20.46％，查询缓存利用率 ＝ 62.26％，查询缓存命中率 ＝ 1.94％，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。
========================================================================================
排序使用情况
mysql> show global status like ‘sort%‘;
Sort_merge_passes 2
Sort_range 18528
Sort_rows 390838
Sort_scan 3439
MySQL 首先会尝试在内存中做排序，使用的内存大小由系统变量 Sort_buffer_size
决定，如果它的大小不够把所有的记录都读到内存中，MySQL 就会把每次在内存中排序的结果存到临时文件中，等 MySQL
找到所有记录之后，再把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上，MySQL
会用另一个临时文件来存再次排序的结果，所以通常会看到 Sort_merge_passes
增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 Sort_buffer_size 会减少 Sort_merge_passes 和
创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度，见 How fast can you sort data with
MySQL?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html，貌似被墙）
另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处，参见：http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/