Огромные базы данных

Ну я бы так не говорил, просто в полях name, lastname могут быть по 2 имени (как бы русский и англ. вариант)

Конечно тут логичнее тогда добавить по полю чем использовать LIKE.

По поводу индексов, если ставить их на практически все поля, разве не будет база очень большой по размеру и не приведёт ли это к дополнительным тормазам, ведь при изменении/добавлении данных все индексы должны быть переписанны. (хотя скорее всего это происходит без проблем)

antono, по ID другие запросы и их намного больше, но думаю тормаза из за поиска по критериям..

лучше покажите explain на запрос

А это зависит от того, как вы работаете с базой.

Если инсертов и апдейтов больше чем селектов - то да, может быть и замедление из-за индексов.

Но в 99% баз, с которыми мне лично доводилось иметь дело, селекты выполняются на порядок(ки) чаще, чем инсерты/апдейты. И тут правильно построенные индексы дают огромный выигрыш в быстродействии.

ЗЫ Кстати, у вас наверняка не одна таблица в базе? И есть запросы с соединениями, причем не по примари ID? Сортировки, группировки? Там выигрыш от индексов будет еще заметнее.

AnNik добавил 11.03.2008 в 08:03

Разнести по разным полям не получится?

Действительно, чем думать что и как, посмотрите планы запросов - всё сразу станет ясно. Хотя если пользователей 100 штук, то индексы сильно не помогут.

Просто посмотрите план выполнения запросов, там будет все написано.

Врать не буду, точно не помню, но LIKE всегда смотрит во все записи.

Спасибо, буду разбираться.

Ещё такой вопрос по запросу на несколько таблиц

первая таблица users

вторая например fotos id(primary), user(index)

что эффекивнее, всем привычное

select * from fotos where user='$user[id]'

или

select * from fotos where id IN ($user[fotos])

где $user[fotos] список ИД фотографий(хранящийся в базе users) например 12,323,546,342 - скажем так до 50 фото

просто ведь если в базе, допустим 10млн записей с фото, то и пройтись по такому индексу тоже не просто.. а так получается сразу в запрос идут ID.

Кто знает, буду благодарен за ответ)

блесну нетривиализмом...

Таблица с фото по сути избыточна, т.к. эти просто 10млн никчемных записей... а потом еще и кейворды и тэги... бр... ссылки на фото, тэги и кейворды мы будем хранить прямо в таблице с анкетами в одном поле содержащем сеарелизованную структурку, вполне возможно ассоциированный массив... удобно до дуриков. ID фото тоже избыточно и мы обычно храним в этом месте хэш по которому лукапится в т.ч. и сервер/группа серверов которые могут отдать это фото, а следовательно формируется нужный URL в т.ч. с учетом загруженности ресурсов... 10млн тянет более 1Тб даже без тумб и прочих preview... далее мы повышаем эффективность query cache использованием одного запроса вида select * from users where userid=id, что сильно экономит нервы на частом просмотре ТОП-овых анкет.

Облака, поиск по кейвордам и т.д. отстраиваем в дополнительных статичных таблицах... индекс для поиска по названию делаем в педальном исполнении, т.е. по крону.

Базу делаем распределенной с дублированием нужного уровня, массовые репликации средствами БД ессесна идут в одно место и заменяются на юзер-левел по мере необходимости... балансинг между mysql-ями конечно же по хэшу, а для более оптимальной утрамбовки индекс по диаппазонам хэшей или id поддергиваемый функцией оптимизации и мониторинга... ну там если ТОПовые весчи надо совсем по всем задникам расдистрибутить или часть задников маркировать как выведенные из эксплуатации. Это так же позволяет использовать все железо что есть под рукой... можно цеплять любую петрушку и постепенно пригружать её до возможного максимума.

Следовательно под анкеты у нас есть две таблицы... первая для всех, а вторая для владельцев... свитчинг между таблицами автоматически происходит через какой-то временной интервал, что дает нам полностью неблокируемый select.... Можно и без этого изврата, но тогда придется городить еще что-то сверху... экономия нескольких мощных юнитов минимум.... т.е. кил 15 американский рублей.

от классиков жанра мы ушли куда-то совсем далеко... 10млн нам не так интересны... мы тут про 10млрд речь вели... кто не понял я не виноват.

зы обращайтесь за консультациями если что... дорого!

Разбейте поля на два: русское и английское. Дело в том, что LIKE '%xxx%' не использует индексы и это условие всегда будет приводить к медленному поиску. LIKE 'xxx%' же использует индексы. Сравнение - тем более. Лучше сделать два запроса типа LIKE 'xxx%', чем один LIKE '%xxx%' ;)

Приведёт. Но как Вы яхту сконструируете, так она и будет бегать. Если запросов на чтение намного больше, чем на запись, то нужно строить эти индексы.

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

ALTER TABLE `tb_users` ADD INDEX(`state`)

ALTER TABLE `tb_users` ADD INDEX(`country`)

Первое быстрее. При работе с memcached быстрее в сто-двести раз.

Где дэньги? ;)