MySQL自带的slow log分析工具
[ 2009/08/17 19:01 | by selboo ]
mysqldumpslow 平时主要用到的参数是
-s ORDER what to sort by (t, at, l, al, r, ar etc), ‘at’ is default
-t NUM just show the top n queries
-g PATTERN grep: only consider stmts that include this string
-s,是order的顺序,主要有c,t,l,r和ac,at,al,ar,分别是按照query次数,时间,lock的时间和返回的记录数来排序,前面加了a的时倒叙
-t,是top n的意思,即为返回前面多少条的数据
-g,后边可以写一个正则匹配模式,大小写不敏感的
mysqldumpslow -s c -t 20 host-slow.log
上述命令可以看出访问次数最多的20个sql语句
mysqldumpslow -s r -t 20 host-slow.log
上述命令可以看出返回记录集最多的20个sql。
mysqldumpslow -t 10 -s t -g “left join” host-slow.log
这个是按照时间返回前10条里面含有左连接的sql语句
-s ORDER what to sort by (t, at, l, al, r, ar etc), ‘at’ is default
-t NUM just show the top n queries
-g PATTERN grep: only consider stmts that include this string
-s,是order的顺序,主要有c,t,l,r和ac,at,al,ar,分别是按照query次数,时间,lock的时间和返回的记录数来排序,前面加了a的时倒叙
-t,是top n的意思,即为返回前面多少条的数据
-g,后边可以写一个正则匹配模式,大小写不敏感的
mysqldumpslow -s c -t 20 host-slow.log
上述命令可以看出访问次数最多的20个sql语句
mysqldumpslow -s r -t 20 host-slow.log
上述命令可以看出返回记录集最多的20个sql。
mysqldumpslow -t 10 -s t -g “left join” host-slow.log
这个是按照时间返回前10条里面含有左连接的sql语句
使用内存作linux下的临时文件夹
[ 2009/08/17 18:37 | by selboo ]
从理论上来说,内存的读写速度是硬盘的几十倍,性能应该会有所提升
在一些访问量比较高的系统上,通过把一些频繁访问的文件,比如session 放入内存中,能够减少很多的iowait,大大提高服务器的性能
在/etc/fstab中加入一行:
none /tmp tmpfs defaults 0 0
重启后生效
或者在/etc/rc.local中加入
mount tmpfs /tmp -t tmpfs -o size=128m
其中size=128m 表示/tmp最大能用128m
或
mount tmpfs /tmp -t tmpfs
不限制大小,这种情况可以用到2G内存,用 df -h 可以看到
tmpfs 2.0G 48M 2.0G 3% /tmp
注:不管哪种方式,只要linux重启,/tmp下的文件全部消失
另外,在一个正在运行的系统上运行 mount tmpfs /tmp -t tmpfs 会导致 /tmp下原来的所有文件都会被“覆盖”掉,之所以加个“”,因为这种覆盖只是暂时的,如果 umount /tmp的话,原来的文件还能再访问。
因为这些文件会被“覆盖”,比如原来的session mysql.sock等文件就不能访问了,用户的登陆信息就会丢失,mysql数据库也无法连接了(如果mysql.sock位于/tmp下的话)。
正确的做法是,先把/tmp下的所有文件临时mv到一个别的目录,mount tmpfs之后,再mv回来
在一些访问量比较高的系统上,通过把一些频繁访问的文件,比如session 放入内存中,能够减少很多的iowait,大大提高服务器的性能
在/etc/fstab中加入一行:
none /tmp tmpfs defaults 0 0
重启后生效
或者在/etc/rc.local中加入
mount tmpfs /tmp -t tmpfs -o size=128m
其中size=128m 表示/tmp最大能用128m
或
mount tmpfs /tmp -t tmpfs
不限制大小,这种情况可以用到2G内存,用 df -h 可以看到
tmpfs 2.0G 48M 2.0G 3% /tmp
注:不管哪种方式,只要linux重启,/tmp下的文件全部消失
另外,在一个正在运行的系统上运行 mount tmpfs /tmp -t tmpfs 会导致 /tmp下原来的所有文件都会被“覆盖”掉,之所以加个“”,因为这种覆盖只是暂时的,如果 umount /tmp的话,原来的文件还能再访问。
因为这些文件会被“覆盖”,比如原来的session mysql.sock等文件就不能访问了,用户的登陆信息就会丢失,mysql数据库也无法连接了(如果mysql.sock位于/tmp下的话)。
正确的做法是,先把/tmp下的所有文件临时mv到一个别的目录,mount tmpfs之后,再mv回来
rsync的一些更安全的用法
[ 2009/08/17 18:34 | by selboo ]
总的来说,开在873端口之后,只要加上验证口令,安全性就有保障了,但毕竟多开一个端口,而且rsync的密码是明文方式存储的,相对来说,还是有被监听的可能。根据不同的情况采用下述不同方案,相对来说,安全性更高一些
1。如果只是本机备份,不需要启动darmon,直接用
/usr/bin/rsync -vzrtopglq --size-only --progress --delete /data/htdocs /backup
2。如果只是内网中的机器互备,可以让rsync只监听在内网的ip上
启动daemon的时候,用参数 --address 可以让rsync只监听在内网的192.168.0.10这个ip上
rsync --daemon --address 192.168.0.10
3。通过公网备份的话,可以将rsync监听在非873端口,增加安全性
启动daemon的时候,用参数 --port 可以让rsync监听在 非873端口
rsync --daemon --port 1873
4。如果还觉得不够安全,可以不启用daemon,通过ssh做备份,更安全和方便一些
在客户端是用命令
/usr/bin/rsync -vzrtopgl --size-only --progress --delete -e ssh root@www.admin99.net:/usr/local/httpd/htdocs/ /backup/admin99
即可以通过ssh端口来做备份,rsync会调用远端的rsync命令来处理相关操作
如果远端机器的ssh开在非22端口的话,可以通过 -p参数来指定ssh的端口
/usr/bin/rsync -vzrtopgl --size-only --progress --delete -e 'ssh -p1089' root@www.admin99.net:/usr/local/httpd/htdocs/ /backup/admin99
如果不想每次备份都手工输入ssh的密码的话,可以参考这里使用scp、ssh等不用输入密码
1。如果只是本机备份,不需要启动darmon,直接用
/usr/bin/rsync -vzrtopglq --size-only --progress --delete /data/htdocs /backup
2。如果只是内网中的机器互备,可以让rsync只监听在内网的ip上
启动daemon的时候,用参数 --address 可以让rsync只监听在内网的192.168.0.10这个ip上
rsync --daemon --address 192.168.0.10
3。通过公网备份的话,可以将rsync监听在非873端口,增加安全性
启动daemon的时候,用参数 --port 可以让rsync监听在 非873端口
rsync --daemon --port 1873
4。如果还觉得不够安全,可以不启用daemon,通过ssh做备份,更安全和方便一些
在客户端是用命令
/usr/bin/rsync -vzrtopgl --size-only --progress --delete -e ssh root@www.admin99.net:/usr/local/httpd/htdocs/ /backup/admin99
即可以通过ssh端口来做备份,rsync会调用远端的rsync命令来处理相关操作
如果远端机器的ssh开在非22端口的话,可以通过 -p参数来指定ssh的端口
/usr/bin/rsync -vzrtopgl --size-only --progress --delete -e 'ssh -p1089' root@www.admin99.net:/usr/local/httpd/htdocs/ /backup/admin99
如果不想每次备份都手工输入ssh的密码的话,可以参考这里使用scp、ssh等不用输入密码
开启 Apache Server Status
[ 2009/08/17 18:19 | by selboo ]
Apache 1.3.2及以后的版本中就自带一个查看Apache状态的功能模块server-status
一般默认状态下,apache安装的时候已经将mod_status模块安装了,只是模式情况下没有启用
在httpd.conf中,找到
引用
将其中的 .example.com 改为自己的域名,比如www.admin99.net
将前面的注释去掉,重启apache,即可通过 http://www.admin99.net/server-status来访问。
可以通过http://www.admin99.net/server-status?refresh=5来自动刷新当前的状态信息,5秒刷新一次
另外,如果想要看当前的详细请求信息的话,可以将
引用
ExtendedStatus On
一般默认状态下,apache安装的时候已经将mod_status模块安装了,只是模式情况下没有启用
在httpd.conf中,找到
引用
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from .example.com
</Location>
SetHandler server-status
Order deny,allow
Deny from all
Allow from .example.com
</Location>
将其中的 .example.com 改为自己的域名,比如www.admin99.net
将前面的注释去掉,重启apache,即可通过 http://www.admin99.net/server-status来访问。
可以通过http://www.admin99.net/server-status?refresh=5来自动刷新当前的状态信息,5秒刷新一次
另外,如果想要看当前的详细请求信息的话,可以将
引用
ExtendedStatus On
mysql 优化的一些小窍门
[ 2009/08/17 18:16 | by selboo ]
* 针对Innodb表,尽量不执行SELECT COUNT(*)语句,因为Innodb表没有类似MyISAM那样的内部计数器来记录表记录总量,执行这个操作将会全表扫描,速度很慢.
* 尽量使用MyISAM表,除非必须使用其他类型,因为MyISAM类型的总体读写效率是相当高的,缺点是表级锁,而不是行/页级锁.
* 善用EXPLAIN来帮助你分析查询优化情况
* 如果需要对一个较大的且并发读写较多的数据表做GROUP BY等统计操作,建议使用摘要表来存储统计信息,定期更新统计表,这可能获得很大的性能改善.
* 查询时如果有ORDER BY分句的话,注意让它的字段顺序和索引字段顺序对应,这样能加快排序速度
* 如果有一个多字段索引,则查询时,必须按照索引顺序来使用,否则该索引不会用到.例如:
索引`idx_`(col1, col2, col3),那么查询SELECT .... FROM ... WHERE col1=1 AND col2=2;使用索引,而查询... WHERE col2=2 AND col3=3;或... WHERE col1=1 AND col3=3;则不使用索引.
* WHERE中的条件如果有恒量类型的(如 `field` = 1),就尽量放在前面,这样能更快的执行过滤.
* 2 个表连接时,连接字段的类型最好一致(包括字段长度),这样的话索引速度快多了.
* 大部分情况下,字符类型的字段索引值需要一部分,例如CREATE INDEX char_idx ON tbl1 ( name(10) );
* 尽量使用最合适的数据类型,能使用ENUM就不使用TINYINT,能使用SMALLINT就不使用MEDIUMINT.这样能节省存储空间,增加数据存储量,提高搜索速度.不要担心这样会对省级产生很大的影响,因为加入从TINYINT类型改变为INT的话,并不会改变原来的数据.
* 如果知道某个表总是频繁使用的话,可以把它放到hot_cache中,用以下方法:
SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX `xxx` IN hot_cache;
* 把拖沓复杂,速度慢的的查询分解成多个简洁明了的查询,这样尽管查询次数多了,但是总体速度和效率却可能反而更高了,而且也减少了锁表的可能.
* 执行查询时,尽量不使用外部函数,因为这样的话就无法使用可能存在的索引,并且无论如何都会极大地降低效率.如:... WHERE `create_time` > UNIX_TIMESTAMP(NOW());这样的查询.可以在程序中把当前的时间取得,然后直接执行构造好了的SQL语句.
* 在索引字段上使用 LIKE 查询时,左边不要使用 '%' 修饰符,这样就可以利用索引,否则无法使用索引.如... `name` LIKE 'yejr%';.
* 如果有可能,多使用存储过程,这大概能获得 22% 的性能提高.
* 如果并发访问量相对最大连接数小多了的话,最好使用永久连接,这样能节省不少连接时的系统资源损耗.
* 定期的在MyISAM表上执行OPTIMIZE TABLE,这能整理随便,提高索引效率.
* 如果你主要按 col1,col2,...顺序检索记录,请在对表大量更改后执行ALTER TABLE ... ORDER BY col1, col2, ...语句,这可以获得更好的性能.
* 对于频繁更改的MyISAM表,应尽量避免更新所有变长字段(VARCHAR、BLOB和TEXT).
* 对于记录总数超过500万的单表,就应该赶紧考虑分表了.分表策略有多种,比如按ID号段,或者按时间切分,等等.
* 创建数据表时尽量指定字段不能为NULL,并且有默认值.
* 使用LOAD DATA,而不是使用大批量的INSERT语句来导入数据.
* 使数据表名和字段名尽可能的短,例如在user表中使用字段名name,而不是user_name.
* 用DELAY_KEY_WRITE = 1选项让MyISAM更快地更新索引,因为在表关闭之前它们不刷新到硬盘上.缺点是如果服务器如果突然被杀掉了,重启之后就必须运行myisamchk修复索引才行.
* 采用复制机制来分摊读数据的负载,把写数据只放在主服务器上,把读平均分摊到各个从服务器上,能大大提高系统负载.
* 尽量使用MyISAM表,除非必须使用其他类型,因为MyISAM类型的总体读写效率是相当高的,缺点是表级锁,而不是行/页级锁.
* 善用EXPLAIN来帮助你分析查询优化情况
* 如果需要对一个较大的且并发读写较多的数据表做GROUP BY等统计操作,建议使用摘要表来存储统计信息,定期更新统计表,这可能获得很大的性能改善.
* 查询时如果有ORDER BY分句的话,注意让它的字段顺序和索引字段顺序对应,这样能加快排序速度
* 如果有一个多字段索引,则查询时,必须按照索引顺序来使用,否则该索引不会用到.例如:
索引`idx_`(col1, col2, col3),那么查询SELECT .... FROM ... WHERE col1=1 AND col2=2;使用索引,而查询... WHERE col2=2 AND col3=3;或... WHERE col1=1 AND col3=3;则不使用索引.
* WHERE中的条件如果有恒量类型的(如 `field` = 1),就尽量放在前面,这样能更快的执行过滤.
* 2 个表连接时,连接字段的类型最好一致(包括字段长度),这样的话索引速度快多了.
* 大部分情况下,字符类型的字段索引值需要一部分,例如CREATE INDEX char_idx ON tbl1 ( name(10) );
* 尽量使用最合适的数据类型,能使用ENUM就不使用TINYINT,能使用SMALLINT就不使用MEDIUMINT.这样能节省存储空间,增加数据存储量,提高搜索速度.不要担心这样会对省级产生很大的影响,因为加入从TINYINT类型改变为INT的话,并不会改变原来的数据.
* 如果知道某个表总是频繁使用的话,可以把它放到hot_cache中,用以下方法:
SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX `xxx` IN hot_cache;
* 把拖沓复杂,速度慢的的查询分解成多个简洁明了的查询,这样尽管查询次数多了,但是总体速度和效率却可能反而更高了,而且也减少了锁表的可能.
* 执行查询时,尽量不使用外部函数,因为这样的话就无法使用可能存在的索引,并且无论如何都会极大地降低效率.如:... WHERE `create_time` > UNIX_TIMESTAMP(NOW());这样的查询.可以在程序中把当前的时间取得,然后直接执行构造好了的SQL语句.
* 在索引字段上使用 LIKE 查询时,左边不要使用 '%' 修饰符,这样就可以利用索引,否则无法使用索引.如... `name` LIKE 'yejr%';.
* 如果有可能,多使用存储过程,这大概能获得 22% 的性能提高.
* 如果并发访问量相对最大连接数小多了的话,最好使用永久连接,这样能节省不少连接时的系统资源损耗.
* 定期的在MyISAM表上执行OPTIMIZE TABLE,这能整理随便,提高索引效率.
* 如果你主要按 col1,col2,...顺序检索记录,请在对表大量更改后执行ALTER TABLE ... ORDER BY col1, col2, ...语句,这可以获得更好的性能.
* 对于频繁更改的MyISAM表,应尽量避免更新所有变长字段(VARCHAR、BLOB和TEXT).
* 对于记录总数超过500万的单表,就应该赶紧考虑分表了.分表策略有多种,比如按ID号段,或者按时间切分,等等.
* 创建数据表时尽量指定字段不能为NULL,并且有默认值.
* 使用LOAD DATA,而不是使用大批量的INSERT语句来导入数据.
* 使数据表名和字段名尽可能的短,例如在user表中使用字段名name,而不是user_name.
* 用DELAY_KEY_WRITE = 1选项让MyISAM更快地更新索引,因为在表关闭之前它们不刷新到硬盘上.缺点是如果服务器如果突然被杀掉了,重启之后就必须运行myisamchk修复索引才行.
* 采用复制机制来分摊读数据的负载,把写数据只放在主服务器上,把读平均分摊到各个从服务器上,能大大提高系统负载.