显然,慢日志现在正在工作。你知道是什么解决了这个问题吗?
同时,这已经演变为查询调优......
#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
在#2?这可能会阻止从 开始st
,这可能对 更具选择性INDEX(language, status)
。
在 #3 中:wp_terms 可能会受益于INDEX(name)
.
在#4:模式设计导致笨拙CONCAT('S', tax.taxonomy)
;可以纠正吗?也就是说,cant.element_type
和tax.taxonomy
look 一样——要么都带前缀,要么都没有?或者前缀可能是一个单独的列?
如果您想进一步讨论这些,请提供SHOW CREATE TABLE
和EXPLAIN SELECT ...
。