日前项目中大规模合服后由于数据量猛增，一直问题不断。各种模块功能也一度无法开启，开发人员判断是服务等待时间过长，原因可能在数据库。需要分析数据库慢日志来定位具体问题。
由于开放至今合过的服的慢日志已达到1G以上，普通的切割文件方法分析起来效率太差，所以使用mysqldumpslow这一mysql自带的慢日志分析工具来进行分析。

mysqldumpslow使用说明
mysqldumpslow --help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

 --verbose    verbose
 --debug      debug
 --help       write this text to standard output

 -v           verbose
 -d           debug
 -s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default
               al: average lock time
               ar: average rows sent
               at: average query time
                c: count （出现次数）
                l: lock time
                r: rows sent
                t: query time
 -r           reverse the sort order (largest last instead of first) （从大到小排序）
 -t NUM       just show the top n queries （最高的n个查询）
 -a           don't abstract all numbers to N and strings to 'S'
 -n NUM       abstract numbers with at least n digits within names
 -g PATTERN   grep: only consider stmts that include this string
 -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),
              default is '*', i.e. match all
 -i NAME      name of server instance (if using mysql.server startup script)
 -l           don't subtract lock time from total time


可根据具体需求具体分析，例如：

分析出使用频率最高的前50条慢sql：

/usr/local/services/mysql/bin/mysqldumpslow -s c -t 50 VM_166_154-slow.log


如只需分析处理速度最慢的10条sql：

/usr/local/services/mysql/bin/mysqldumpslow -t 10 VM_166_154-slow.log



根据结果就可以对症下药，在对应的表和字段上添加索引了。