分类： Mysql/postgreSQL
2009-06-29 15:08:57
申明，以下的步骤是在查找一个已上线系统的性能问题时使用的，主要是针对mysql的性能调优。对于未上线系统，可以通过LR做压力来进行观察。思路是通用的^_^，步骤中的链接文章也在我的空间中，如果链接出问题，就麻烦大家自己翻一下了
1. 先分析慢查询，找出出现频率最多的慢查询语句，关于慢查询日志的使用和分析，参见“”。使用explain分析这些慢的语句，使用方法和相关参数含义，参见“”。如果语句优化效果不明显或没有优化空间，进入下一步
2. 分析show status的相关参数，查找是否参数设置不合理导致的问题，参见“”。修改相关参数后仍然效果不明显或没有发现可以修改的参数，进入第三步
3. 使用show processlist命令，查看mysql中线程的状态，相关参数含义，参见“”。这个命令，最好在压力测试出现问题的时候使用，因为show processlist截取的是当前状态下的线程状态。附上一个脚本，用于截取此命令的数据并保存到文本中。建议取的间隔时间在5s以上，否则可能对服务器造成一定的压力。
_date=`date +%y-%m-%d`
_time=`date +%H:%M`
_dir=/root/process/
_log=$_dir$_date.log
touch $_log
echo begin at $_time:>>$_log
for ((i=1;i<2;)) do
date +%H:%M:%S>>$_log
/usr/local/mysql/bin/mysqladmin processlist -u root –p123>>$_log
sleep 5s
done
说明：绿色部分为mysql地址，-u后是你的用户名，-p后是mysql的密码
脚本保存在.sh文件里，需要先转换成可执行文件。然后用./文件名来执行。注意，这样执行是在前台执行。可以用at来提交作业到后台执行。但是不建议。
对于show processlist中出现大量锁的情况，有以下两种可能。
因为我们的表类型是myisam，采用的是表级锁。我只针对这种情况进行分析。对于innoDB类型（采用行级锁），因为是事务型的表，一旦出现琐的情况，就要考虑是否事务使用不当造成死锁。
言归正传。因为表级别的锁不会出现死锁，但是mysql对这种表的规定是，写锁的级别高于读锁。如果有一个update操作作用于表A，那么所有作用于表A的操作都会被锁。所以，如果表A的update操作很频繁，建议不要使用myisam表。另一个针对mysiam表的锁的情况是：如果一个select操作很慢，在他结束之前，如果出现一个update操作，根据锁的优先级别，所有其他的查询操作全部被锁。这种情况，首先考虑优化那个慢的查询语句。如果没有优化空间，可以考虑拆分表或复制表的方式。我们的系统就是第二种原因，后来把那个功能暂时屏蔽了之后系统就恢复了正常。
有一篇文章也写了类似的情况，链接地址：http://ms.mblogger.cn/shimmer/posts/22320.aspx
里面还有一些关于mysql优化的一些经验，值得一看。
