Форум Сайтостроение Веб-строительство

Mysql всегда ли хороши индексы?

12
[Удален]
#11

в общем то чтобы убрать наверняка, ме надо поиграть с бд и запросами, но навскидку попробую наугад подсказать индекс который поможет. это будет индекс по 4 полям

alter table talk add index `dude` (user_id, talk_activity, talk_comments_qty, talk_last_comment_timestamp)

думаю что должно помочь, но может и не помочь, если не поможет, то "крутить" надо :)

dvaes
На сайте с 03.09.2007
Offline
65
dvaes
#12
bearman:
думаю что должно помочь, но может и не помочь, если не поможет, то "крутить" надо

+100500

желательно делайте индексы по нескольким полям, по которым идет выборка и сортировка. тогда filesort должен уйти в небытие. ну и смотрите каждый подбираемый индекс в explain)

[Удален]
#13
dvaes:
желательно делайте индексы по нескольким полям, по которым идет выборка и сортировка

мускуль еще не всегда любит "порядок" полей в индексе, иногда отказывается юзать :D, а поменяешь 2 поля местами и все залетает хах)

M
На сайте с 20.08.2004
Offline
376
Miracle
#14
bearman:
user_id, talk_activity, talk_comments_qty, talk_last_comment_timestamp

все 4 поля у меня в индексе , я экспериментировал только с talk_last_comment_timestamp

bearman:
мускуль еще не всегда любит "порядок" полей в индексе, иногда отказывается юзать , а поменяешь 2 поля местами и все залетает хах)

а как посоветуете тестами заниматься? достаточно ли того как делаю это я?

отец сыночка, лапочки дочки и еще одного сыночка
[Удален]
#15
Miracle:
все 4 поля у меня в индексе , я экспериментировал только с talk_last_comment_timestamp

покажите show create table talk;

M
На сайте с 20.08.2004
Offline
376
Miracle
#16
dvaes:
желательно делайте индексы по нескольким полям, по которым идет выборка и сортировка. тогда filesort должен уйти в небытие.

один индекс на несколько полей или как?

Miracle добавил 09.03.2010 в 18:06

вообщем, делал по всякому - filesort не уходит в бытие

Miracle добавил 09.03.2010 в 18:07

вот таблица

CREATE TABLE `talk` (
`talk_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(11) unsigned DEFAULT NULL,
`cat_id` tinyint(3) unsigned DEFAULT NULL,
`talk_topic` varchar(255) DEFAULT NULL,
`talk_text` text,
`talk_text_anonce` text,
`talk_activity` tinyint(1) unsigned DEFAULT '1',
`talk_status` tinyint(3) unsigned DEFAULT '0',
`talk_last_comment_timestamp` int(11) unsigned DEFAULT NULL,
`talk_comments_qty` int(6) unsigned DEFAULT '0',
`talk_timestamp` int(11) unsigned DEFAULT NULL,
`talk_tags` varchar(255) DEFAULT NULL,
`talk_user_ip` varchar(14) DEFAULT NULL,
`rate_pl` int(11) unsigned NOT NULL DEFAULT '0',
`rate_mi` int(11) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`talk_id`),
KEY `user_id` (`user_id`),
KEY `talk_timestamp` (`talk_timestamp`),
KEY `talk_last_comment_timestamp` (`talk_last_comment_timestamp`),
KEY `cat_id` (`cat_id`),
KEY `talk_activity` (`talk_activity`),
KEY `talk_comments_qty` (`talk_comments_qty`)
) ENGINE=MyISAM AUTO_INCREMENT=2585 DEFAULT CHARSET=utf8;
[Удален]
#17

дайте дампы, я поиграюсь, а? интересно стало :)

можно слать на ya@helldude.ru

bearman добавил 09.03.2010 в 18:08

обожаю мускуль оптимизировать, это лучше чем сео =))

тоже от тебя мало что зависит, можно только "помогать" и ждать результат :D

N
На сайте с 06.05.2007
Offline
419
netwind
#18

Действительно, запихайте побольше данных. Способ выполнения запроса у mysql зависит от текущих данных, а не только от структуры. С ростом объема он может поменяться и может случиться неприятный сюрприз.

Ваш случай специфический: несмотря на созданный индекс mysql прогнозирует почти то же самое число затронутых строк что и без индекса. Накладные расходы на последовательное считывание таблицы в произвольном порядке (ALL) как она лежит на диске могут оказаться меньше считывания в порядке индекса потому что файловые системы и диски легче справляются с последовательным чтением.

Что касается filesort : именно так обозначается сортировка вообще, не обязательно во временном файле, несмотря на слово file в названии. То есть не обязательно все очень плохо. Использование сложных составных индексов разумеется влияет на скорость обновления таблицы. Тут бы не перестараться изгоняя filesort.

Ну и выложите базу, поди не секреты какие.

Мне ваши результаты explain кажутся странными. Самый очевидный индекс следовало делать по talk_last_comment_timestamp, но похоже из-за desc он не используется. Комментарии ведь равномерно разложены во времени,а все остальные индексы с низкой селективностью. Данные в talk_last_comment_timestamp реальны или забиты мусором для тестирования ?

netwind добавил 09.03.2010 в 21:09

Вот пришел домой и попытался сгенерировать данные как смог - talk_last_comment_timestamp равномерно распределен среди 3000 записей. В моем "мусоре" все отлично : 


+----+-------------+-------+--------+---------------------------------+-----------------------------+---------+-------------------+------+-------------+

| id | select_type | table | type   | possible_keys                   | key                         | key_len | ref               | rows | Extra       |

+----+-------------+-------+--------+---------------------------------+-----------------------------+---------+-------------------+------+-------------+

|  1 | SIMPLE      | t     | index  | talk_activity,talk_comments_qty | talk_last_comment_timestamp | 5       | NULL              |   27 | Using where |

|  1 | SIMPLE      | u     | eq_ref | PRIMARY                         | PRIMARY                     | 4       | sehelp1.t.user_id |    1 |             |

+----+-------------+-------+--------+---------------------------------+-----------------------------+---------+-------------------+------+-------------+
Кнопка вызова админа ()
12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий