Допустим есть таблица keywords, в ней хранятся ключевые слова. Какой запрос будет наиболее быстрым в Mysql? P.S. точность поиска не важна, важна скорость, sphinx не предлагать.
Да, но LIMIT 1 можно убрать SELECT * FROM `keywords` WHERE keyword='$keyword' - такой запрос будет быстрее чем с LIKE и MATCH AGAINST?
если строка ТОЧНО совпадает с тем что в в бд тогда да но это не поиск а условие. а поиск это like %text% совпадение с частью строки
Для MATCH AGAINST - обязательно --- Добавлено --- Для больших проектов Sphinx, ElasticSearch и т.д. Там даже варианты с LIKE или MATCH не рассматриваются. А для маленьких проектов, где в лучше случае поисковой запрос раз в 30 секунд, я не особо парюсь. Впрочем, MATCH предпочтительней, т.к. не по всем строкам бегать будет. --- Добавлено --- Сейчас попалась страенькая статейка. Можете и оттуда взять инфу для собственной статистики.
Ну а при таком запросе - SELECT id,keyword FROM `keywords` WHERE keyword='$keyword' - индексы вообще не нужны?
Даже не знаю, как на такой вопрос ответить. Откуда я знаю, можету вас поле keyword с типом TEXT. То о каких индексах может идти речь. Индексы нужны там, где они нужны. Почитайте в документации. Как минимум, можно мониторить медленные запросы
Индексы - это сделка, вы платите увеличением времени записи за скорость чтения, соответственно нужны они лишь там, где эта сделка выгодна. К тому же, наличие индекса само по себе ничего не гарантирует, потому что планировщик может пойти с другого конца запроса и посчитать, что его использование будет дороже, чем простой перебор. Более того, нужно оценивать не только время исполнения запроса, но и его частоту: хитрый и долгий select выполняющийся раз в день, даже ускоренный в 10 раз даст меньше выгоды, чем десяток микросекунд на постоянно исполняющемся запросе, а связанные с ним накладные расходы на запись так вообще уведут пользу в минус. И это если не вдаваться в детали с разными типами индексов, уточняющими условиями, разбивкой на несколько запросов или наоборот, объединеним в один, вложенными select vs join, специфичными для конкретной СУБД особенностями, кэшированием и прочими сопутствующими вещами. Короче, если бы существовала универсальная метрика нужно / не нужно, то это бы уже давно добавили на уровне движков БД, а все остальные варианты кроме "быстрого" выпилили. А до тех пор - explain, slow log и теория наше всё )
давай уточним на всякий случай: ты собираешся хранить по одному слову в записи или кучу слов сразу? --- Добавлено --- https://bit.ly/2IE6zHJ - структура для ключевых слов: многие ко многим
Уже подготовленные ключевые слова из одного слова и словосочетания из двух слов(редко из трёх). Varchar 50.
это как быть немножко беременным если _иногда_ там более одного ключевого слова, это ломает схему. мой совет: сделай классически но до конца, чтобы всё работало — словарь слов и таблица связок. и только потом ищи другие варианты. нельзя не изучив нотную грамоту победить в конкурсе пианистов. --- Добавлено --- для "синонимов" / "вариантов" можно придумать таблицу синонимов. потом.