MySQL база с 10 гб и SELECT

Когда начинаю выполнять SELECT с условием %LIKE%, то очень долго выполняется.

Без схемы БД очень сложно что-то советовать. Может у тебя там индексов нет от слова совсем.

Когда начинаю выполнять SELECT с условием %LIKE%, то очень долго выполняется.

%LIKE% с этим ни один индекс не справится, он просто не сработает по такому ограничению, было бы LIKE% то тогда бы сработало.

По-другому писать запрос, не использовать %LIKE%, а если очень нужно то смотреть что можно сделать с полнотекстовым поиском в твоей СУБД. Если прямо очень нужно искать отдельные фрагменты текста то придется использовать какой-нибудь fulltext index.
Я уже давно ничего такого не делал, но насколько я помню перестройка такого индекса настолько тяжелая что там где я работал ее выполняли по крону раз в сутки.

Как лучше сделать? Может перейти на постгресс или что-то другое

Постгрис не поможет, если нужен полнотекстовый поиск то часто используют специально заточенные на это СУБД, какой-нибудь elasticsearch например.

Индексов нет, но они вроде не помогают при команде LIKE.

Спасибо, но пытаться выкрутить MySQL и играться с ним в данном случае нет смысла, верно?

Как лучше сделать?

Так лучше никогда не делать.

Ты опиши задачу подробнее, «SELECT с условием %LIKE%» быстро работать не будет ни в одной СУБД, нужно менять на что-то другое.

https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html

Что вы имеете ввиду?

Просто это одно из основных что мне нужно, искать любое вхождение в бд и выводить значения потом.

Я не разбираюсь в MySQL, работал только с Oracle и PG, там полнотекстовые индексы имеют ограничения, перестройка такого индекса затратная и ограничения по словаформам (тут уже точно не знаю, у меня небыло таких тикетов).
В тех местах где я работал для полнотекстового поиска использовали такие вещи как elasticsearch, туда выносились только те данные по которым нужно было выполнять такой поиск. Он же использовался для хранения логов (ELK и все такое).

Тогда как советовали тебе нужен fulltext индекс. И запрос там будет уже не like.

В тех местах где я работал для полнотекстового поиска использовали такие вещи как elasticsearch

Ещё есть sphinxsearch, он сейчас вроде реже эластика используется, но он ближе к mysql (вроде это вообще плагин к мускулю) так что может ТСу удобнее будет

1. Вы не приводите пример запроса.
2. Вы не приводите схему бд, хотя бы ту часть которая участвует в запросе.
3. Вы не пишете на каком утюге всё это работает и сколько ещё пользователей одновременно с вами хотят не познанного.
4.

очень долго выполняется

безусловно точная величина.

5. Вы не пишите насколько часто вам нужно выполнять этот запрос и какому кол-ву пользователей это нужно в один момент времени.

Как лучше сделать? Может перейти на постгресс

Переходите на постгрес

или что-то другое

или на что-то другое

Пример запроса в студию.

Если это абсолютно случайные наборы символов в базе и запросе - то ничего не поможет.

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

И т.д. Без подробного описания задачи с реальными примерами вообще разговаривать не о чем.

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

Нужно вхождение искать слова в других словах.

innodb не совсем подходит для этого

Почему?

с условием %LIKE%, то очень долго выполняется

Потому что такой запрос не использует индекс. Тебе нужно перейти на полнотекстовый поиск и сделать соответствующий индекс.

Спасибо, сейчас пробую, но есть такой вопрос:

создал таблицу

 CREATE TABLE `article` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  `title` varchar(200) DEFAULT NULL,

  `content` text,

  PRIMARY KEY (`id`),

  FULLTEXT KEY `title` (`title`,`content`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8; 

в таблице записи

 
ID title                   content
1  name1 name2 name3 aa    ivanscorendk

после этого пытаюсь выполнить:

SELECT * FROM article WHERE MATCH (content) AGAINST ('*cor*' IN BOOLEAN MODE)

Пишет что не найдено, прочитал что если BOOLEAN мод включен, то есть функция *, но не работает.

Можете подсказать?

Почему-то не находит часть текста, пример перед моим сообщением вам.

Добавил пример запроса.

Вы не приводите пример запроса.

SELECT с условием %LIKE%

Вы не приводите схему бд, хотя бы ту часть которая участвует в запросе.

Просто таблица в которой записи с типом varchar, time, поиск нужен по столбцу с VARCHAR

Вы не пишете на каком утюге всё это работает и сколько ещё пользователей одновременно с вами хотят не познанного.

Я один буду выполнять такой запрос

безусловно точная величина.

Все поняли что долго выполняется так как кол-во записей 45 млн, а вы нет, думаю тут вопрос в вашей компетенции

Переходите на постгрес
или на что-то другое

Очень «ценные» советы

Вам лучше следовать фразе: Когда нечего сказать - лучше молчать

Создал новую таблицу с fullsearch на примере,теперь что-то будет вам понятно или дальше будете задавать вопросы а сколько записей и тд?))

Pinkbyte, Aber, Anoxemian, ya-betmen, MrClon, no-such-file, спасибо вам за ответы.

Ты можешь свой content разбить по какому-то принципу на части, которые потом будут использованы при поиске?

Если да, то разбиваешь, например, ivanscorendk на ivans, cor, endk и пишешь в другую табличку, проиндексированную, строки INSERT INTO words(word,article) VALUES('ivans', 123),('cor',123),('endk',123), где 123 - индекс записи с ivanscorendk в article. Тогда на select article.* from article,words where article.idx = words.article and words.word = 'cor' у тебя ответ будет мгновенно.

Если этого сделать невозможно, то ой. Только полнотекстовый поиск, больше никак.

К сожалению, разбить не могу.

Можете подсказать почему не работает?

 SELECT * FROM article WHERE MATCH (content) AGAINST (‘*cor*’ IN BOOLEAN MODE) 

Не показывает что найдено что-то.

А должно? Я не помню наизусть синтаксис MATCH. Может там кавычки двойные для * нужны или ещё чего. В документацию заглянуть сложно?

Во всех примерах что находил одинарные, всегда перед тем как задать вопрос, гуглю)

Так надо не примеры, а документацию читать. Может там только по BINARY полям так можно, а TEXT не получится.

Нет, поэтому и не могу понять почему не работает с *.

Full-text indexes can be created only for VARCHAR, CHAR or TEXT columns.

Не совсем подходит, так как нужно искать в самом свое искать.

Как лучше сделать? Может перейти на постгресс или что-то другое

На специализированную субд типа эластика, как советовали выше.
НО я был бы не я, если бы не предложил какой-нибудь велик.
Короче, добавляешь таблицы words (id int, word varchar 100500) и words_index (id, id_rec (из твоей таблицы), id_word (из words))
Вместо того, чтобы делать вставку текста, делаешь сплит по пробелу, вставляешь уникальные слова в words (предварительно чекнув, что там уже есть). В words_index вставляешь ид новой записи и ид слов.
В итоге у тебя получается эрзац индекс, по нему и ищешь таким же образом: то, что у тебя в like делаешь сплит по пробелу и смотришь сначала в words (число слов/кусков слов = число запросов), всё что там найдешь собираешь и идешь в words_index и получаешь кучу ид из твоей таблицы. По идее это будет быстрее и веселее, чем делать like %xxx yy% в лоб

Ну и когда ты будешь массово индексировать свои 45М записей я бы советовал не дрочить пхп с базой, а взять какой-нибудь нормальный язык и собирать этот индекс, забирая из бд данные пачками по 100к - 1М записей, а потом уже всё это разом заливать.

Если это поисковое слово из словаря, то можно вести таблицу из этих слов и вхождений. Так всё поисковики делают.

Даже если это кусок слова. Несколько like word% или like %word из словаря будет всяко быстрее, чем из всей текстоты.

Что то мне подсказывает судя по размеру базы это слив из Яндекс еды. ;)

Нет

Что там такого интересного слили?

Да ничего, просто взаимосвязь между сотовым, ФИО и реальным адресом. Вплоть до кода в подъезде.

Каеф. Каждая псина сифозная теперь знает про тебя всё, если ты когда-то зашкварился яндекс едой. Это закончится только тогда, когда уголовку будут давать за такой слив кому-нибудь из руководства.

Да нет, это закончится тогда, когда будут внедрены методы криптографии и ухода от абсолютных идентификаторов типа номеров сотового телефона и т. д.

Что тольку сажать руговодство, если данные все равно будут накапливаться? Рано или поздно их будут сливать.

И таки да, пользоваться доставками до двери глупо и неправославно.

Да нет, это закончится тогда, когда будут внедрены методы криптографии и ухода от абсолютных идентификаторов типа номеров сотового телефона и т. д.

Так а смысл телодвижения какие-то делать в этом направлении? Ну утекло и утекло. Назначат какого-нибудь васька козлом и всё забудут.

Что тольку сажать руговодство, если данные все равно будут накапливаться?

Так их резко перестанут накапливать после первых посадок.
А где они прям необходимы начнут шифровать с токеном вдоль и поперёк.
А так - нахрен это делать? Все равно никому ничего за это не будет. Ну обосрались и обосрались.

Где об этом хоть почитать можно?)) Не нашел статью

Нашел) Так там всего 60к, а у меня 45 млн, поэтому могли бы сразу сопоставить) И разбираюсь я с этим всем, еще с февраля, просто сейчас более плотно занялся)