最好的优化-----不查询!
如果一台服务器出现长时间负载过高 /周期性负载过大,或偶尔卡住
如何来处理?
答:大的思路--------
是周期性的变化还是偶尔问题?
是服务器整体性能的问题, 还是某单条语句的问题?
具体到单条语句, 这条语句是在等待上花的时间,还是查询上花的时间.
唯一的办法-----监测并观察服务器的状态.
观察服务器状态, 一般用如下2个命令
Show status; Show processlist;
例: mysql> show status;
#mysqladmin ext
MySQL周期性波动试验
实验目的: 模拟数据库高低峰时的压力波动,并会观察绘制波动曲线
实验思路: 反复查询数据库并缓存入memcached, 缓存定期失效,
观察记录服务器参数,并作图表.
实验准备: nginx+php+memcached+awk+ab
1: index.php (随机访问3W条热数据,并储存在memcached中
2: memcached (储存查询结果)
3: ab 压力测试工具
4: awk脚本
编译PHP-memcache扩展 (此步骤适合任意PHP扩展)
以memcache-2.2.7为例(注意,这是PHP连接memcached的一个扩展)
解压后,假设路径/path/to/memcache
step1 : /path/to/memcached/# /path/to/php/bin/phpize #作用是根据PHP的版本生成编译文件
此步骤后,memcache目录下,产生configure文件
step2: configure --with-php-config =/path/to/php/bin/php-config
step3: make && make install
此步骤编译出一个memcache.so文件
step4: 修改php.ini引入memcache.so
实验步骤:
总数据3W以上,50个并发,每秒请求500-1000次
请求结果缓存在memcache,生命周期为60秒,
(生命周期要结合请求周期来制定,比如3万条数据随机,每秒1000条,30秒能走一遍,生命周期可设为60秒)
观察mysql连接数,每秒请求数的周期变化.
看上图,mysql的每秒请求数,随着缓存失效,有短时间的高峰.
解决办法:
1: 减少无关请求(业务逻辑层面,暂不讨论,但其实是最有效的手段)
2: 如果请求数是一定的,不可减少的. 我们要尽量让请求数平稳,不要有剧烈波动.
很多时候,不是服务器撑不住总的查询量,而是在某个时间段撑不住高峰请求.
该实际问题最后的解决:
----夜间负载低时,集中失效.
短时间内会有波峰,但夜间访问量少,因此波峰并不剧烈,当到上午10点左右人多时,缓存已经建立了一部分. 白天时,波峰也不剧烈.
或者让缓存的生命周期在一定范围内随机,也可以减缓波峰剧烈的情况
我们把实验中的生命周期由80秒,改为[40-120秒],其他实验条件不变.
得到如下曲线
可以看出,稳定运行后,请求在[1000-1500]之间波动,
而固定缓存周期是,请求在[500-1700]之间波动.
实验附件:
bench.php<?php// 30K hot news$rangeid = rand(1,30000)+13000000;$mconn = memcache_connect('localhost',11211);if( ($com = memcache_get($mconn,$rangeid)) === false) {$conn = mysql_connect('localhost','root');$sql = 'use bigdata';mysql_query($sql,$conn);$sql = 'set names utf8';mysql_query($sql,$conn);$sql = 'select id,name,brief from lx_com where id=' . $rangeid;$rs = mysql_query($sql,$conn);$com = mysql_fetch_assoc($rs);memcache_add($mconn , $rangeid , $com , false, mt_rand(40,120));} else {echo 'from cache';}print_r($com);status.sh#!/bin/bashwhile truedomysqladmin -uroot ext|awk '/Queries/{q=$4}/Threads_connected/{c=$4}/Threads_running/{r=$4}END{printf("%d %d %dn",q,c,r)}' >> status.txtsleep 1done
对于不规则的延迟现象的观察
不规则的延迟现象往往是由于效率低下的语句造成的,如何抓到这些效率低的语句.
可以用show processlist命令长期观察,或用慢查询.
Show processlist;
这个命令是显示当前所有连接的工作状态.
#!/bin/bashwhile truedomysql -uroot -e 'show processlistG'|grep State:|uniq -c|sort -rnecho '---'sleep 1Done
如果观察到以下状态,则需要注意
converting HEAP to MyISAM 查询结果太大时,把结果放在磁盘 (语句写的不好,取数据太多)
create tmp table 创建临时表(如group时储存中间结果,说明索引建的不好)
Copying to tmp table on disk 把内存临时表复制到磁盘 (索引不好,表字段选的不好)
locked 被其他查询锁住 (一般在使用事务时易发生,互联网应用不常发生)
logging slow query 记录慢查询
mysql 5.5 以后加了一个profile设置,可以观察到具体语句的执行步骤.
0:查看profile是否开启
> Show variables like ‘profiling’
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling | OFF |
+---------------+-------+
1:> set profiling=on;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling | On |
+---------------+-------+
mysql> show profiles;
+----------+------------+----------------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+----------------------------------------------------------+
| 1 | 0.00034225 | select cat_id,avg(shop_price) from goods group by cat_id |
+----------+------------+----------------------------------------------------------+
1 row in set (0.00 sec)
mysql> show profile for query 1;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000058 |
| checking permissions | 0.000008 |
..
| Sorting result | 0.000004 |
| Sending data | 0.000120 |
| end | 0.000005 |
| query end | 0.000006 |
| closing tables | 0.000008 |
| freeing items | 0.000023 |
| logging slow query | 0.000003 |
| cleaning up | 0.000004 |
+----------------------+----------+
疑问; 如何定位到有问题的语句?
答:
1: 开启服务器慢查询
2: 了解临时表的使用规则
3: 经验
MySQL如何使用内部临时表
官方:/doc/refman/5.5/en/internal-temporary-tables.html
在处理请求的某些场景中,服务器创建内部临时表. 即表以MEMORY引擎在内存中处理,或以MyISAM引擎储存在磁盘上处理.如果表过大,服务器可能会把内存中的临时表转存在磁盘上.
用户不能直接控制服务器内部用内存还是磁盘存储临时表
临时表在如下几种情况被创建:
如果group by 的列没有索引,必产生内部临时表,
如果order by 与group by为不同列时,或多表联查时order by ,group by 包含的列不是第一张表的列,将会产生临时表(实验1)
mysql> explain select goods_id,cat_id from goods group by cat_id G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: goods
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 20
Extra: Using temporary; Using filesort
1 row in set (0.00 sec)
mysql> alter table goods add index cat_id(cat_id);
Query OK, 0 rows affected (0.18 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> explain select goods_id,cat_id from goods group by cat_id G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: goods
type: index
possible_keys: NULL
key: cat_id
key_len: 2
ref: NULL
rows: 20
Extra: Using index
mysql> explain select goods_id,cat_id from goods group by cat_id order by 1 G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: goods
type: index
possible_keys: NULL
key: PRIMARY
key_len: 3
ref: NULL
rows: 20
Extra: Using temporary
distinct 与order by 一起使用可能会产生临时表(实验2)
mysql> explain select distinct cat_id from goods order by 1 G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: goods
type: index
possible_keys: NULL
key: cat_id
key_len: 2
ref: NULL
rows: 20
Extra: Using index
1 row in set (0.00 sec)
mysql> explain select distinct cat_id from goods order by goods_id G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: goods
type: index
possible_keys: NULL
key: PRIMARY
key_len: 3
ref: NULL
rows: 20
Extra: Using temporary
1 row in set (0.00 sec)
mysql> explain select distinct cat_id from goods order by click_countG
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: goods
type: index
possible_keys: NULL
key: cat_id
key_len: 2
ref: NULL
rows: 20
Extra: Using temporary; Using filesort
1 row in set (0.00 sec)
如果使用SQL_SMALL_RESULT,MySQL会使用内存临时表,除非查询中有一些必须要把临时表建立在磁盘上.
union合并查询时会用到临时表
某些视图会用到临时表,如使用temptable方式建立,或使用union或聚合查询的视图
想确定查询是否需要临时表,可以用EXPLAIN查询计划,并查看Extra列,看是否有Using temporary.
如果一开始在内存中产生的临时表变大,会自动转化为磁盘临时表. 内存中临时表的最大值为tmp_table_size和max_heap_size中较小值.
这和create table时显示指定的内存表不一样:这些表只受max_heap_table_size系统参数影响.
当服务器创建内部临时表(无论在内存还是在磁盘),create_tmp_tables变量都会增加.
如果创建了在磁盘上内部临时表(无论是初始创建还是由in-memory转化),
create_tmp_disk_tables 变量都会增加.
一些情况下限制了内存临时表的使用,而使用磁盘临时表:
(使用了内部临时表的前提下) 语句中存在BLOB或TEXT列(实验3)
在GROUP BY 或 DISTINCT子句中有大于512字节的string列
在UNION或UNION ALL时,SELECT语句里有大于512字节的string列.
mysql> create table t1 (
num int,
intro text(1000)
);
mysql>insert into t1 values (3,'this is USA' , 4,'China');
mysql> show status like '%tmp%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 5 |
| Created_tmp_files | 9 |
| Created_tmp_tables | 74 |
+-------------------------+-------+
3 rows in set (0.00 sec)
mysql> select * from t1 group by num;
+------+-------------+
| num | intro |
+------+-------------+
| 3 | this is USA |
| 4 | China |
+------+-------------+
2 rows in set (0.00 sec)
mysql> show status like '%tmp%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 6 |
| Created_tmp_files | 9 |
| Created_tmp_tables | 75 |
+-------------------------+-------+
3 rows in set (0.00 sec)
通过前面实验,可以看出,数据库的优化是一个系统工程:
建表: 表结构的拆分,如核心字段都用int,char,enum等定长结构
非核心字段,或用到text,超长的varchar,拆出来单放一张表.
建索引: 合理的索引可以减少内部临时表(索引优化策略里详解)
写语句: 不合理的语句将导致大量数据传输以及内部临时表的使用.
