Привет у меня есть таблица из 2-х поле
int1 / varchar 255
по varchar уникальный индекс. по нему будут искаться уникальные названия.
Как думаете, какую нагрузку выдержит такая таблица и не будет дедлоков?
Есть возможность немного денормализировать и добавить перед varchar дополнительное поле int2 и тогда сделать уникальным уже индекс: int2+varchar, чтоб как бы разгрузить SELECT
Стоит ли заморачиваться, как думаете?
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Полная Версия: varchar unic index
Есть ли У Вас есть возможность использовать составные индексы то используйте их с полями integer.
В этом случаи индексация по varchar 250 не имеет смысла,так как Вы делаете полное сканирование каждой строчки
В этом случаи индексация по varchar 250 не имеет смысла,так как Вы делаете полное сканирование каждой строчки
| Цитата |
| так как Вы делаете полное сканирование каждой строчки |
В каком смысле.???
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
mysql же использует индекс по varchar`у и сразу же находит ту единственную строку или о чем разговор?
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
| Цитата (ABC @ 21.02.2014 - 11:52) |
| mysql же использует индекс по varchar`у и сразу же находит ту единственную строку или о чем разговор? |
Если у Вас тексты разделяются по словам,то весь индекс будет в кэше.
В этой ситации разница будет не велика.
Посмотри как происходит кеширование varchar -> char
http://dev.mysql.com/doc/refman/5.0/en/char.html
Oyeme
А почему нет смысла использовать индекс по varchar, я не пойму почему?
А почему нет смысла использовать индекс по varchar, я не пойму почему?
| Цитата |
| Если у Вас тексты разделяются по словам,то весь индекс будет в кэше. |
Ну да...может я не понимаю, а в чем разница?
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Я наверное совсем отупел под конец дня я так и не нашел там нечего. Способ хранения, про кеширование вообще ничего нету.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Короче рещил сократить индекс до 48 знаков, чтоб на всякий случай. 
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Отмена... он же уникальный должен быть.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
он же уникальный должен быть.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
| Цитата |
| Короче рещил сократить индекс до 48 знаков, чтоб на всякий случай. |
Это не имеет смысла,потом-что если Вы используете 5 символов,будет использовано только 5 байт,если Вы используете 10 символов будет использовано 10 байт.
В char это же наоборо.Char - заполняет не использовано место пустой информацией.
| Цитата (ABC @ 21.02.2014 - 12:37) | ||
| Oyeme А почему нет смысла использовать индекс по varchar, я не пойму почему?
Ну да...может я не понимаю, а в чем разница? |
О каком количестве данных мы говорим?
Какая средняя длина информации будет у Вас в полях?
Как будет происходить поиск?Полными словами,по-символьно?
| Цитата |
| О каком количестве данных мы говорим? Какая средняя длина информации будет у Вас в полях? Как будет происходить поиск?Полными словами,по-символьно? |
Будет думаю 500-800 тысяч строк.
Средняя длинна по 20-40 символов.
Поиск целеком, без LIKE т.е. name=$var //полное соответствие
Нагрузка по времени...ну не так чтоб часто, типа поиска названий книг там где есть удобные каталоги и без поиска, но он предусмотрен и как раз насчет него вся морока.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
| Цитата (ABC @ 21.02.2014 - 13:48) | ||
Будет думаю 500-800 тысяч строк. Средняя длинна по 20-40 символов. Поиск целеком, без LIKE т.е. name=$var //полное соответствие Нагрузка по времени...ну не так чтоб часто, типа поиска названий книг там где есть удобные каталоги и без поиска, но он предусмотрен и как раз насчет него вся морока. |
Попробуйте использовать Index - fulltext так вы будете искать по полным словам.
Индекс индексирует "слова",что делает его быстрее чем поиск по символьно.
| Цитата |
| Попробуйте использовать Index - fulltext так вы будете искать по полным словам. |
там INNODB
мне не нужен fulltext, там будет полное соответствие по названиям документов. Как думаете с теми параметрами при таблице наполенной 800 тыс названиями.
При `name`='$var'//длинной, скажем 60 символов насколько тяжелым будет индекс, точнее будут ли дедлоки?
| Цитата |
| А что, дедлоки зависят от размера индекса? |
Я не могу спрогнозировать их причину в том, числе, но знаю. что это в том числе, когда железу тяжело.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Здесь расположена полная версия этой страницы.