Question

This is what I saw in slow-query.log

# User@Host: appUser[appUser] @  [192.168.1.10]
# Query_time: 65.118800  Lock_time: 0.000257 Rows_sent: 7  Rows_examined: 78056
SET timestamp=1312883519;
select 
    this_.id as id2_0_, 
    this_.appearance_count as appearance2_2_0_, 
    this_.author as author2_0_, 
    this_.date_added as date4_2_0_, 
    this_.date_last_ranked as date5_2_0_, 
    this_.date_updated as date6_2_0_, 
    this_.description as descript7_2_0_, 
    this_.frequency_updated as frequency8_2_0_, 
    this_.hidden as hidden2_0_, 
    this_.link as link2_0_, 
    this_.lock_id as lock11_2_0_, 
    this_.plain_text_description as plain12_2_0_, 
    this_.processor_done as processor13_2_0_, 
    this_.processor_lock_id as processor14_2_0_, 
    this_.published_date as published15_2_0_, 
    this_.raw_link as raw16_2_0_, 
    this_.retweet_count as retweet17_2_0_, 
    this_.source_url as source18_2_0_, 
    this_.subtype as subtype2_0_, 
    this_.thumbnail_img_url as thumbnail20_2_0_, 
    this_.title as title2_0_, 
    this_.total_hit_count as total22_2_0_, 
    this_.total_lift_count as total23_2_0_, 
    this_.total_share_count as total24_2_0_, 
    this_.trend_value as trend25_2_0_, 
    this_.type as type2_0_ 
from 
    news this_ 
where 
    exists (select 1 from news_sub_topic where this_.id=news_sub_topics_id) 
order by 
    this_.trend_value desc, 
    this_.retweet_count desc, 
    this_.total_lift_count desc, 
    this_.published_date desc 
limit 7;

this is what EXPLAIN gives:

+----+--------------------+----------------+------+--------------------------------------+-------------------+---------+------------------------+-------+-----------------------------+
| id | select_type        | table          | type | possible_keys                        | key               | key_len | ref                    | rows  | Extra                       |
+----+--------------------+----------------+------+--------------------------------------+-------------------+---------+------------------------+-------+-----------------------------+
|  1 | PRIMARY            | this_          | ALL  | NULL                                 | NULL              | NULL    | NULL                   | 50910 | Using where; Using filesort | 
|  2 | DEPENDENT SUBQUERY | news_sub_topic | ref  | FK420C980470B0479,FK420C98041F791FA1 | FK420C980470B0479 | 9       | causelift_web.this_.id |     1 | Using where; Using index    | 
+----+--------------------+----------------+------+--------------------------------------+-------------------+---------+------------------------+-------+-----------------------------+
2 rows in set (3.28 sec)

this is the CREATE sytax for the news and news_sub_topic table:

CREATE TABLE `news` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `appearance_count` int(11) NOT NULL,
  `author` longtext COLLATE utf8_unicode_ci,
  `date_added` datetime NOT NULL,
  `date_updated` datetime DEFAULT NULL,
  `description` longtext COLLATE utf8_unicode_ci,
  `link` longtext COLLATE utf8_unicode_ci,
  `published_date` datetime NOT NULL,
  `raw_link` longtext COLLATE utf8_unicode_ci,
  `subtype` varchar(5) COLLATE utf8_unicode_ci NOT NULL,
  `thumbnail_img_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `title` longtext COLLATE utf8_unicode_ci,
  `type` varchar(5) COLLATE utf8_unicode_ci NOT NULL,
  `date_last_ranked` datetime DEFAULT NULL,
  `lock_id` int(11) DEFAULT NULL,
  `plain_text_description` longtext COLLATE utf8_unicode_ci,
  `source_url` longtext COLLATE utf8_unicode_ci,
  `retweet_count` int(11) DEFAULT NULL,
  `frequency_updated` bit(1) DEFAULT NULL,
  `hidden` bit(1) DEFAULT NULL,
  `processor_done` bit(1) DEFAULT NULL,
  `processor_lock_id` int(11) DEFAULT NULL,
  `total_hit_count` int(11) DEFAULT NULL,
  `total_lift_count` int(11) DEFAULT NULL,
  `total_share_count` int(11) DEFAULT NULL,
  `trend_value` float DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `link_idx` (`link`(255)),
  KEY `type_idx` (`type`),
  KEY `processor_lock_id_idx` (`processor_lock_id`),
  KEY `processor_done_idx` (`processor_done`),
  KEY `hidden_idx` (`hidden`),
  KEY `title_idx` (`title`(255)),
  KEY `published_date_idx` (`published_date`)
) ENGINE=InnoDB AUTO_INCREMENT=321136 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


CREATE TABLE `news_sub_topic` (
  `news_sub_topics_id` bigint(20) DEFAULT NULL,
  `sub_topic_id` bigint(20) DEFAULT NULL,
  KEY `FK420C98045D8019D4` (`sub_topic_id`),
  KEY `FK420C980470B0479` (`news_sub_topics_id`),
  CONSTRAINT `FK420C98041F791FA1` FOREIGN KEY (`news_sub_topics_id`) REFERENCES `news` (`id`),
  CONSTRAINT `FK420C98045D8019D4` FOREIGN KEY (`sub_topic_id`) REFERENCES `sub_topic` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

anyone can explain why sometimes it took 65 seconds for this query to finish? but sometimes it is fast? what other factors should i look into (DB config, OS, etc.).

thanks for any leads on this.

Answer 1

my feeling is the ‘WHERE’ clause is your problem.

Try this code instead:

from 
    news this_ 
  inner join news_sub_topic topic on this.id=topic.news_sub_topics_id

The explanation is the because the lookup against news is using a filesort and not an index, likely because the where clause isn’t giving a good hint to the optimize.