SQLinfo.ru - Все о MySQL Webew.ru: теория и практика веб-технологий

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

Задавайте вопросы, мы ответим

Вы не зашли.

#1 26.03.2011 21:22:18

Syegorius
Завсегдатай
Зарегистрирован: 29.10.2010
Сообщений: 28

оптимизация огромной бд

Доброе время суток, будте добры, подскажите пожалуста как быть - есть таблица в которой более 100 000 записей. В таблице такие поля:

rating, screen_id, user_id, screen_name, user_name, tags

сейчас не у одного поля не стоит никакого индекса (даже у user_id, screen_name) потому что они могут повторятся. Все запросы к этой таблице сортируются по убыванию ratingа, т.е думаю понятно - тот у кого выше рейтинг тот и первый типа так:

select * from screen_rating where tags like "%hello%" or name like "%hello%" order by rating desc limit 0, 10;

Выходя из этого, вопрос первый - как и какие проставить индексы так, что бы это все происходило быстрее, причем все данные могут повторятся и не одному из полей нельзя присваивать юник. Подозреваю что нужно использовать "примари", но скажу честно понятия не имею чей-то за индекс.

Теперь вопрос номер два - пользователь в поле поиска вводит, например "hello hi bye", потом скрипт делит это по пробелу и получается три слова. Подскажите как должен выглядить запрос, типа того что в верху, но что бы в таблице искались совпадения со всеми тремя словами, а не только с "hello".

И вопрос номер три - нужно всегда подсчитывать количество возможных полей, сейчас используется вот такой вот запрос:

select count(rating) as count from screen_rating where tags like "%hello%" or name like "%hello%";

Это для того чтоб пользователь видел сколько эл-тов в базе нашлось по его тегу. Если кто-то знает как можно уменьшить время, то тож маякните...

И еще хотелось спросить чем отличается MyIssam от InnoDB и какой из этих типов лучше использовать для огромных баз данных с огромными таблицами?

Всем спасибо за ответы!

Неактивен

 

#2 27.03.2011 00:38:48

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: оптимизация огромной бд

В том виде, в котором хранятся Ваши данные, уже ничего не сделаешь —
база обречена на провал. Можно попробовать сделать полнотекстовый
индекс над tags и name, но в этом случае Вам не удастся эффективно
сортировать по rating. Если это просто набор фиксированных слов, то
имеет смысл сделать отдельную табличку и сделать поиск по ней. В слу-
чае же полнотекстового индекса сортировка будет производиться в соот-
ветствии с релевантностью данных (что и является наиболее логичным).

Неактивен

 

#3 27.03.2011 00:58:22

Syegorius
Завсегдатай
Зарегистрирован: 29.10.2010
Сообщений: 28

Re: оптимизация огромной бд

Вообще вот эта таблица и является отдельной таблицей, которая обновляется раз в сутки, в нее заносятся данные из других таблиц, что бы как-то сократить время выполнения скрипта, потому что иначе скрипт будет вначале обращатся в таблицу screen, находить в ней все данные о screenах, а потом еще для каждого screenа искать в таблице user информацию о юзере, который этот скрин залил...
И если можно то намекните как всетаки создать запрос в котором можно сверять данные ячейки по нескольким шаблонам, как я это описал во втором вопросе, спасибо...

Неактивен

 

#4 27.03.2011 01:40:22

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: оптимизация огромной бд

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

Неактивен

 

#5 27.03.2011 03:36:44

Syegorius
Завсегдатай
Зарегистрирован: 29.10.2010
Сообщений: 28

Re: оптимизация огромной бд

Понял... вощем буду тогда дальше сидедеть разбираться...

Ну и все-таки по поводу запроса, который сверяет поля по нескольким словам как он должен выглядеть? Я все про то там где нужно найти все поля, в которых есть слова "hello, hi, bye", как он должен выглядеть?

Неактивен

 

#6 27.03.2011 03:56:43

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: оптимизация огромной бд

a LIKE '%hi%' OR a LIKE '%hello%'

Ну то есть если Вас устраивает то, что всегда достаются все данные из таблицы.
Если не устраивает, то надо таки делать полнотекстовый индекс и использовать
MATCH.

Неактивен

 

#7 27.03.2011 04:27:01

Syegorius
Завсегдатай
Зарегистрирован: 29.10.2010
Сообщений: 28

Re: оптимизация огромной бд

Понял, спасибо, буду разбираться.

Неактивен

 

#8 27.03.2011 17:49:22

Syegorius
Завсегдатай
Зарегистрирован: 29.10.2010
Сообщений: 28

Re: оптимизация огромной бд

Прочитал все про полнотекстовый индекс, вроде как разобрался, но не могу понять почему вы сказали "Можно попробовать сделать полнотекстовый
индекс над tags и name, но в этом случае Вам не удастся эффективно
сортировать по rating." Почему я не могу поставить полнотекстовый индекс для tags и name и индекс для rating?

Неактивен

 

#9 27.03.2011 19:04:46

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5842

Re: оптимизация огромной бд

Сделать индексов вы можете много, но при выборке используется только один индекс.

Неактивен

 

#10 27.03.2011 23:42:13

Syegorius
Завсегдатай
Зарегистрирован: 29.10.2010
Сообщений: 28

Re: оптимизация огромной бд

И снова извиняюсь за сверхневероятно тупые вопросы, но хотелось бы спросить, а как определяется по какому индексу искать, или этот индекс нужно указывать?

Неактивен

 

#11 28.03.2011 12:10:53

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5842

Re: оптимизация огромной бд

На этапе составления плана выполнения запроса оптимизатор решает какой индекс использовать в данном случае.
Иногда он может ошибаться и в таких случаях используют директивы use/force/ignore index
http://sqlinfo.ru/forum/viewtopic.php?id=231

Для лучшего понимания работы индексов советую посмотреть FAQ №5

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson