ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Можно ли ускорить и прочее..
25 сообщений из 68, страница 1 из 3
  1  все
Можно ли ускорить и прочее..
    #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
18.04.2020, 14:38
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948586
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
вадя
поиск происходит при вводе очередного символа в поле инпут в браузере содержимое инпута отправляется на сервер при вводе каждого символа
А откуда тогда несколько лайков - поле-то одно, и значение в нём одно...
...
Рейтинг: 0 / 0
18.04.2020, 14:48
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948588
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Akina
А откуда тогда несколько лайков - поле-то одно, и значение в нём одно...
к примеру поле содержит
Код: plaintext
Бальзам семнадцать целебных трав 35% 0.5.
вводится
Код: plaintext
бальз цел 35

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


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

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

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

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

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

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

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

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

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

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

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

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


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



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

У специализированного средства еще есть такой плюс, как учет морфологии. LIKE-ами это нереализуемо в принципе.
...
Рейтинг: 0 / 0
18.04.2020, 21:50
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948688
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
miksoft
Поиск по "абв абв бв" и "абв" даст одинаковый результат. Но в первом случае три LIKE-а, а во втором один. Хоть и небольшая, но экономия процессорного времени.
вероятность такой ситуации не велика, а строить код , который будет участвовать во всех случаях - затратно. и будет ли заметная экономия в целом - не известно.
но идея хорошая.
...
Рейтинг: 0 / 0
18.04.2020, 21:52
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948690
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
miksoft
От MySQL отказываться не обязательно, но при нескольких миллионах имеет смысл использовать внешний поиск, тот же Сфинкс.
это стоящее замечание/предложение.
miksoft
У специализированного средства еще есть такой плюс, как учет морфологии.
к счастью такая задача пока не стоит.
...
Рейтинг: 0 / 0
18.04.2020, 21:54
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948723
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дегтярев Евгений
Участник
Однозначно поддержу пункты про лимитирование результатов поиска и вынесение полнотекстового поиска из mysql.
Добавлю, что нужно отправлять поисковый запрос на каждое изменение поисковой фразы. Имеет смысл вводить задержку, например, 500мс. Если поисковая фраза изменилась и за 500мс не было изменений - отправляем запрос. Идея - не долбить сервер запросами, пока пользователь печатает слово.
...
Рейтинг: 0 / 0
19.04.2020, 08:15
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948730
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
можно перечитать темы, и копипастить оттуда
1. Как работает LIKE?
2. Ускорение LIKE '%str%' в версии 5.7
...
Рейтинг: 0 / 0
19.04.2020, 10:43
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948761
mini.weblab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mini.weblab
Участник
можно перечитать темы, и закопипастить оттуда, и отправить в Oracle, они же наверное не знают как у них там индекс работает
...
Рейтинг: 0 / 0
19.04.2020, 15:39
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948775
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дегтярев Евгений
Участник
так тс 5 лет проблему решает
однако
...
Рейтинг: 0 / 0
19.04.2020, 16:14
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948781
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Дегтярев Евгений
так тс 5 лет проблему решает
однако
jоднако проблемы нет, просто интересно, может что меняется, сам за всем не уследишь - вот и спрашиваю
...
Рейтинг: 0 / 0
19.04.2020, 17:26
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948786
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
вадя
Alex_Ustinov
сомневаюсь
проверил
давай по существу. В прошлый раз я потерял часов 6 ночью думал у тебя это горит, оказалось что ты просто собирал статистику.
Я сейчас подниму свои скрипты, ты посмотри свои. сверимся по параметрам.
у меня есть ПК на винде и я подниму любой скаченыый МайСкуль за 2 минуты максимум. Это я о том что ты сидишь на Дебе и не упорядочить-поднять два МайСкуля
...
Рейтинг: 0 / 0
19.04.2020, 17:59
| Ответить | Цитировать | Написать  
25 сообщений из 68, страница 1 из 3
  1  все
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Можно ли ускорить и прочее..
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&fpage=22&tid=1828610]:
 0ms
get settings:
 8ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 37ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 86ms
get tp. blocked users:
 1ms
others: 12ms
total:  174ms
созд. / загр.: 174ms
x
x
Закрыть


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