Примерный поиск по полю SQL ?

Хз, фуллтекст, на более менее объемах, на моих задачах, стабильно дает приемлемый результат. Прилично меньше 1сек на вполовину меньшее кол-во. Правда с недобазой скулайт. На Mysql, вероятно тоже самое - одно дело индекс, другое - перебрать все с регэксп. Давно не юзал Mysql

стеммер там какой? Плюс переколдовки, терминами яндекса.

Ну типа запрос "1000106 колец поршневых"

Никакой фуллтекст не поймет, что колец и кольца это одно и тоже. Даже со стеммером, лемматизация поможет.

mystem

колец

колец{кольцо}

кольца

кольца{кольцо}

В данном случае,

-- At line 1:

SELECT rowid, highlight(s, 0, "(*", "*)") as sku, highlight(s, 1, "[!", "!]") as name, price FROM s 

WHERE s MATCH '1000106 колец поршн* OR 1000106 кольц* поршн*' 

ORDER BY bm25(s);

-- Result: 12 rows returned in 18ms

при условии добавления

private $REPL = [
    'колец'=>'кольц', 'кольц'=>'колец',  'ремен'=>'ремн', 'ремн'=>'ремен', 'мод'=>'межосев дифференц',

    'межосев дифференц'=>'мод', 'коленвал'=>'коленчат', 'cummins'=>'камминз', 'камминз'=>'cummins',  'камминc'=>'cummins',

и т.д.

результат на картинко, а без этого - колец == кольц

SELECT rowid, highlight(s, 0, "(*", "*)") as sku, highlight(s, 1, "[!", "!]") as name, price FROM s 

WHERE s MATCH '1000106 колец поршн*'

-- Result: 0 rows returned in 3ms

Но, это не совсем верный запрос для поиска. Сам ищу.

фуллиндекс ИЗИ обрабатывает 2 ляма записей на обычном HDD, индекс потом вообще закидывается в памяти и диск более не трогается. И там поиск 0,001 секунды происходит.

%LIKE% вообще не использует индексы т.е. это полностью перебор всей таблицы при каждом запросе. А это может быть и 30 минут легко.

Добавлю

Без шума в виде номера. Т.е. запрос "колец поршневых"

Без колец == кольц

если так

SELECT rowid, highlight(s, 0, "(*", "*)") as sku, highlight(s, 1, "[!", "!]") as name, price FROM s 

WHERE s MATCH 'колец поршн*' ORDER BY bm25(s);

5115	И801.08.000	Метизы, рем. к-ты, подшипники: Приспособление для снятия и установки [!поршневых!] [!колец!] БИМЕТ	5140.0

если так

SELECT rowid, highlight(s, 0, "(*", "*)") as sku, highlight(s, 1, "[!", "!]") as name, price FROM s 

WHERE s MATCH 'колец OR поршн*' ORDER BY bm25(s);

то -- Result: 1877 rows returned in 28ms

И801.08.000	Метизы, рем. к-ты, подшипники: Приспособление для снятия и установки [!поршневых!] [!колец!] БИМЕТ	5140.0

30-404	Метизы, рем. к-ты, подшипники: Набор [!колец!] для ремонта РТИ (желтый)	502.0

30-382	Метизы, рем. к-ты, подшипники: Набор [!колец!] для ремонта РТИ (красный)	502.0

30-386	Метизы, рем. к-ты, подшипники: Набор [!колец!] для ремонта РТИ (синий)	502.0

5320-3506000У	Тормоза: Р/к (ремкомплект) [!колец!] трубопроводов тормозов 5 наим. 209 дет. КАМРТИ	520.0

3902286	Двигатель: Кольцо [!поршневое!] «Cummins»	138.0

С колец == кольц

SELECT rowid, highlight(s, 0, "(*", "*)") as sku, highlight(s, 1, "[!", "!]") as name, price FROM s 

WHERE s MATCH 'колец поршн* OR кольц* поршн*' ORDER BY bm25(s);

2445	740-1000106	Двигатель: [!Кольца!] [!поршневые!] (Кострома)

2446	740.30-1000106	Двигатель: [!Кольца!] [!поршневые!] ЕВРО-1, 2 Кострома

2447	740-1000106-01	Двигатель: [!Кольца!] [!поршневые!] ОАО «КамАЗ»

2448	740-1000106	Двигатель: [!Кольца!] [!поршневые!] ч/б

А всего то дали понять, что колец == кольц

---------- Добавлено 19.10.2019 в 02:01 ----------

И так, на всякий

-- At line 1:

SELECT rowid, highlight(s, 0, "(*", "*)") as sku, highlight(s, 1, "[!", "!]") as name, price FROM s 

WHERE s MATCH 'колец OR поршн*'

-- Result: 1877 rows returned in 11ms

без сортировки по бм25, тупо по порядку

2244	7405-1004066	Двигатель: Клапан форсунки охлажд-я [!поршня!]

2245	7405-1004066	Двигатель: Клапан форсунки охлажд-я [!поршня!] ОАО «КамАЗ»

2445	740-1000106	Двигатель: Кольца [!поршневые!] (Кострома)

2446	740.30-1000106	Двигатель: Кольца [!поршневые!] ЕВРО-1, 2 Кострома

2447	740-1000106-01	Двигатель: Кольца [!поршневые!] ОАО «КамАЗ»

2448	740-1000106	Двигатель: Кольца [!поршневые!] ч/б

Ну или как то так

или так

если не перепутал 1 ссылку со второй

Да, и в этом главная засада LIKE, естественно. Да и в принципе FTX и нужен для гибкого и быстрого поиска с размытыми критериями, морфологией, настройками весов и проч. Но при небольших объёмах и простых задачах лайк вполне годится.

Не так все просто. Адрес "ул. Петрова 16" сторонний сервис превратит в "ул. Петрова 17", если у этого стороннего сервиса дома номер 16 в базе нет. И адрес "ул. Петрова 18" - тоже. А адрес "ул. Петрова 16, квартира 23" - сторонний сервис превратит в "ул. Петрова 23", при условии если у сервиса в базе дом 23 есть, а дома 16 нет.

Таким образом у вас в исходном состоянии у вас было два разных адреса, а после использования "стороннего сервиса" - одинаковый. Или наоборот было два одинаковых дома с разной квартирой, - а стало два разных дома.

А еще могу рассказать, как сторонние сервисы интерпретируют "ул. Петрова 16/2" и "ул. Петрова 16 корпус 2" и "ул. Петрова 16/2 корпус 3". Корпуса не во всех городах РФ широко распространены, но есть такие города где "корпус" встречается чуть ли не в половине всех адресов.

А еще вот есть в городе проспект Гагарина, улица Гагарина, и бульвар Гагарина. Допустим адрес "ул. Гагарина 17" существует, а "проспект Гагарина 17" не существует. Что сделает сторонний сервис, если вы ему загадаете "Гагарина 17" или "пр. Гагарина 17"? Я уже не помню ответа на эти вопросы если честно, разбирался давно, но что-то не очень умное.

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

- адреса офисов фирм.

- адреса торговых точек.

- адреса объектов недвижимости.

- любые адреса в которых могут быть преднамеренные ошибки.

То никакой сторонний сервис не решит проблему поиска по адресам.

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