标签: filesort

我正在开发一个事件跟踪系统,该系统使用少量查找表以及主要日志记录表.在我正在编写的报告中,可以选择一个对象来查看统计信息.界面按重要性降低(即命中)的顺序显示所有对象.

这两个表的架构(略微修剪,但你得到了要点):

CREATE TABLE IF NOT EXISTS `event_log` (
  `event_id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(5) DEFAULT NULL,
  `object_id` int(5) DEFAULT NULL,
  `event_date` datetime DEFAULT NULL,
  PRIMARY KEY (`event_id`),
  KEY `user_id` (`user_id`),
  KEY `object_id` (`object_id`)
);

CREATE TABLE IF NOT EXISTS `lookup_event_objects` (
  `object_id` int(11) NOT NULL AUTO_INCREMENT,
  `object_desc` varchar(255) NOT NULL,
  PRIMARY KEY (`object_id`)
);

我遇到问题的查询如下.它与我的约100个条目的表一起工作正常,但是EXPLAIN让我有点担心.

    explain SELECT 
            el.object_id, 
            leo.object_desc, 
            COUNT(el.object_id) as count_rows
        FROM 
            event_log el 
            LEFT JOIN lookup_event_objects leo ON leo.object_id = el.object_id
        GROUP BY 
            el.object_id
        ORDER BY …

我打算使用这个SQL SELECT创建一个视图,但它的解释显示它使用临时和使用filesort.我无法弄清楚我需要什么指数才能解决这个问题.大多数情况下,我想知道为什么它使用fileort intead使用索引进行排序.

这是我的表格:

CREATE TABLE `learning_signatures` (
  `signature_id` int(11) NOT NULL AUTO_INCREMENT,
  `signature_file` varchar(100) NOT NULL,
  `signature_md5` varchar(32) NOT NULL,
  `image_file` varchar(100) NOT NULL,
  PRIMARY KEY (`signature_id`),
  UNIQUE KEY `unique_signature_md5` (`signature_md5`)
) ENGINE=InnoDB AUTO_INCREMENT=640 DEFAULT CHARSET=latin1

CREATE TABLE `learning_user_suggestions` (
  `user_suggestion_id` int(11) NOT NULL AUTO_INCREMENT,
  `signature_id` int(11) NOT NULL,
  `ch` char(1) NOT NULL,
  `time_suggested` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `user_id` int(11) NOT NULL,
  PRIMARY KEY (`user_suggestion_id`),
  KEY `char_index` (`ch`),
  KEY `ls_sig_id_indx` (`signature_id`),
  KEY `user_id_indx` (`user_id`),
  KEY `sig_char_indx` (`signature_id`,`ch`)
) …

我有一个简单的MySQL查询,但是当我有很多的记录(目前103,0000),性能实在是太慢了,它说,它是使用文件排序,林不知道这是为什么它是缓慢的.有没有人建议加快它？或者使用filesort停止它？

MYSQL查询:

SELECT adverts .*    
FROM adverts
WHERE (
price >='0'
)
AND (
adverts.status = 1
)
AND (
adverts.approved = 1
)
ORDER BY date_updated DESC 
LIMIT 19990 , 10

解释结果:

id   select_type   table   type    possible_keys    key    key_len    ref    rows   Extra 
1    SIMPLE        adverts range   price            price  4          NULL   103854 Using where; Using filesort

这是广告表和索引:

CREATE TABLE `adverts` (
  `advert_id` int(10) NOT NULL AUTO_INCREMENT,
  `user_id` int(10) NOT NULL,
  `type_id` tinyint(1) NOT NULL,
  `breed_id` int(10) NOT NULL,
  `advert_type` tinyint(1) …

我有一个包含数千行内容(约300万)的Joomla表.我在查询表时尽可能快地重写数据库查询时遇到了一些麻烦.

这是我的完整查询:

SELECT cc.title AS category, a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.attribs, a.hits, a.images, a.urls, a.ordering, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email
FROM j15_content AS a
LEFT JOIN j15_categories AS cc …

我正在尝试优化此查询:

SELECT `posts`.* FROM `posts` INNER JOIN `posts_tags` 
     ON `posts`.id = `posts_tags`.post_id 
     WHERE  (((`posts_tags`.tag_id = 1))) 
     ORDER BY posts.created_at DESC;

表的大小是38k行,31k和mysql使用"filesort"因此它变得非常慢.我试着使用不同的索引,没有运气.

CREATE TABLE `posts` (
  `id` int(11) NOT NULL auto_increment,
  `created_at` datetime default NULL,
  PRIMARY KEY  (`id`),
  KEY `index_posts_on_created_at` (`created_at`),
  KEY `for_tags` (`trashed`,`published`,`clan_private`,`created_at`)
) ENGINE=InnoDB AUTO_INCREMENT=44390 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

CREATE TABLE `posts_tags` (
  `id` int(11) NOT NULL auto_increment,
  `post_id` int(11) default NULL,
  `tag_id` int(11) default NULL,
  `created_at` datetime default NULL,
  `updated_at` datetime default NULL,
  PRIMARY KEY  (`id`),
  KEY `index_posts_tags_on_post_id_and_tag_id` (`post_id`,`tag_id`) …

以下查询需要25秒,有2个表连接.第一个帖子表有150,00行,主题表有50,000行.任何人都知道如何加快速度.

SELECT SQL_NO_CACHE
  post_search.post_id,
  topic_search.topic_id,
  topic_search.topic_title,
  topic_search.topic_last_post_time,
  MATCH(post_search.post_text,topic_search.topic_title) AGAINST('search_terms' IN BOOLEAN MODE) AS score
FROM bb_posts_fulltext_search post_search
LEFT JOIN bb_topics_fulltext_search topic_search
  ON post_search.topic_id = topic_search.topic_id
WHERE MATCH(post_search.post_text,topic_search.topic_title) AGAINST('search_terms' IN BOOLEAN MODE)
GROUP BY topic_search.topic_id
ORDER BY score DESC
LIMIT 0,6

描述

mysql> DESCRIBE bb_posts_fulltext_search;
+-----------+------------+------+-----+---------+-------+
| Field     | Type       | Null | Key | Default | Extra |
+-----------+------------+------+-----+---------+-------+
| post_id   | bigint(20) | NO   | PRI | NULL    |       |
| post_text | longtext   | YES  | MUL | …

可能我错过了一些愚蠢的事情......显然MySQL 5.1仍然在做一个Filesort,即使有一个索引与ORDER BY子句中的列完全匹配.要在此发布,我已经过度简化了数据模型,但问题仍然存在:

表定义:

CREATE TABLE `event` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `owner_id` int(11) DEFAULT NULL,
  `date_created` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `owner_id` (`owner_id`),
  KEY `date_created` (`date_created`),
  CONSTRAINT `event_ibfk_1` FOREIGN KEY (`owner_id`) REFERENCES `user_profile` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;

我的问题是,一个简单的SELECT事件显示"正在使用filesort":

explain select * from event order by date_created desc;

并且查询的结果解释了:

id  select_type table   type    possible_keys   key key_len ref rows    Extra   
1   SIMPLE      event   ALL NULL        NULL    NULL    NULL    6       Using filesort

有没有办法让这种类型的查询使用执行filesort的索引insteas？ …

MySQL似乎没有使用索引,并在以下查询中使用filesort:

  SELECT `tweets`.* 
    FROM `tweets` 
   WHERE (`tweets`.contest_id = 159) 
ORDER BY tweet_id ASC, tweeted_at DESC LIMIT 100 OFFSET 0

我有关于contest_id,tweet_id和tweeted_at的索引

当我执行时EXPLAIN EXTENDED,Extra返回"使用where;使用filesort".如何改进查询？

在一个简单但非常大的InnoDB表,我对A列的唯一索引,我想在(整数)列A的为了得到(整数)B列的列表

非常简单的查询,我正在翻阅数百万条记录.

SELECT B FROM hugeTable ORDER BY A LIMIT 10000 OFFSET 500000

在非常快的服务器上每次查询需要10秒钟？

Filesort: Yes Filesort_on_disk: Yes Merge_passes: 9

这对我来说没有意义,为什么它不能使用索引A？

说明显示简单,没有可能的键和文件.

我有两个简单的表:

CREATE TABLE cat_urls (
  Id int(11) NOT NULL AUTO_INCREMENT,
  SIL_Id int(11) NOT NULL,
  SiteId int(11) NOT NULL,
  AsCatId int(11) DEFAULT NULL,
  Href varchar(2048) NOT NULL,
  ReferrerHref varchar(2048) NOT NULL DEFAULT '',
  AddedOn datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  GroupId int(11) DEFAULT NULL,
  PRIMARY KEY (Id),
  INDEX SIL (SIL_Id, AsCatId)
)

CREATE TABLE products (
  Id int(11) NOT NULL AUTO_INCREMENT,
  CatUrlId int(11) NOT NULL,
  Href varchar(2048) NOT NULL,
  SiteIdentity varchar(2048) NOT NULL,
  Price decimal(12, 2) NOT NULL,
  IsAvailable bit(1) NOT NULL, …