Меню
Что нового?

Using filesort

antenne

Новичок
Using filesort

mysql> explain select * from search_index WHERE uid IN(119103, 144163, 71119, 88182, 76123, 94095, 135607, 113842, 13963, 2944) order by position;
+----+-------------+--------------+-------+-----------------+------+---------+------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------------+-------+-----------------+------+---------+------+------+-----------------------------+
| 1 | SIMPLE | search_index | range | uid,chunk_fetch | uid | 4 | NULL | 10 | Using where; Using filesort |
+----+-------------+--------------+-------+-----------------+------+---------+------+------+-----------------------------+


mysql> show create table search_index\G
*************************** 1. row ***************************
Table: search_index
Create Table: CREATE TABLE `search_index` (
`position` mediumint(8) unsigned NOT NULL default '0',
`uid` int(10) unsigned NOT NULL,
`sex` enum('M','F') NOT NULL,
`age` tinyint(3) unsigned NOT NULL,
`countryCode` tinyint(3) unsigned NOT NULL,
`cityCode` smallint(5) unsigned default NULL,
`havePhoto` tinyint(3) unsigned NOT NULL,
UNIQUE KEY `uid` (`uid`),
UNIQUE KEY `pos` (`position`),
KEY `chunk_fetch` (`uid`,`position`),
KEY `chunk_fetch_r` (`position`,`uid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)


нужно избавиться от filesort... диск нагружен, работает медленно

насколько я понимаю, мускуль выбирает индекс uid, потому как больше ему выбрать нечего,
затем, т.к. в индексе отсутствует Position - сортирует через файл

Есть предложения?
 
Wicked

Wicked

Новичок
сделать пару двойных индексов: (uid, position) и (position, uid), и посмотреть, какой из них будет использоваться... если будет :)
затем неиспользуемые индексы удалить.
 

antenne

Новичок
дык уже..

KEY `chunk_fetch` (`uid`,`position`),
KEY `chunk_fetch_r` (`position`,`uid`)

chunk_fetch используется, если удаляю uid, а filesort остается :)
 

Sender

Новичок
1. убрать ORDER BY посмотреть осталось ли filesort, будешь знать для какой операции он filesort юзает.

2. Попробоват напрямую указать какие индексы использовать.


А вообще должно работать нормально. может с памятью связано как-то...


ИМХО все... не претендует на абсолютную истину
 

Апельсин

Оранжевое создание
> убрать ORDER BY посмотреть осталось ли filesort, будешь знать для какой операции он filesort юзает.

ну да, а без этого очень сложно догадаться для какой части MySQL использует filesort.

А по теме у тебя range, а для range MySQL не может использовать вторую часть индекса для сортировки.
 

vovik

Новичок
Откуда уверенность что диск нагружен именно из-за этого filesort ? На основании чего такой вывод ?

Несмотря на то, что операция называется filesort, если размер буфера сортировки (sort_buffer_size) достаточен, то обращений к диску не будет. В главе мана "ORDER BY Optimization" это описано подробно.

В запросе выбирается 10 записей, имхо даже не самый большой буфер в состоянии их в себя вместить.
 

antenne

Новичок
Автор оригинала: vovik
Откуда уверенность что диск нагружен именно из-за этого filesort ? На основании чего такой вывод ?

Несмотря на то, что операция называется filesort, если размер буфера сортировки (sort_buffer_size) достаточен, то обращений к диску не будет. В главе мана "ORDER BY Optimization" это описано подробно.

В запросе выбирается 10 записей, имхо даже не самый большой буфер в состоянии их в себя вместить.
Нажмите для раскрытия...
Действительно, сейчас уже уверенности нет.
А как можно определить, из-за чего тормоза?
Время выполнения запроса колеблется от 2 до 80 миллисекунд, когда берется из query cache - 0.19 ms
 
Wicked

Wicked

Новичок
профайлер — подпрограмма протоколирования, позволяющая оценить время выполнения отдельных функций © lingvo

Реализация - дело десятое. Хоть microtime'ы в скрипт натыкай.
 

antenne

Новичок
Автор оригинала: Wicked
профайлер — подпрограмма протоколирования, позволяющая оценить время выполнения отдельных функций © lingvo

Реализация - дело десятое. Хоть microtime'ы в скрипт натыкай.
Нажмите для раскрытия...
microtime'ы натыканы, хотелось бы саму СУБД профилировать.. ну, syscalls чтоли?
 
flash-vkv

flash-vkv

Новичок
попробуй так
explain select * from search_index WHERE position > 0 AND uid IN(119103, 144163, 71119, 88182, 76123, 94095, 135607, 113842, 13963, 2944) order by position;
и индекс position
может помочь, еше можно попробовать сменить тип таблицы
а так все уже рассказали выше.
 
flash-vkv

flash-vkv

Новичок
вы наверно подумали я сума сошел :)
вот, по анологии с приведеным выше запросом проделал со своей похожей таблицей. запрос такой
[sql]
EXPLAIN SELECT *
FROM `t_info`
WHERE id_inf
AND id_street
IN ( 324, 686, 1637, 1835, 1649, 2071 )
ORDER BY id_inf
[/sql]
составной индекс id_inf+id_street
так вот при типе таблицы MyISAM выход такой
____________________________________________
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t_info ALL NULL NULL NULL NULL 2601 Using where; Using filesort
____________________________________________________
при InnoDB
____________________________________________

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t_info index NULL id_inf 8 NULL 2593 Using where
_____________________________________________________

думаю обьяснять выход нестоит
 

Апельсин

Оранжевое создание
flash-vkv, у вас совсем другая ситуация ..

а то для для InnoDB оно possible_keys показывает NULL, но таки использует составной индекс и type=index - это говорит о том, что это "не правильный индекса" но оно его использует для full index scan.

-~{}~ 22.09.06 13:01:

antenne, а сколько строк в таблице вообще?

-~{}~ 22.09.06 13:10:

Да и еще
2 секунды выполняется - это только когда первый раз к таблице обращаешься или всегда?
Если только первый, то оно просто индексы в кэш грузит.
 
Войдите или зарегистрируйтесь для ответа.
Сверху