БД гигантского размера

Все ответы - примерные.

Нужен полный доступ.

Но заниматься бесплатно никто не будет (кроме школьников).

По сути, уже 5 примерно раз вам сказали куда копать.

а вы отнекиваетесь и цепляетесь за более простые, но не верные ответы.

И не нужно заниматься, тем более бесплатно, нужно направление задать нужное :)

Слабое место. Если лимит будет от 500 и выше, тормоза буду очень большие.

SELECT id2 FROM table WHERE id1 = ID ORDER BY ctr LIMIT limit

т.е. запрос по этим полям?

SELECT item_id FROM table WHERE keyword_id = ID ORDER BY ctr LIMIT limit

Именно для этого запроса нужен индекс по одному полю keyword_id

Запрос хороший и попадет в query_cache, дополнительного кеширования не нужно.

CREATE TABLE IF NOT EXISTS `cj` (

  `keyword_id` int(11) NOT NULL,

  `item_id` int(11) NOT NULL,

  `views` int(11) NOT NULL DEFAULT '0',

  `clicks` int(11) NOT NULL DEFAULT '0',

  `ctr` int(11) NOT NULL DEFAULT '0',

  PRIMARY KEY (`keyword_id`,`item_id`),

  KEY `keyword_id` (`keyword_id`,`item_id`,`ctr`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

"KEY `keyword_id` (`keyword_id`,`item_id`,`ctr`)" - бесполезный индекс будет только занимать место и тормозить при апдейтах таблицы. `keyword_id`,`item_id` - уникальны, каким боком сюда включать еще ctr?..

'PRIMARY KEY (`keyword_id`,`item_id`)' - желательно снести этот примари кей и пересоздать его как UNIQUE KEY keyword_item (`keyword_id`,`item_id`). Смысл тотже самый, но новые данные в табличку будут вставлятся быстрее.

Интересно было бы после этих изменений сравнить еще скорость InnoDB vs MyISAM.

sidorka, получилось сделать что-нибудь?

Зачем? Если там уже и так есть два индекса по этому полю. Как раз если смотреть на этот запрос, то здесь нужен составной индекс для WHERE и ORDER.

А есть ли два индекса?.. :)

Вопрос к Вам: почему индекс KEY `keyword_id` (`keyword_id`,`item_id`,`ctr`) никогда не будет использоваться и будет висеть мертвым грузом?

По скорости PRIMARY KEY (`keyword_id`,`item_id`) vs keyword_id выиграет keyword_id

Тут да, возможны варианты, т.к. на разных данных могут поочередно выигрывать, то один индекс, то другой. Нужно проводить замеры именно на боевой базе.

Я имею ввиду индексы keyword_id vs keyword_id, ctr

PRIMARY KEY + KEY `keyword_id`

SELECT item_id FROM table WHERE keyword_id = ID

не просто используется, а еще является покрывающем. Другой вопрос, что есть другой ключ - первичный + короче, такой же структуры и mysql явно предпочтет его.

SELECT item_id FROM table WHERE keyword_id = ID ORDER BY ctr

Index (Primay key) + filesort

Возможно. За то по скорости в запросе SELECT item_id WHERE keyword_id=ID выигрывает PRIMARY KEY. И смею предположить что даже с добавлением ORDER BY использования этого индекса будет быстрее простого.

Перешел с перконы на MariaDB - полегчало. С перконой не заладилось как-то - диск грузило сильно, хотя это скорее руки кривые.

Порекомендуйте оптимальный вариант рандомной выборки нескольких записей. Структура та же.

---------- Добавлено 26.02.2015 в 22:09 ----------

По индексам - и так, и сяк пробовал.

Сейчас так, возможно и лишнее что-то

CREATE TABLE IF NOT EXISTS `cj` (

  `keyword_id` int(11) NOT NULL,

  `item_id` int(11) NOT NULL,

  `views` int(11) NOT NULL DEFAULT '0',

  `clicks` int(11) NOT NULL DEFAULT '0',

  `ctr` int(11) NOT NULL DEFAULT '0',

  UNIQUE KEY `keyword_id` (`keyword_id`,`item_id`),

  KEY `keyword_id_2` (`keyword_id`),

  KEY `item_id` (`item_id`),

  KEY `ctr` (`ctr`),

  KEY `keyword_id_3` (`keyword_id`,`ctr`)

) ENGINE=Aria DEFAULT CHARSET=utf8 PAGE_CHECKSUM=0 ROW_FORMAT=DYNAMIC TRANSACTIONAL=0;