Непонятки с индесами

[ccop]

Непонятки с индексами

Есть таблица, которая состоит с, предположим, десятка полей.
На id, login, password, type, is_top, chk поставлена индексация.

и вот в phpMyAdmin напротив id и login стоит кол-во элементов - 109, а password, type, is_top, chk - "нету". Выходит, что для этих столбцов индекс небыл создан? Почему и как исправить ситуацию?
Спаисбо.

 

[Quessir]

В смысле??? Кол-во элементов? На полях? Ты имел ввиду у тебя на полях password... стоит NULL (пустота)?

 

[Vallar_ultra]

ccop

Поясни конкретнее: ЧТО ПРОИЗОШЛО НЕ ТАК? Индексы что-ли слетели или что?

 

[ccop]

Прошу прощения, некорректно сформулировал вопрос.

Вот так, думаю, будет лучше:
Есть таблица, которая состоит с, предположим, десятка полей.
На id, login, password, type, is_top, chk поставлена индексация, т.е. данные по этим столбцам должны индексироваться.

Теперь захожу в phpMyAdmin и вижу такое:

Имя ключа     Тип                 Количество элементов
id            PRIMARY              6
login 	      UNIQUE               6
type          INDEX                Нет
password      INDEX                Нет
is_top        INDEX                Нет
chk           INDEX                Нет

Не означает ли это, что по этим столбцам password, type, is_top, chk индексация не производиться?

 

[akd]

repair table?

 

[ccop]

Сработало. Но, когда я добавил новую записиь, кол-во индексов всеравно не изменилось. Такой вопрос: (не делать же постояно repair table) как можна настроить таблицу, что бы она при изменениях сама изменяла индексы?
Спасибо!

 

[Апельсин]

Это Cardinality. Тебе не нужно постоянно заниматься тем, что обновлять статистику. В большинстве случаев, то что надо СУБД обновит статистику сама.

 

[ccop]

Апельсин
Теперь я понял почему так медленно работала выборка, просто не было индексов. Можно как-то автоматизировать этот процесс? Указать, что бы СУБД сама при изменениях обновляла все индексы?

 

[Апельсин]

Индексы у тебя были, просто не было обновлено значение cardinality. СУБД переодически обновляет статистику сама, в большинстве случаев тебе вообще не стоит об этом беспокоится. А вообще для обновления cardinality используется ANALYZE TABLE. REPAIR перестраивает весь индекс и конечно тем самым обновляет статистику тоже, но за такое использование REPAIR надо дать в глаз (akd это к тебе относится между прочим ;Р).

Если ты хочешь узнать использует ли MySQL индексы, какие и сколько элементов при этом сканирует - используй EXPLAIN.

 

[akd]

Апельсин, а я и не предлагал ему делать repair после каждого инзерта.

 

[ccop]

Сайт у меня уже запущен где-то месяцев 6. И тока вот сейчас начал проверят ибо выборка что-то медленно работать стала. Вот, к примеру, есть табличка в которой 3175 записей, в поле "количество элементов" выдает "нет", сделал "ANALYZE TABLE" обновилось. Не уверен, что оно будет дальше само обновлять индексы и вообще, не будет ли конфликта, что в индексах будет 3175, а всего записей 4000, к примеру?

-~{}~ 01.02.07 02:22:

Кстати, вот когда сделал repair, вроде все нормально было, а сейчас смотрю, снова индексы сбились.
При запросе "SHOW INDEX FROM users"
в поле "Cardinality" выдает "NULL", но для PRIMARY id, все ок - 111.

-~{}~ 01.02.07 02:26:

Я понял, оно только Unique обновляет.