我在.my.cnf中有以下内容
# LOGGING #
slow_query_log = ON
slow_query_log_file = /var/log/mariadb/slow_query.log
log-queries-not-using-indexes = 1当我运行tuning-primer.sh时,我得到这样的结果:
SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10.000000 sec.
You have 0 out of 36 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine有人能解释一下这是怎么回事吗?
发布于 2016-02-08 01:32:54
显然,慢速日志现在可以工作了。你知道是什么解决了这个问题吗?
同时,这已经演变为查询调优...
#1是用来做什么的?为什么它运行得如此频繁?它平均返回156K行(整个表?),但只返回665行。665行太多了;您真的需要全部行吗?在SQL中可以进行更多的过滤吗?
听起来好像没有INDEX(autoload) --添加它;它应该会大大加快查询速度。
#1
SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'S'你在用下面的几千行做什么?你在上千次地演绎它们吗?
#2
SELECT st.value AS tra, s.value AS org, s.domain_name_context_md5 AS ctx
FROM wp_icl_strings s
LEFT JOIN wp_icl_string_translations st ON s.id=st.string_id
AND st.status=N
AND st.language='S'
AND s.language!='S'
#3
SELECT slug, taxonomy
FROM wp_posts
INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id)
INNER JOIN wp_term_taxonomy ON (wp_term_relationships.term_taxonomy_id =
wp_term_taxonomy.term_taxonomy_id )
INNER JOIN wp_terms ON (wp_term_taxonomy.term_id = wp_terms.term_id )
WHERE wp_posts.ID IN ("S","S","S","S","S","S","S","S","S",...)
ORDER BY wp_terms.name ASC
#4
SELECT t.element_id, tax.term_id, tax.taxonomy
FROM wp_icl_translations t
JOIN wp_term_taxonomy tax ON t.element_id = tax.term_taxonomy_id
AND t.element_type = CONCAT('S', tax.taxonomy)
JOIN wp_terms terms ON terms.term_id = tax.term_id
WHERE tax.term_id != tax.term_taxonomy_id 为什么要把LEFT放在第二位?这可能会阻止从st开始,而使用INDEX(language, status)可能会更有选择性。
在#3: wp_terms可能会从INDEX(name)中受益。
在#4中:模式设计导致了笨拙的CONCAT('S', tax.taxonomy);这可以纠正吗?也就是说,t.element_type和tax.taxonomy看起来是否相同--要么都有前缀,要么都没有前缀?或者可能前缀是一个单独的列?
如果您想进一步讨论这些内容,请提供SHOW CREATE TABLE和EXPLAIN SELECT ...。
https://stackoverflow.com/questions/35117392
复制相似问题