现在我陷入了一段时间,Select_full_join的数量不断增加。
我使用的是“log-queries-not-using-indexes”,我查看了mysql-slow.log,发现了很多类似这样的查询:
# Time: 131106 16:44:51
# User@Host: XXX @ localhost []
# Query_time: 0.000497 Lock_time: 0.000061 Rows_sent: 1 Rows_examined: 0
SET timestamp=1383752691;
SELECT COUNT(*) AS expression
FROM
(SELECT 1 AS expression
FROM
com_c_jobs_listing cj
WHERE (category IN ('Operations', 'Business Development', 'Sales/Account Management', 'R&D', 'Internal IT')) AND (country IN ('Brazil', 'China', 'France', 'Germany', 'Italy', 'Japan', 'Korea', 'Netherlands', 'Russia', 'United Kingdom', 'United States')) ) subquery;
我不明白为什么这是记录。而且,有一个索引的类别和国家。
我想我漏掉了什么但是我找不到...
以下是解释查询的结果:
id select_type表类型可能的密钥密钥key_len引用行额外
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL NULL选择优化掉的表2 DERIVED cj范围类别、国家/地区类别302 NULL 86使用where
我该怎么办?有主意吗?
2条答案
按热度按时间webghufk1#
根据您的详细说明(此处截断):
您可以看到为派生子查询选择了一个键,但是父查询依赖于派生表,因此没有索引(没有可能的键)。
为什么要使用子查询而不直接计算行数呢?
92dk7w1h2#
log-queries-not-using-indexes
设置就是这样做的,它记录不使用索引的查询,但是,为了使查询计入select_full_join
,它必须是一个导致全表扫描的 join。虽然文档没有解释如何跟踪这些查询,可以查询
performance_schema.events_statements_history
表(并且是“current”和“history_long”兄弟)来查找实际的语句。该表包括列select_full_join
和select_full_range_join
,如果查询满足这些条件,则它们将为非零。sql_text
列将包含SQL本身,current_schema
将告诉您运行SQL的数据库。需要注意的是performance_schema事件表不会跟踪来自任何地方的每个查询,因此您可能需要定期查询该表,直到找到问题所在。