记录长时间的查询很有必要,这个对检查问题发生的原因有很大帮助,因为一般是长时间的查询会导致排队严重或者导致表锁定。
在配置文件里面加上几句即可:
看字面即可理解设置的含义了,设置多长时间算是长时间的查询,设置日志名称,最后是否记录没有使用索引的查询。
日志名称如果是用/开头的,要注意日志写入权限,否则会出错。用一个名称则会放置在数据库目录var内。
没有使用索引的查询可能会很多,如果有必要那可以记录,但日志会出现好多
分析日志主要是查找到哪些查询占用时间比较长,这样可以优化数据库和程序。
比如如下日志片段:
最简单的改善方案是给该表的 friendnum 字段加索引。
日志分析没有做过,可以参考一下别人写的工具介绍:五款常用mysql slow log分析工具的比较
原创内容如转载请注明:来自 阿权的书房
在配置文件里面加上几句即可:
long_query_time = 2
log_slow_queries = slow_queries
#log_queries_not_using_indexes = true
log_slow_queries = slow_queries
#log_queries_not_using_indexes = true
看字面即可理解设置的含义了,设置多长时间算是长时间的查询,设置日志名称,最后是否记录没有使用索引的查询。
日志名称如果是用/开头的,要注意日志写入权限,否则会出错。用一个名称则会放置在数据库目录var内。
没有使用索引的查询可能会很多,如果有必要那可以记录,但日志会出现好多
分析日志主要是查找到哪些查询占用时间比较长,这样可以优化数据库和程序。
比如如下日志片段:
引用
# Time: 090511 11:57:19
# User@Host: user[password] @ [192.168.1.2]
# Query_time: 5 Lock_time: 0 Rows_sent: 10 Rows_examined: 414839
SELECT (XXXX省略) ORDER BY s.friendnum DESC LIMIT 0,10;
# User@Host: user[password] @ [192.168.1.2]
# Query_time: 5 Lock_time: 0 Rows_sent: 10 Rows_examined: 414839
SELECT (XXXX省略) ORDER BY s.friendnum DESC LIMIT 0,10;
最简单的改善方案是给该表的 friendnum 字段加索引。
日志分析没有做过,可以参考一下别人写的工具介绍:五款常用mysql slow log分析工具的比较
原创内容如转载请注明:来自 阿权的书房
收藏本文到网摘
没有使用指定数据库会导致mysql同步失败
amoeba-mysql的安装使用和读写分离
