powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Можно ли ускорить и прочее..
68 сообщений из 68, показаны все 3 страниц
Можно ли ускорить и прочее..
    #39948583
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
есть таблица (mysql 8++)
в ней поле
name varchar(150) CHARACTER SET utf8 COLLATE utf8_general_ci
ADD UNIQUE INDEX UK_bars_name (name)
есть хранимка

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
PROCEDURE listBox(IN param varchar(400))
  
BEGIN
  SET @sql = CONCAT('SELECT  id as id, name as name FROM goods.bars  FORCE INDEX (UK_bars_Name)  where ', param, ' limit 10 ;');
  PREPARE sqll FROM @sql;
  EXECUTE sqll;
  DEALLOCATE PREPARE sqll;
END


для неё входной параметр подготавливается отдельно, и имеет вид
name like '%xxx%' [and name like ..]
name like может быть сколько угодно(но из практики 3 достаточно)
в таблице 1 000 000 с не большим записей.
если вместо xxx ( в name like '%xxx%' ) ввести заведомо отсутствующий набор символов , то получается скан всей таблицы - это 0.4сек
если что-то присутствующее - то (при 3 like) 100-300 мс
(поиск происходит при вводе очередного символа в поле инпут в браузере содержимое инпута отправляется на сервер при вводе каждого символа)

вопрос
- это долго или нормально? (условный вопрос)
- реально ли как-то ускорить (в ini прописаны достаточные параметры по памяти - гигабайты)
- не упирается ли это быстродействие в скорость работы с памятью?
- задача такого поиска - быстрый ввод товара в документы. 1000 000 взято чисто из инета - реальное количество сколько может быть?

вопросы из разряда спортивного интереса и проведения опытов.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948586
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
поиск происходит при вводе очередного символа в поле инпут в браузере содержимое инпута отправляется на сервер при вводе каждого символа
А откуда тогда несколько лайков - поле-то одно, и значение в нём одно...
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948588
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akina
А откуда тогда несколько лайков - поле-то одно, и значение в нём одно...
к примеру поле содержит
Код: plaintext
Бальзам семнадцать целебных трав 35% 0.5.
вводится
Код: plaintext
бальз цел 35

получается 3 like
Код: sql
1.
name like '%бальз%' and name like '%цел%' and name like '%35%'  


найдёт именно эту строку
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948615
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
помниться мне Вадя очень был рад что план в какой то версии показал что при like % используется индекс, но тема все та же, "можно ли ускорить да как ускорить...."
ответ как и много лет назад - НЕ ИСПОЛЬЗОВАТЬ Like % )))
проверял я тогда на трех версиях MySQL - время совпадало что с "показом использовании индекса", что без него...
а ВОЗ и ныне там...
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948617
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov,
по поводу
Alex_Ustinov
НЕ ИСПОЛЬЗОВАТЬ Like % )))

придумай что-либо более , что может его заменить.
время прошло, версии mysql обновились, подумал - может что придумали лучшее, что не учёл...
ну счас есть и кроме быстродействия вопросы
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948620
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
что может его заменить.
Ну вообще-то быстрый поиск подстроки - это суффиксное дерево... но MySQL про него не в курсе.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948624
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадяпридумай что-либо более , что может его заменить.если не заложено на ВАЗ возить бревна в 1 тонну, то ходить вокруг него и думать как пристроить кузов бесполезно.

Я думаю тебе надо самому что-то придумать, может перечитать варианты что тебе советовали...
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948632
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akina
Ну вообще-то быстрый поиск подстроки - это суффиксное дерево... но MySQL про него не в курсе.
ну вот в этом беда
Alex_Ustinov
если не заложено на ВАЗ возить бревна в 1 тонну, то ходить вокруг него и думать как пристроить кузов бесполезно.
к примеру 5.7 на порядок медленнее в этом плане чем 8++

ну нет ничего нового- так нет....
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948650
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторк примеру 5.7 на порядок медленнее в этом плане чем 8++ сомневаюсь
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948653
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
сомневаюсь
проверил
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948659
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
1000 000 взято чисто из инета - реальное количество сколько может быть?
А какое направление?
В автозапчастях может быть и сильно больше, там ориентируйтесь на 20 миллионов.
Но для большинства направлений и 100 тысяч достаточно.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948665
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

Еще предложил бы на рассмотрение варианты:

1) в запросе добавить LIMIT 101.
Если выбрано 100 или менее записей, то просто показывать их пользователю.
Если выбрана 101 запись, то дополнительно говорить "найдено более 100 вариантов, уточните поиск". Или даже вообще только эту запись.
Экономия в том, что если подходящих записей слишком много, то не сканировать всю таблицу, а бросить гораздо раньше.

2) Если количество найденных записей достаточно умеренное (заметно меньше исходного количества), то сохранять их где-либо (хоть в другой таблице, лучше IN-MEMORY) и при наборе следующего символа искать уже в этом наборе, а не в исходной таблице

3) прикрутить внешний поиск, например, Сфинкс.

Еще можно прикрутить совсем внешний поиск (т.е. сторонний сервис). Мне доводилось работать с таким. Ищет быстро, сильно быстрее обычного LIKE '%строка%'. Но тот сервис загнулся. Да и зависимость от стороннего сервиса как-то не здорово.

4) Проверять ввод.
- не делать поиск, если во введенной строке нет ни одного слова длиннее 2-3 символов. Т.е. по строке "а б в" поиск даже начинать не надо.
- при поиске проверить введенные слова на вхождение друг в друга. Т.е. по строке "абв абв бв" искать только "абв".

5) В зависимости от качества данных еще может иметь смысл конвертация символов, схожих по написанию к одному варианту. Например, буквы о-латинская, о-русская, цифра 0 часто выглядят одинаково, поэтому при поиске можно свести к одному. Если применять эту механику, то, конечно, и исходные данные нужно сконвертировать аналогично.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948673
mini.weblab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
помниться мне Вадя очень был рад что план в какой то версии показал что при like % используется индекс, но тема все та же, "можно ли ускорить да как ускорить...."
ответ как и много лет назад - НЕ ИСПОЛЬЗОВАТЬ Like % )))
проверял я тогда на трех версиях MySQL - время совпадало что с "показом использовании индекса", что без него...
а ВОЗ и ныне там...

чтобы использовался индекс запрос нужно переписать
Код: sql
1.
name like 'бальз%' and name like 'цел%' and name like '35%' 


в вадином варианте индекс использоваться не будет
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948675
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mini.weblab
чтобы использовался индекс запрос нужно переписать
Код: sql
1.
name like 'бальз%' and name like 'цел%' and name like '35%' 



в вадином варианте индекс использоваться не будет
Вот только результат этого запроса всегда будет пустой.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948679
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
1) в запросе добавить LIMIT 101.
Если выбрано 100 или менее записей, то просто показывать их пользователю.
Если выбрана 101 запись, то дополнительно говорить "найдено более 100 вариантов, уточните поиск". Или даже вообще только эту запись.
Экономия в том, что если подходящих записей слишком много, то не сканировать всю таблицу, а бросить гораздо раньше.
только 10, остальное так и есть.
miksoft
2) Если количество найденных записей достаточно умеренное (заметно меньше исходного количества), то сохранять их где-либо (хоть в другой таблице, лучше IN-MEMORY) и при наборе следующего символа искать уже в этом наборе, а не в исходной таблице
мысль интересная. надо обдумать
miksoft
4) Проверять ввод.
- не делать поиск, если во введенной строке нет ни одного слова длиннее 2-3 символов. Т.е. по строке "а б в" поиск даже начинать не надо.
- при поиске проверить введенные слова на вхождение друг в друга. Т.е. по строке "абв абв бв" искать только "абв".
первая часть - что-то похожее реализовано, вторая - спорная.
miksoft
5) В зависимости от качества данных еще может иметь смысл конвертация символов, схожих по написанию к одному варианту. Например, буквы о-латинская, о-русская, цифра 0 часто выглядят одинаково, поэтому при поиске можно свести к одному. Если применять эту механику, то, конечно, и исходные данные нужно сконвертировать аналогично.
это уже слишком качественно. пока такое не планируется.
исхожу из того, что если есть подобное наименование - его правят и сохраняют как новый или исправленный, но без вредительсва
miksoft
А какое направление?
пока просто товары , без привязки.
miksoft
Но для большинства направлений и 100 тысяч достаточно.
есть реальная база с 30 000 - на локальной машине - от ввода символа в браузере - до отображения найденных 10 строк - максимум 16мс.
miksoft
В автозапчастях может быть и сильно больше, там ориентируйтесь на 20 миллионов.
Но для большинства направлений и 100 тысяч достаточно.
проверял на 10 лимонах - 4сек..
вопрос - при каком количестве наименований стоит переходить на другой продукт?
я думаю что 20 лямов - это уже другой уровень. а до 1ляма - можно использовать
эти 0.4 сек при 1 000 000 (не ощущаются с учётом количества)

хотелось бы узнать области и количество наименований
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948683
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
miksoft
4) Проверять ввод.
- не делать поиск, если во введенной строке нет ни одного слова длиннее 2-3 символов. Т.е. по строке "а б в" поиск даже начинать не надо.
- при поиске проверить введенные слова на вхождение друг в друга. Т.е. по строке "абв абв бв" искать только "абв".
первая часть - что-то похожее реализовано, вторая - спорная.
Почему спорная?
Поиск по "абв абв бв" и "абв" даст одинаковый результат. Но в первом случае три LIKE-а, а во втором один. Хоть и небольшая, но экономия процессорного времени.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948686
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
вопрос - при каком количестве наименований стоит переходить на другой продукт?
я думаю что 20 лямов - это уже другой уровень. а до 1ляма - можно использовать
Что такое другой продукт? От MySQL отказываться не обязательно, но при нескольких миллионах имеет смысл использовать внешний поиск, тот же Сфинкс.
До 100 000 и LIKE справляется неплохо.
Со средним диапазоном я как-то не сталкивался, точную границу не подскажу.

У специализированного средства еще есть такой плюс, как учет морфологии. LIKE-ами это нереализуемо в принципе.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948688
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
Поиск по "абв абв бв" и "абв" даст одинаковый результат. Но в первом случае три LIKE-а, а во втором один. Хоть и небольшая, но экономия процессорного времени.
вероятность такой ситуации не велика, а строить код , который будет участвовать во всех случаях - затратно. и будет ли заметная экономия в целом - не известно.
но идея хорошая.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948690
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
От MySQL отказываться не обязательно, но при нескольких миллионах имеет смысл использовать внешний поиск, тот же Сфинкс.
это стоящее замечание/предложение.
miksoft
У специализированного средства еще есть такой плюс, как учет морфологии.
к счастью такая задача пока не стоит.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948723
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Однозначно поддержу пункты про лимитирование результатов поиска и вынесение полнотекстового поиска из mysql.
Добавлю, что нужно отправлять поисковый запрос на каждое изменение поисковой фразы. Имеет смысл вводить задержку, например, 500мс. Если поисковая фраза изменилась и за 500мс не было изменений - отправляем запрос. Идея - не долбить сервер запросами, пока пользователь печатает слово.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948730
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
можно перечитать темы, и копипастить оттуда
1. Как работает LIKE?
2. Ускорение LIKE '%str%' в версии 5.7
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948761
mini.weblab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
можно перечитать темы, и закопипастить оттуда, и отправить в Oracle, они же наверное не знают как у них там индекс работает
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948775
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
так тс 5 лет проблему решает
однако
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948781
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дегтярев Евгений
так тс 5 лет проблему решает
однако
jоднако проблемы нет, просто интересно, может что меняется, сам за всем не уследишь - вот и спрашиваю
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948786
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
Alex_Ustinov
сомневаюсь
проверил
давай по существу. В прошлый раз я потерял часов 6 ночью думал у тебя это горит, оказалось что ты просто собирал статистику.
Я сейчас подниму свои скрипты, ты посмотри свои. сверимся по параметрам.
у меня есть ПК на винде и я подниму любой скаченыый МайСкуль за 2 минуты максимум. Это я о том что ты сидишь на Дебе и не упорядочить-поднять два МайСкуля
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948788
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
вадя
пропущено...
проверил
давай по существу. В прошлый раз я потерял часов 6 ночью думал у тебя это горит, оказалось что ты просто собирал статистику.
Я сейчас подниму свои скрипты, ты посмотри свои. сверимся по параметрам.
у меня есть ПК на винде и я подниму любой скаченыый МайСкуль за 2 минуты максимум. Это я о том что ты сидишь на Дебе и не упорядочить-поднять два МайСкуля
*не можешь упорядочить как поднять разные версии. Такое ощущение что ты делаешь просто опрос - "а как ребята у вас? а у них так..."
можно удалить не глядя...
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948797
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
*не можешь упорядочить как поднять разные версии. Такое ощущение что ты делаешь просто опрос - "а как ребята у вас? а у них так..."
можно удалить не глядя...
ну поднимать - у меня всё и 5.7. и 8 развернуты
вот только не вижу смысла что-либо на 5.7 пробовать...
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948804
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну что, тогда потестим? говори версии, я делаю соответствие.
У меня будут нулевые БД
Делаем таблицу для теста с одинаковым наполнением.
Ты можешь оказаться и правым, не стесняйся, я готов к поражению, тем более все на скл ру
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948805
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
условие - таблица до 2-3 млн с одним полем 10-12 знаков char() поиск 4 знака (ну как ты приводил пример с Майскуру, что там используется сепер пупер поиск для 3 и более знаков БойляМариота(не помню дословно)) пиши конкретику
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948809
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
ну что, тогда потестим? говори версии, я делаю соответствие.
давай потестим - я могу скинуть таблицу
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948811
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

ты с ума сошел - давай ddl и раунд-заполнение, зачем мне твои мегА
по твоим данным проверять не будем, твою задачу решай сам
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948812
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
Alex_Ustinov
ну что, тогда потестим? говори версии, я делаю соответствие.
давай потестим - я могу скинуть таблицу
версии майскуля пиши, и 5.7 и 8(плюсы круто, но лучше точную цифру)
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948964
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
8.0.19
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE goods.bar (
  ID bigint NOT NULL AUTO_INCREMENT,
  Name varchar(255) DEFAULT NULL,
  PRIMARY KEY (ID)
)
ENGINE = INNODB,
CHARACTER SET utf8mb4,
COLLATE utf8mb4_unicode_ci;

ALTER TABLE goods.bar
ADD UNIQUE INDEX UK_bar_Name (Name)



полный скан - 12 сек

Код: sql
1.
2.
3.
SELECT
  COUNT(*)
FROM goods.bar


4748228
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39948997
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Ещё одним сюрпризом может стать отсутствие в MySQL 8 встроенного механизма кэширования запросов 
query cache, который широко использовался в предыдущих версиях. Данная функция уже довольно давно 
значилась как deprecated и вот, наконец, момент настал.

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

В случае, если вы уверены в необходимости кэширования запросов, то вам следует рассмотреть использование 
сторонних SQL-прокси с кэшированием, к примеру ProxySQL обладающим в разы более высокой эффективностью 
и настраиваемостью.
в первых 8 видимо ещё было...
раньше не было таких обращений к диску после первого скана всей таблицы
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39949013
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
при апграде переписывается ini.
поставил
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4

первый поиск 9 сек
последующие только в памяти 2.3 сек (это при вводе заранее отсутствующих наборов)
для 4 748 228 это много или терпимо?

моё мнение что послу 1 000 000 надо уже другое использовать.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951228
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
результаты сравнения никто не смотрит,

приведем еще одно, на здоровье всем
сравним поиск LIKE "%строка%" в MySQL 5.7.28 и 8.0.19
все проверялось на экземплярах "из коробки" 1 таблица в базе
обе БД с такими параметрами
innodb_buffer_pool_size = 512M
innodb_file_per_table = ON (по дефолту)

заполнение данных
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
DELIMITER $$
/*  таблица - поле поиска char(30)  */
CREATE TABLE test.mytable (
  id int NOT NULL AUTO_INCREMENT,
  ColForSearch char(30) DEFAULT NULL,
  PRIMARY KEY (id)
)
ENGINE = INNODB,
CHARACTER SET utf8,
COLLATE utf8_general_ci;


ALTER TABLE test.mytable
ADD INDEX IDX_mytable_ColForSearch (ColForSearch);
$$

CREATE FUNCTION test.randstr(lenstr INT)
  RETURNS varchar(255) CHARSET utf8
  NO SQL
BEGIN
  SET @randstr := "";
  SET @engstr="abcdefghjklmnopqrstuvwxyz";
  WHILE lenstr > 0 DO
    SET @randstr = CONCAT(@randstr,SUBSTR(@engstr,ROUND(RAND()*CHAR_LENGTH(@engstr)),1)); 
    SET lenstr = lenstr - 1;
  END WHILE;

RETURN @randstr;
END;
$$

/* заполняем 2,5 млн. записей ~15-20 мин. */
INSERT INTO mytable (mytable.ColForSearch) 
SELECT randstr(30) FROM 
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t1,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t2,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 ) AS t3,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t4,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t5,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 ) AS t6,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t7,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t8,
  (select 1 as a union select 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5) AS t9,
  (select 1 as a union select 2) AS t10;
$$

DELIMITER ;

/* получаем файл *.ibd таблицы ~152М с индексом ~265М, все в буфере, 
хотя это не важно, мы просто сравниваем*/

EXPLAIN запросов SELECT ... ColForSearch LIKE "%строка%" одинаков и неинтересен
id select_type table partitions type possible_keys key key_len ref rows filtered Extra1 SIMPLE t (null) index (null) IDX_mytable_ColForSearch 91 (null) 2492034 11.11 Using where; Using index
результаты сравнения, можно смотреть только на "время выполнения"
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
/* запрос когда НЕТ совпадений, сканируем */
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "%НЕТ_ЗАПИСЕЙ%";
5.7.28 - Запрос открыт за 1,641c [1,634c выполнение, 0,007c выборка]
8.0.19 - Запрос открыт за 1,786c [1,779c выполнение, 0,007c выборка]
/* запрос когда НЕТ совпадений LIKE с начала строки*/
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "НЕТ_ЗАПИСЕЙ%";
5.7.28 - Запрос открыт за 0,003c [0,002c выполнение, 0,001c выборка]
8.0.19 - Запрос открыт за 0,010c [0,002c выполнение, 0,008c выборка]

/* поиск 6 знаков -------------------------- */
/* рез-т 166-155 записей посмотрим время COUNT()*/
SELECT COUNT(*) FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnaor%";
5.7.28 - Запрос открыт за 1,677c [1,676c выполнение, 0,001c выборка]
8.0.19 - Запрос открыт за 1,840c [1,832c выполнение, 0,008c выборка]
SELECT SQL_NO_CACHE * FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnaor%";
5.7.28 - Запрос открыт за 1,723c [1,717c выполнение, 0,006c выборка]
8.0.19 - Запрос открыт за 1,975c [1,967c выполнение, 0,008c выборка]
/* без SQL_NO_CACHE  то же самое в моем случае */
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnaor%";
5.7.28 - Запрос открыт за 1,729c [1,720c выполнение, 0,009c выборка]
8.0.19 - Запрос открыт за 1,897c [1,888c выполнение, 0,009c выборка]
/* like с начала строки!!!*/
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "ywnaor%"; 
5.7.28 - Запрос открыт за 0,017c [0,001c выполнение, 0,016c выборка] /* 4 записи  */
8.0.19 - Запрос открыт за 0,008c [0,001c выполнение, 0,007c выборка] /* 8 записи  */

/* поиск 5 знаков -------------------------- */
/* рез-т 700-683 записей */
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnao%";
5.7.28 - Запрос открыт за 1,048c [1,045c выполнение, 0,003c выборка] 
8.0.19 - Запрос открыт за 1,112c [1,108c выполнение, 0,004c выборка] 

/* поиск 4 знака -------------------------- */
/* 3433-3450 записей  посмотрим время COUNT() */
SELECT COUNT(*) FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
5.7.28 - Запрос открыт за 1,679c [1,655c выполнение, 0,024c выборка]
8.0.19 - Запрос открыт за 1,790c [1,789c выполнение, 0,001c выборка]
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
5.7.28 - Запрос открыт за 0,223c [0,220c выполнение, 0,003c выборка]
8.0.19 - Запрос открыт за 0,228c [0,225c выполнение, 0,003c выборка]
/* то же, поиск 4 знака  с начала строки 130 записей*/
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "wnao%";
5.7.28 - Запрос открыт за 0,002c [0,001c выполнение, 0,001c выборка]
8.0.19 - Запрос открыт за 0,012c [0,001c выполнение, 0,011c выборка]

можно было взять и >5 млн таблицу но толку от этого нет, результат не изменится
Лень крутить версию 5.6, где в плане не будет "Using index", но по результатам прошлого сравнения должно быть практически то же самое. Чуть позже посмотрим, так ли это.
Вадяпроверилперепроверь сам лично. скрипты все выложены.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951234
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
Код: sql
1.
2.
3.
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
5.7.28 - Запрос открыт за 0,223c [0,220c выполнение, 0,003c выборка]
8.0.19 - Запрос открыт за 0,228c [0,225c выполнение, 0,003c выборка]

Что-то меня это смущает.
Почему при уменьшении количества знаков в искомой строке время уменьшается?
Это точно время всей выборки, а не первой записи?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951237
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

да, ошибочка
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951238
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
Alex_Ustinov
Код: sql
1.
2.
3.
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
5.7.28 - Запрос открыт за 0,223c [0,220c выполнение, 0,003c выборка]
8.0.19 - Запрос открыт за 0,228c [0,225c выполнение, 0,003c выборка]

Что-то меня это смущает.
Почему при уменьшении количества знаков в искомой строке время уменьшается?
Это точно время всей выборки, а не первой записи?
кстати да, там 1,858s для 8,0, я за сравнением и не думал о цифрах
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951239
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
miksoft,

да, ошибочка
не 1,8 это профилировщик, сам запрос так и есть 0,2
запускаю в dbForge , постраничный вывод у меня отключен.
Или я не прав?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951242
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да, в консоли 1,85сек. для 8.0.19 и для 4-знаков и для 5-ти.
значит и для 5,7 тоже самое.
dbForge дал время по 1-й странице вывода, получается так
ну, хотел сравнение, получил только сравнение...
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951287
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
продолжаем утреннюю зарядку с версией 5.1 (зачем нам 5.6 если есть возможность углубиться далеко в прошлое)
запросы выполнялись в dbForge, там где то выскакивал постраничный вывод хотя он отключен, ну в принципе для сравнение пойдет как есть, все выполнялось копипастом запросов в каждой версии
сравнение поиска LIKE "%строка%" в 5.1.73 / 5.7.28 / 8.0.19
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
/* запрос когда НЕТ совпадений, сканируем */
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "%НЕТ_ЗАПИСЕЙ%";
5,1,73 - Запрос открыт за 1,761c [1,757c выполнение, 0,004c выборка]
5.7.28 - Запрос открыт за 1,641c [1,634c выполнение, 0,007c выборка]
8.0.19 - Запрос открыт за 1,786c [1,779c выполнение, 0,007c выборка]
/* запрос когда НЕТ совпадений LIKE с начала строки*/
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "НЕТ_ЗАПИСЕЙ%";
5,1,73 - Запрос открыт за 0,005c [0,001c выполнение, 0,004c выборка]
5.7.28 - Запрос открыт за 0,003c [0,002c выполнение, 0,001c выборка]
8.0.19 - Запрос открыт за 0,010c [0,002c выполнение, 0,008c выборка]

/* поиск 6 знаков -------------------------- */
/* рез-т 166-155 записей посмотрим время COUNT()*/
SELECT COUNT(*) FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnaor%";
5,1,73 - Запрос открыт за 1,741c [1,741c выполнение, < 0,001c выборка]
5.7.28 - Запрос открыт за 1,677c [1,676c выполнение, 0,001c выборка]
8.0.19 - Запрос открыт за 1,840c [1,832c выполнение, 0,008c выборка]
SELECT SQL_NO_CACHE * FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnaor%";
5,1,73 - Запрос открыт за 1,829c [1,825c выполнение, 0,004c выборка]
5.7.28 - Запрос открыт за 1,723c [1,717c выполнение, 0,006c выборка]
8.0.19 - Запрос открыт за 1,975c [1,967c выполнение, 0,008c выборка]
/* без SQL_NO_CACHE  то же самое в моем случае, практически  */
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnaor%";
5,1,73 - Запрос открыт за 1,814c [1,810c выполнение, 0,004c выборка]
5.7.28 - Запрос открыт за 1,729c [1,720c выполнение, 0,009c выборка]
8.0.19 - Запрос открыт за 1,897c [1,888c выполнение, 0,009c выборка]
/* like с начала строки!!!*/
SELECT  * FROM mytable AS t WHERE t.ColForSearch LIKE "ywnaor%"; 
5,1,73 - Запрос открыт за 0,005c [0,001c выполнение, 0,004c выборка] /* 8 записей  */
5.7.28 - Запрос открыт за 0,017c [0,001c выполнение, 0,016c выборка] /* 4 записи  */
8.0.19 - Запрос открыт за 0,008c [0,001c выполнение, 0,007c выборка] /* 8 записей  */

/* ИСПРАВЛЕНО для 5 и 4 знаков в поиске время по профилировщику */
/* поиск 5 знаков -------------------------- */
/* рез-т 700-683 записей */
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%ywnao%";
5,1,73 - Запрос открыт за 1,820c
5.7.28 - Запрос открыт за 1,712c
8.0.19 - Запрос открыт за 1,802c

/* поиск 4 знака -------------------------- */
/* 3433-3450 записей  посмотрим время COUNT() */
SELECT COUNT(*) FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
5,1,73 - Запрос открыт за 1,737c
5.7.28 - Запрос открыт за 1,679c
8.0.19 - Запрос открыт за 1,790c [1,789c выполнение, 0,001c выборка]
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
5,1,73 - Запрос открыт за 1,887c [1,887c выполнение, 0,001c выборка]
5.7.28 - Запрос открыт за 1,711c [1,708c выполнение, 0,003c выборка]
8.0.19 - Запрос открыт за 1,822c [1,819c выполнение, 0,003c выборка]
/* то же, поиск 4 знака  с начала строки 130 записей*/
SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "wnao%";
5,1,73 Запрос открыт за 0,008c [0,002c выполнение, 0,006c выборка]
5.7.28 - Запрос открыт за 0,002c [0,001c выполнение, 0,001c выборка]
8.0.19 - Запрос открыт за 0,012c [0,001c выполнение, 0,011c выборка]


самое интересное - это план в 5.1.73

EXPLAIN SELECT * FROM mytable AS t WHERE t.ColForSearch LIKE "%wnao%";
id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE t index (null) IDX_mytable_ColForSearch 91 (null) 2500407 Using where; Using index
откуда в 5.1.73 Using index - не знаю
это чисто сравнительный тест. С учетом "равномерного заполнения" повторяемость теста есть... имхо
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951356
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
результаты интересные но вот толко это
ColForSearch char(30)
смущает
у меня
varchar(255)
как бы разница до 8,5 раз
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951360
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я взял данные тут https://github.com/papyrussolution/UhttBarcodeReference/releases
удалил дубликаты
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951385
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
для 8
таблица
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
CREATE TABLE test.bar (
  ID bigint NOT NULL AUTO_INCREMENT,
  Name varchar(255) DEFAULT NULL,
  PRIMARY KEY (ID),
  UNIQUE INDEX UK_bar (Name, ID)
)
ENGINE = INNODB,
AUTO_INCREMENT = 6501952,
AVG_ROW_LENGTH = 90,
CHARACTER SET utf8mb4,
COLLATE utf8mb4_unicode_ci
PARTITION BY RANGE (ID)
(
PARTITION partition1 VALUES LESS THAN (100000)
ENGINE = INNODB,
PARTITION partition2 VALUES LESS THAN (MAXVALUE)
ENGINE = INNODB
);



хранимка
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
PROCEDURE test.listBox(IN param varchar(400))
  DETERMINISTIC
BEGIN
  SET @param = REPLACE(param, CHAR(3), '''''');
  SET @sql = CONCAT('EXPLAIN  SELECT  id as id, Name as name FROM test.bar  where ', @param, ' limit 10 ;');
  PREPARE sqll FROM @sql;
  EXECUTE sqll;
  DEALLOCATE PREPARE sqll;



"id""select_type""table""partitions""type""possible_keys""key""key_len""ref""rows""filtered""Extra"1"SIMPLE""bar""partition1,partition2""index"null"UK_bar""1031"null45422030,14"Using where Using index"
входные данные (такого набора нет однозначно)

name like '%мыло%' and name like '%мята%' and name like '%10770%'

Хранимая процедура 'test.listBox' была успешно выполнена за 2,447с.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951391
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЗЫ
сравнивать с 5.7 - нет желания, потому как много чего там нет...
даже если мои ранишние данные 5.7 и ошибочны.

ЗЫ
сделал так что отправка на сервер осуществляется только если после ввода символа есть пауза в 300 мс.
надо сказать - очень не удобно. делать паузу ещё больше - общее время поиска увеличивается на эту паузу.
отравлять на сервер по Enter - может быть...
для "малого количества" отправка после ввода каждого символа - не сильно напрягает сервер. зато удобство - очень привлекательно.
тут надо выбирать решение по месту , исходя из конкретных условий.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951414
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
результаты интересные но вот толко это
ColForSearch char(30)
смущает
у меня
varchar(255)
как бы разница до 8,5 раз
какая разница, в прошлый раз было varchar(50)
я просто не хочу долго ждать наполнения, будет 100% то же самое
я тебе показал что ничего не поменялось на 3 версиях.
Потому что я понял, что ничего ты НЕ
Вадяпроверил---даже если мои ранишние данные 5.7 и ошибочны. ----
они и не ошибочны. Ошибочно у тебя воображение.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951442
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
какая разница, в прошлый раз было varchar(50)
да не большая. только до 5 раз.
ты защищаешь старые версии - ну ради бога.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951450
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

я не защищаю старые версии, где ты это увидел.
Проделай мои тесты с полем 255. выложи и покажи нам.
Если ты считаешь что Бтри дерево при 30-50 работает не также как при 255 - покажи пожалуйста результаты сравнения
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951462
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
я не защищаю старые версии, где ты это увидел.
Проделай мои тесты с полем 255. выложи и покажи нам.
Если ты считаешь что Бтри дерево при 30-50 работает не также как при 255 - покажи пожалуйста результаты сравнения
каюсь, каюсь....
проверил на 5.7.28
результаты одинаковые с 8.0.19
сам счас в недоумении почему тогда такая разница была....
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951477
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
да не большая. только до 5 раз.
Для поля varchar неважно как оно объявлено, число - это лишь ограничение на длину значения. Важно фактическое наполнение.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951481
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
Для поля varchar неважно как оно объявлено, число - это лишь ограничение на длину значения. Важно фактическое наполнение.
дак я и написал до 5 раз
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951487
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
miksoft
Для поля varchar неважно как оно объявлено, число - это лишь ограничение на длину значения. Важно фактическое наполнение.
дак я и написал до 5 раз
Если наполнять поле всегда на 30 символов (Alex_Ustinov именно так и сделал), то неважно объявлено оно varchar(50) или varchar(255). Никакого "до 5 раз" не возникает.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951492
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
Если наполнять поле всегда на 30 символов (Alex_Ustinov именно так и сделал), то неважно объявлено оно varchar(50) или varchar(255). Никакого "до 5 раз" не возникает
это да, но реально 30 это слишком мало.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951571
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадяно реально 30 это слишком мало.для чего мало?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951655
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
для чего мало?
для названия товаров
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951675
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

а причем здесь название товаров в сравнении скорости поиска LIKE "%строка%"
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951686
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
а причем здесь название товаров в сравнении скорости поиска LIKE "%строка%"
для чего нужен поиск? без применения к конкретной ситуации он бессмыслен
одно из значимых применений - поиск наименования товара, как при вводе нового, так и при наборе товара в корзину.
чем быстрее будет поиск - тем удобнее для оператора/клиента
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951717
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

масло масляное
LIKE %строка% быстрее работать не будет. Товар или звезды на небе.
ты еще умудряешься этажерки строить LIKE %строка% LIKE %строка% LIKE %строка%

с FullText проверял? какие результаты? Покажи,сравним
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951750
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
революции в алгоритмах поиска подстроки в последние годы не было, какой смысл все это проверять?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951755
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
с FullText проверял? какие результаты? Покажи,сравним
FullText это совсем не то. тут сравнивать нечего.
а эти этажерки я придумал ещё в начале нулевых. показали себя очень удобным вариантом.
вопрос о ускорении - это надежда что что-то меняется в нативных кодах и прочее.
вопрос о границах применения - у меня реальное значение 30к - подходит идеально.
я дал ссылку с 4.7м записями - dbForge под окнами показывает 1.9 сек, но если в полном цикле - ввод в браузере - вывод в браузере - это уже до 3 сек (накапливается и манера ввода и прочее)

тут есть вопрос - по работе "этажерки" если первый like не сработал - продолжается ли работа следующих или переходит к новой записи?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951760
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
или может задать тип поля другой?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951763
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дегтярев Евгений
революции в алгоритмах поиска подстроки в последние годы не было, какой смысл все это проверять?
ну Вадя хочет быстрее, надо проверять варианты по отношению к LIKE %строка%
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951771
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

DdForge показывает в окне выполнения время постраничного вывода. Точное время надо смотреть в профилировщике.
miksoft меня поправил, если ты читаешь внимательно

FullText - конечно он другой. Но он ~ в 4 раза быстрее чем LIKE %строка%. ИНдекс может быть построен по нескольким полям.
Может тогда и не надо будет поле в 255 символов... Ну ищет от 3 символов, зато базу лишний раз не дергает. Товарные сайты с контекстным LIKE %строка% ищут по вводу от 2-3 символов.

LIKE %СТО% ищет кучу мусора, что очень модно но и совершенно не надо...
найдет и СТОЛ и ТЕСТО и ПУСТО, он ищет вхождение подстроки а не СЛОВА.

впрочем, дело вкуса, а то боюсь ты будешь трактовать что я "защищаю" фуллтекст.
тут надо понять, что на 10млн LIKE %слово%
вадятут есть вопрос - по работе "этажерки" если первый like не сработал - продолжается ли работа следующиха ты проверял? что у тебя получилось? на твоих данных?
вадяFullText это совсем не то. тут сравнивать нечего.а вот это поясни, не понял, может я что-то не знаю?
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951777
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov,

точное время как таковое не важно. я сравниваю время когда like отфильтровывает намного менее 1000.
Alex_Ustinov
LIKE %СТО% ищет кучу мусора, что очень модно но и совершенно не надо...
найдет и СТОЛ и ТЕСТО и ПУСТО, он ищет вхождение подстроки а не СЛОВА.

FullText он ищет с начала слов. из опыта применения - операторы (после некоторого времени работы с этим поиском) начинают вводить символы не только с начала слова , а именно характерные части слов, что
сразу ограничивает набор выбора.

Alex_Ustinov
впрочем, дело вкуса, а то боюсь ты будешь трактовать что я "защищаю" фуллтекст.
тут надо понять, что на 10млн LIKE %слово%
я когда перешёл на mysql - пробовал фултекст, но оказалось не удобно.

Alex_Ustinov
а вот это поясни, не понял, может я что-то не знаю?
ты знаешь всё, всё тонкость - то что ищет с начала слов.
Alex_Ustinov
он ищет вхождение подстроки а не СЛОВА.
вот в этом вся фишка.
вхождение нескольких специфичных групп символов позволяет произвести быстрый выбор нужного.
насколько это важно - у меня есть многолетний опыт наблюдения как с эти работали операторши и как это помогало быстро найти нужное наименование.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951781
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
--- тут надо понять, что на 10млн LIKE %слово%
* это тупик
если в качестве контекстного поиска это и используется, то с LIMIT 10-20 для выпадающего списка. (типа магазин ВсеИНструменты)
Если речь идет только об этом - то вообще не вижу смысла об этом размышлять.
у меня MySql говорит что умный и после неверного условия дальше не идет
Код: sql
1.
2.
3.
4.
SELECT COUNT(*), @a FROM mytable m
WHERE m.id=91479 /* берем одну строку */
AND m.ColForSearch LIKE IF(@a:=1,"%НЕТ_ТАКОГО%", "") /* нет такого */
AND m.ColForSearch LIKE IF(@a:=2,"%НЕТ_ТАКОГО%", "") 

COUNT(*) @a0 1

Код: sql
1.
2.
3.
4.
SELECT COUNT(*), @a FROM mytable m 
WHERE m.id=91479 /* берем одну строку */
AND m.ColForSearch LIKE IF(@a:=1,"%vund%","") /* это условие есть */
AND m.ColForSearch LIKE IF(@a:=2,"%НЕТ_ТАКОГО%","")

COUNT(*) @a0 2
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951790
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадявот в этом вся фишка.
вхождение нескольких специфичных групп символов позволяет произвести быстрый выбор нужного.
насколько это важно - у меня есть многолетний опыт наблюдения как с эти работали операторши и как это помогало быстро найти нужное наименование. условно-иногда-удобно для каких-то редких случаев.
У операторов это привычка, не показатель для оценки пользователя.
...
Рейтинг: 0 / 0
Можно ли ускорить и прочее..
    #39951812
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov
условно-иногда-удобно для каких-то редких случаев.
У операторов это привычка, не показатель для оценки пользователя.
у меня операторы могли во время телефонного разговора - принятия заказа от клиента подготовить счёт с учётом наличия товара, возможных замен, с учётом резервов. с учетом скорости оплаты счета, с учётом быстроты доставки товара на склад.
и всё благодаря возможности быстро найти товар в базе по названию. к концу заказа - счёт уже был распечатан и засунут в факс....
...
Рейтинг: 0 / 0
68 сообщений из 68, показаны все 3 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Можно ли ускорить и прочее..
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]