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

MySQL 5.0.92-log

Есть таблица
CREATE TABLE `users` (
  /* МНОГО ПОЛЕЙ */
  PRIMARY KEY  (`user_id`),
  KEY `indx_user_session_time` (`user_session_time`),
  KEY `indx_user_active` (`user_active`),
  KEY `indx_user_lastvisit` (`user_lastvisit`),
  KEY `indx_user_regdate` (`user_regdate`),
  KEY `indx_user_from` (`user_from`),
  KEY `indx_user_email` (`user_email`),
  KEY `indx_user_posts` (`user_posts`),
  KEY `indx_user_website` (`user_website`),
  KEY `indx_username` (`username`),
  KEY `indx_user_lastvisit__user_birthday__username` (`user_lastvisit`,`user_birthday`,`username`),
  KEY `indx_user_weblog` (`user_weblog`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251

В ней первичный ключ и 11 вторичных.
Я знаю, что максимальная длина префиксов в innoDB не должна превышать 767 байт.
В этой таблице суммарная длина ключей явно меньше этого значения.

У меня был оптимизирован запрос на соединение с этой таблицей по индексу KEY `indx_user_weblog` (`user_weblog`), где user_weblog это INT(10).
На сколько я знаю, чем выше cardinality, тем лучше оптимизирован join. Всё хорошо. Cardinality был более 10000, точно не вспомню.

Но я создаю очередной индекс для VARCHAR(40)
KEY `indx_user_website` (`user_website`)
и cardinality KEY `indx_user_weblog` (`user_weblog`) резко падает до одного, двух. Естественно, в запросе join этот индекс перестал использоваться оптимизатором и он работает ужасно. Ключ также не используется, если применить USE INDEX или FORCE INDEX.

По правде говоря, поначалу длина VARCHAR была 100 для нескольких полей для которых были созданны индексы.
Это user_email, user_from, user_website.
То есть длина индексов была
`indx_user_session_time` - 4
`indx_user_active` - 3
`indx_user_lastvisit` - 4
`indx_user_regdate` - 4
`indx_user_from` - 103
`indx_user_email` - 103
`indx_user_posts` - 3
`indx_user_website` - 103
`indx_username` - 27
`indx_user_lastvisit__user_birthday__username` - 35
`indx_user_weblog` - 4

То есть явно меньше 767.
Но в торопях, я подумал, что больше, погорячился, уменьшил значения всех VARCHAR до 40.
Но дело было не в этом и это не помогло.
В итоге, я начал пересоздавать индексы и обнаружил, что теряет cardinality ПРЕДпоследний созданный индекс, причём если создаются все индексы, то есть его как бы выбивает почему-то последний созданный индекс.
Если не создаётся хотя бы один из списка (хотя проверял не по всем), то cardinality у всех в норме.

Я остановился на том, что создал предпоследним индекс `indx_user_website` , для которого теперь вычисляемый cardinality через SHOW INDEX FROM равен 1.
Но это поле не участвует в join-запросах, поэтому мне не страшно. Хотя этот индекс по-прежнему хорошо отрабатывает в обычном запросе на одну таблицу.

Вопрос, с чем связанно такое странное поведение? Может я упустил какой-то абзац в документации?

Отредактированно usershift (17.03.2011 01:52:33)