и с лимитом конечно

может типа полнотекстовый отдельный на каждую колонку создать?

кажется он все три пытается может тут и капец

не будут использоваться

на эластике такой запрос написанный по их правилам конечно же выстреливает за 0.05 сек

хз как оно там что оно там само эти индексы строит

или мне и вправду стоит разложить на
id, param, value

и на value полнотекстовый
соответственно param будут
number
number_clear
name

как я понимаю приоритет, чтобы в number данные нашлись, можно сделать union с order by MATCH по каждой из колонок с limit 80 и потом поверх сделать ещё limit 80

ну и сам запрос не факт что эквивалентный для elastic

сейчас попробую ка кты говоришь минуту

лучше сразу по-кусочкам смотреть

покамест вопрос

если делать union по двум разным таблицам, как реализовывать offset который пропускает строки и тратит на это время вместо поиска строки с номером?
или эту строку предварительно как-то подсчитывают?

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

order by текущий заставляет сначала показывать все из name

s/name/number/

не получилось понять...

поясни

если запустить по второму полнотекстовому индексу где number_clear/number то отстреливает мгновенно результаты

именно из-за name запрос затягивается на 100 сек

но если не искать в name - смысла в поиске не много

там часто есть важные слова типа болт, шарнир и тд