Задавайте вопросы, мы ответим
Вы не зашли.
Доброе время суток, будте добры, подскажите пожалуста как быть - есть таблица в которой более 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 и какой из этих типов лучше использовать для огромных баз данных с огромными таблицами?
Всем спасибо за ответы!
Неактивен
В том виде, в котором хранятся Ваши данные, уже ничего не сделаешь —
база обречена на провал. Можно попробовать сделать полнотекстовый
индекс над tags и name, но в этом случае Вам не удастся эффективно
сортировать по rating. Если это просто набор фиксированных слов, то
имеет смысл сделать отдельную табличку и сделать поиск по ней. В слу-
чае же полнотекстового индекса сортировка будет производиться в соот-
ветствии с релевантностью данных (что и является наиболее логичным).
Неактивен
Вообще вот эта таблица и является отдельной таблицей, которая обновляется раз в сутки, в нее заносятся данные из других таблиц, что бы как-то сократить время выполнения скрипта, потому что иначе скрипт будет вначале обращатся в таблицу screen, находить в ней все данные о screenах, а потом еще для каждого screenа искать в таблице user информацию о юзере, который этот скрин залил...
И если можно то намекните как всетаки создать запрос в котором можно сверять данные ячейки по нескольким шаблонам, как я это описал во втором вопросе, спасибо...
Неактивен
Раньше у Вас были разложены яблоки, груши и сливы по разным корзинкам. Но
Вы решили скинуть всё из корзинок в один большой таз, чтобы сократить время
работы человека, который будет их разбирать. Житейский опыт показывает, что
человеку Вы количество работы увеличили. Почему же в базе Вы считаете, что
уменьшили?
Неактивен
Понял... вощем буду тогда дальше сидедеть разбираться...
Ну и все-таки по поводу запроса, который сверяет поля по нескольким словам как он должен выглядеть? Я все про то там где нужно найти все поля, в которых есть слова "hello, hi, bye", как он должен выглядеть?
Неактивен
a LIKE '%hi%' OR a LIKE '%hello%'
Ну то есть если Вас устраивает то, что всегда достаются все данные из таблицы.
Если не устраивает, то надо таки делать полнотекстовый индекс и использовать
MATCH.
Неактивен
Понял, спасибо, буду разбираться.
Неактивен
Прочитал все про полнотекстовый индекс, вроде как разобрался, но не могу понять почему вы сказали "Можно попробовать сделать полнотекстовый
индекс над tags и name, но в этом случае Вам не удастся эффективно
сортировать по rating." Почему я не могу поставить полнотекстовый индекс для tags и name и индекс для rating?
Неактивен
Сделать индексов вы можете много, но при выборке используется только один индекс.
Неактивен
И снова извиняюсь за сверхневероятно тупые вопросы, но хотелось бы спросить, а как определяется по какому индексу искать, или этот индекс нужно указывать?
Неактивен
На этапе составления плана выполнения запроса оптимизатор решает какой индекс использовать в данном случае.
Иногда он может ошибаться и в таких случаях используют директивы use/force/ignore index
http://sqlinfo.ru/forum/viewtopic.php?id=231
Для лучшего понимания работы индексов советую посмотреть FAQ №5
Неактивен