Форум пользователей MySQL

Первый запрос, где меньше записей (id_zanr=15)

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra
id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra
1    SIMPLE    f    ref    PRIMARY,name_film_2,view_film,date_public,duration...    name_film_2    4    const    16569    Using where
1    SIMPLE    zf    eq_ref    id_zanr_2    id_zanr_2    8    zxkino.f.id_film,const    1    Using index

Второй запрос, где записей больше (id_zanr=5)

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra
1    SIMPLE    f    ref    PRIMARY,name_film_2,view_film,date_public,duration...    name_film_2    4    const    16569    Using where
1    SIMPLE    zf    eq_ref    id_zanr_2    id_zanr_2    8    zxkino.f.id_film,const    1    Using index

CREATE TABLE zanr_film (
  id_zanr int(11) NOT NULL,
  id_film int(11) NOT NULL,
  UNIQUE KEY id_zanr_2 (id_film,id_zanr)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Если убрать KEY id_zanr_2, то запрос, где записей меньше выполняется быстрее, а там, где их больше, медленее

Отредактированно humbert (04.05.2010 15:48:55)

Спасибо за помощь, но ситуация такая же. Играл с индексами, разные ставил. Либо быстро выбираются те, которых меньше, либо наоборот. Но вот чтобы оба варианта работало не получилось.

Да explain показывает одно и тоже на обоих запросах.

Спасибо за помощь и за потраченное время.

Если у Вас есть еще время и желание помочь (понять), то вот сами таблицы

CREATE TABLE films (
  id_film int(11) NOT NULL auto_increment,
  name_film varchar(255) NOT NULL,
  eng_film varchar(255) NOT NULL,
  duration_film int(11) NOT NULL,
  opis_film text,
  reiting_imdb float NOT NULL,
  year_film int(4) NOT NULL,
  trailer_url varchar(255) NOT NULL,
  slug_film varchar(255) NOT NULL,
  code_char_film int(11) default NULL,
  description_film text,
  door_title varchar(255) NOT NULL,
  door_keyword varchar(255) NOT NULL,
  door_description text,
  door_opis text,
  view_film int(11) NOT NULL,
  title_film varchar(255) NOT NULL,
  main_img varchar(255) NOT NULL,
  trailer_width int(11) NOT NULL,
  trailer_height int(11) NOT NULL,
  date_public int(11) NOT NULL,
  reiting_kinopoisk float NOT NULL,
  reiting_site float NOT NULL,
  keyword_film varchar(255) NOT NULL,
  peremen_film text NOT NULL,
  flag_film int(1) NOT NULL,
  PRIMARY KEY  (id_film),
  UNIQUE KEY slug_film (slug_film,code_char_film),
  KEY name_film (name_film)
) ENGINE=MyISAM AUTO_INCREMENT=16574 DEFAULT CHARSET=utf8;
       

CREATE TABLE zanr_film (
  id_zanr int(11) NOT NULL,
  id_film int(11) NOT NULL,
  PRIMARY KEY  (id_film,id_zanr)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

В films более 16.000 записей, в zanr_film более 25000, при этом id_zanr не более 25 штук всего. У некоторых фильмов несколько жанров. Из 25 жанров есть такие, у которых всего 24 фильма, а есть такие, у которых более 4.000 фильмов.

Нужно вывести список фильмов определенных жанров, и вот тут то и есть тормоза. Если стоит index в zanr_film по id_film, то быстрее всего выводится список для жанра, который имеет наибольшее количество фильмов. Если индекс отсутствует, то жанр с наименьшим количеством будет быстрее обрабатываться.

Не совсем врубаюсь, можно языком для даунов?

Мне 2 запроса делать к БД: сначала id_film из таблицы жанров, а потом конкретные фильмы?

Вот так?

Select *From films f, zanr_film zf where flag_film=1 and zf.id_film=f.id_film and id_zanr=5 order by name_film Limit 10

Если так, то выполняется 0.5 сек.

Да и Limit 10 мне не особо нужен, т.к. осуществляю постраничный вывод фильмов, т.е. используется и Limit 10000, 90

А с индексами пробовал по разному, нашел закономерность, если много фильмов в жанре, то ставим индекс на id_film

Alter Table zanr_film enable keys

,
если мало, то индекс убираем.

Alter Table zanr_film disable keys

Индекс стоит на id_film в zanr_film. Работает быстро.

Но опять уперся в Limit, если "Limit 0,90", то быстро (0.06 сек.) , если же "Limit 4734, 90", то примерно 1 сек. запрос выполняется.

Еще раз спасибо за помощь, за 10 лет, что работаю типа программистом, первый раз взялся изучать оптимизацию mysql

Спасибо, будем думать дальше, как оптимизировать работу. Возможно будет лучшим предусмотреть кеширование данных в файл и выдавать кеш. Правда тут возникает проблема актуальности данных, но что-нить придумаю.

Спасибо за помощь

Спасибо еще раз. Низко кланяюсь.