|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Есть вот такая таблица (упростил до минимума, она на самом деле больше):
Отредактированно Shopen (01.09.2010 12:08:06)
Неактивен
Наверное, это все-таки бага MySQL, но такова жизнь. Если он видит специальную
конструкцию MATCH … AGAINST — он всегда предпочитает использовать ее (более
того, она не сработает в случае отсутствия полнотекстового индекса на полях).
В Вашем случае, видимо, прийдется проверять вытащенную строку на клиентской
стороне 
Неактивен
Для этого придется сделать свой маленький полнотекствый поиск
Неожиданно, мда... Может какие то альтернативы есть? Думал сначала с подзапросом сделать, но к подзапроса MATCH уже не применишь. Остается совершенно феерический вариант делать временную(memory?) таблицу (с индексом name) туда вынимать результат запроса по ключу inn, и в ней уже искать с MATCH ))
Неактивен
А, если не секрет, какой там пример запроса внутри? Может, просто комбинация LIKE %word% сработает?
После вытаскивания 1-2 строк должно работать быстро.
Неактивен
Там произвольная фраза - наименование юридического лица, например "Открытое акционерное общество Вася Пупкин и Ко", так что просто %word% отделаться не получится. Кстати я заметил, что при некоторых inn mysql все таки использует индекс по этому полю. Например если inn="000000000000" или 606060606060 (таких записей не существует), значит все же не всегда. Зависимости пока не уловил.
Неактивен
При выборке из таблицы всегда используется максимум один индекс. Чрезвычайно
редко можно добиться INDEX_MERGE — он происходит тогда, когда можно легко
вытащить небольшое количество строк при OR (например WHERE f1 = 1 OR f2 = 2
при существовании индексов на (f1) и (f2) ). Индекс выбирается исходя из оценки
количества полученных строк.
Вы можете написать FORCE INDEX(inn), но, боюсь, что это не поможет, т.к. полно-
текстовый индекс — это таки индекс, и его можно или использовать, или нет. Если
использовать, то (как следует из первого правила) единственным образом. А MATCH()
использует индекс.
Неактивен
Про FORCE я еще в первом сообщении написал, что не помогает. Мне не нужно добиться одновременного использования индексов. Я не совсем понимаю почему в одних случаях mysql всё-таки использует индекс inn, а в других - нет. Т.е. если бы было как вы сказали в самом начале - что если есть match - то всегда используется fulltext - это было бы плохо, но понятно. Но я наткнулся (совершенно случайно) на то, что все таки при некоторых значениях inn - на MATCH mysql забивает
Это при том, что inn практически уникален. Кстати интересно, на уникальный ключ mysql тоже положит?
Отредактированно Shopen (01.09.2010 20:40:59)
Неактивен
Можно попробовать поисследовать этот вопрос. У меня ощущение, что он-использует другой индекс только в случае, когда тот выдает заведомо меньше записей (т.е. ноль).
Неактивен
Очень похоже что так и есть, что еще более странно.
Неактивен
Почему странно?
Неактивен
А как mysql определяет, что таких записей нет при explain, он что индекс просматривает? Ну если он это все равно делает, то обязан знать, что если такой inn существует - то там одна запись, ну две. И тем не менее игнорит этот индекс. Очень странное, имхо, поведение.
UPD. Интересно, если я разнесу эти два поля по разным таблицам и сделаю JOIN - он все равно приоритет матчу будет отдавать? Можно проверить, просто таблица большая, это долго, а может вы заранее знаете, что бесполезно
Отредактированно Shopen (03.09.2010 22:07:28)
Неактивен
Да, просматривает, и оценивает количество получаемых строк. Но сколько
строк достанется из FULLTEXT он без выполнения запроса не знает. Насколько
я понимаю, нам очень повезло, что там есть дополнительная проверка, что
если строк не вернется вообще. то и запрос выполнять не надо. В альтер-
нативном случае MySQL обязан использовать полнотекстовый индекс, потому
что MATCH он без индекса выполнить не сможет.
Если сделаете JOIN, то получите выборку id по полнотекстовому индексу,
и потом выборку остальных данных по id.
Неактивен
