|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
есть таблица (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.
для неё входной параметр подготавливается отдельно, и имеет вид 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 взято чисто из инета - реальное количество сколько может быть? вопросы из разряда спортивного интереса и проведения опытов. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 14:38 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя поиск происходит при вводе очередного символа в поле инпут в браузере содержимое инпута отправляется на сервер при вводе каждого символа ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 14:48 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Akina А откуда тогда несколько лайков - поле-то одно, и значение в нём одно... Код: plaintext
Код: plaintext
получается 3 like Код: sql 1.
найдёт именно эту строку ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 15:08 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
помниться мне Вадя очень был рад что план в какой то версии показал что при like % используется индекс, но тема все та же, "можно ли ускорить да как ускорить...." ответ как и много лет назад - НЕ ИСПОЛЬЗОВАТЬ Like % ))) проверял я тогда на трех версиях MySQL - время совпадало что с "показом использовании индекса", что без него... а ВОЗ и ныне там... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 17:39 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov, по поводу Alex_Ustinov НЕ ИСПОЛЬЗОВАТЬ Like % ))) придумай что-либо более , что может его заменить. время прошло, версии mysql обновились, подумал - может что придумали лучшее, что не учёл... ну счас есть и кроме быстродействия вопросы ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 18:02 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя что может его заменить. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 18:19 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадяпридумай что-либо более , что может его заменить.если не заложено на ВАЗ возить бревна в 1 тонну, то ходить вокруг него и думать как пристроить кузов бесполезно. Я думаю тебе надо самому что-то придумать, может перечитать варианты что тебе советовали... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 18:29 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Akina Ну вообще-то быстрый поиск подстроки - это суффиксное дерево... но MySQL про него не в курсе. Alex_Ustinov если не заложено на ВАЗ возить бревна в 1 тонну, то ходить вокруг него и думать как пристроить кузов бесполезно. ну нет ничего нового- так нет.... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 18:55 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
авторк примеру 5.7 на порядок медленнее в этом плане чем 8++ сомневаюсь ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 19:57 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov сомневаюсь ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 20:00 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя 1000 000 взято чисто из инета - реальное количество сколько может быть? В автозапчастях может быть и сильно больше, там ориентируйтесь на 20 миллионов. Но для большинства направлений и 100 тысяч достаточно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 20:12 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя, Еще предложил бы на рассмотрение варианты: 1) в запросе добавить LIMIT 101. Если выбрано 100 или менее записей, то просто показывать их пользователю. Если выбрана 101 запись, то дополнительно говорить "найдено более 100 вариантов, уточните поиск". Или даже вообще только эту запись. Экономия в том, что если подходящих записей слишком много, то не сканировать всю таблицу, а бросить гораздо раньше. 2) Если количество найденных записей достаточно умеренное (заметно меньше исходного количества), то сохранять их где-либо (хоть в другой таблице, лучше IN-MEMORY) и при наборе следующего символа искать уже в этом наборе, а не в исходной таблице 3) прикрутить внешний поиск, например, Сфинкс. Еще можно прикрутить совсем внешний поиск (т.е. сторонний сервис). Мне доводилось работать с таким. Ищет быстро, сильно быстрее обычного LIKE '%строка%'. Но тот сервис загнулся. Да и зависимость от стороннего сервиса как-то не здорово. 4) Проверять ввод. - не делать поиск, если во введенной строке нет ни одного слова длиннее 2-3 символов. Т.е. по строке "а б в" поиск даже начинать не надо. - при поиске проверить введенные слова на вхождение друг в друга. Т.е. по строке "абв абв бв" искать только "абв". 5) В зависимости от качества данных еще может иметь смысл конвертация символов, схожих по написанию к одному варианту. Например, буквы о-латинская, о-русская, цифра 0 часто выглядят одинаково, поэтому при поиске можно свести к одному. Если применять эту механику, то, конечно, и исходные данные нужно сконвертировать аналогично. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 20:32 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov помниться мне Вадя очень был рад что план в какой то версии показал что при like % используется индекс, но тема все та же, "можно ли ускорить да как ускорить...." ответ как и много лет назад - НЕ ИСПОЛЬЗОВАТЬ Like % ))) проверял я тогда на трех версиях MySQL - время совпадало что с "показом использовании индекса", что без него... а ВОЗ и ныне там... чтобы использовался индекс запрос нужно переписать Код: sql 1.
в вадином варианте индекс использоваться не будет ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:18 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
mini.weblab чтобы использовался индекс запрос нужно переписать Код: sql 1.
в вадином варианте индекс использоваться не будет ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:22 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft 1) в запросе добавить LIMIT 101. Если выбрано 100 или менее записей, то просто показывать их пользователю. Если выбрана 101 запись, то дополнительно говорить "найдено более 100 вариантов, уточните поиск". Или даже вообще только эту запись. Экономия в том, что если подходящих записей слишком много, то не сканировать всю таблицу, а бросить гораздо раньше. miksoft 2) Если количество найденных записей достаточно умеренное (заметно меньше исходного количества), то сохранять их где-либо (хоть в другой таблице, лучше IN-MEMORY) и при наборе следующего символа искать уже в этом наборе, а не в исходной таблице miksoft 4) Проверять ввод. - не делать поиск, если во введенной строке нет ни одного слова длиннее 2-3 символов. Т.е. по строке "а б в" поиск даже начинать не надо. - при поиске проверить введенные слова на вхождение друг в друга. Т.е. по строке "абв абв бв" искать только "абв". miksoft 5) В зависимости от качества данных еще может иметь смысл конвертация символов, схожих по написанию к одному варианту. Например, буквы о-латинская, о-русская, цифра 0 часто выглядят одинаково, поэтому при поиске можно свести к одному. Если применять эту механику, то, конечно, и исходные данные нужно сконвертировать аналогично. исхожу из того, что если есть подобное наименование - его правят и сохраняют как новый или исправленный, но без вредительсва miksoft А какое направление? miksoft Но для большинства направлений и 100 тысяч достаточно. miksoft В автозапчастях может быть и сильно больше, там ориентируйтесь на 20 миллионов. Но для большинства направлений и 100 тысяч достаточно. вопрос - при каком количестве наименований стоит переходить на другой продукт? я думаю что 20 лямов - это уже другой уровень. а до 1ляма - можно использовать эти 0.4 сек при 1 000 000 (не ощущаются с учётом количества) хотелось бы узнать области и количество наименований ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:33 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя miksoft 4) Проверять ввод. - не делать поиск, если во введенной строке нет ни одного слова длиннее 2-3 символов. Т.е. по строке "а б в" поиск даже начинать не надо. - при поиске проверить введенные слова на вхождение друг в друга. Т.е. по строке "абв абв бв" искать только "абв". Поиск по "абв абв бв" и "абв" даст одинаковый результат. Но в первом случае три LIKE-а, а во втором один. Хоть и небольшая, но экономия процессорного времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:45 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя вопрос - при каком количестве наименований стоит переходить на другой продукт? я думаю что 20 лямов - это уже другой уровень. а до 1ляма - можно использовать До 100 000 и LIKE справляется неплохо. Со средним диапазоном я как-то не сталкивался, точную границу не подскажу. У специализированного средства еще есть такой плюс, как учет морфологии. LIKE-ами это нереализуемо в принципе. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:50 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft Поиск по "абв абв бв" и "абв" даст одинаковый результат. Но в первом случае три LIKE-а, а во втором один. Хоть и небольшая, но экономия процессорного времени. но идея хорошая. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:52 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft От MySQL отказываться не обязательно, но при нескольких миллионах имеет смысл использовать внешний поиск, тот же Сфинкс. miksoft У специализированного средства еще есть такой плюс, как учет морфологии. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2020, 21:54 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Однозначно поддержу пункты про лимитирование результатов поиска и вынесение полнотекстового поиска из mysql. Добавлю, что нужно отправлять поисковый запрос на каждое изменение поисковой фразы. Имеет смысл вводить задержку, например, 500мс. Если поисковая фраза изменилась и за 500мс не было изменений - отправляем запрос. Идея - не долбить сервер запросами, пока пользователь печатает слово. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 08:15 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
можно перечитать темы, и копипастить оттуда 1. Как работает LIKE? 2. Ускорение LIKE '%str%' в версии 5.7 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 10:43 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
можно перечитать темы, и закопипастить оттуда, и отправить в Oracle, они же наверное не знают как у них там индекс работает ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 15:39 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
так тс 5 лет проблему решает однако ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 16:14 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Дегтярев Евгений так тс 5 лет проблему решает однако ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 17:26 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя Alex_Ustinov сомневаюсь Я сейчас подниму свои скрипты, ты посмотри свои. сверимся по параметрам. у меня есть ПК на винде и я подниму любой скаченыый МайСкуль за 2 минуты максимум. Это я о том что ты сидишь на Дебе и не упорядочить-поднять два МайСкуля ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 17:59 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov вадя пропущено... проверил Я сейчас подниму свои скрипты, ты посмотри свои. сверимся по параметрам. у меня есть ПК на винде и я подниму любой скаченыый МайСкуль за 2 минуты максимум. Это я о том что ты сидишь на Дебе и не упорядочить-поднять два МайСкуля можно удалить не глядя... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 18:26 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov *не можешь упорядочить как поднять разные версии. Такое ощущение что ты делаешь просто опрос - "а как ребята у вас? а у них так..." можно удалить не глядя... вот только не вижу смысла что-либо на 5.7 пробовать... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 19:05 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
ну что, тогда потестим? говори версии, я делаю соответствие. У меня будут нулевые БД Делаем таблицу для теста с одинаковым наполнением. Ты можешь оказаться и правым, не стесняйся, я готов к поражению, тем более все на скл ру ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 20:32 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
условие - таблица до 2-3 млн с одним полем 10-12 знаков char() поиск 4 знака (ну как ты приводил пример с Майскуру, что там используется сепер пупер поиск для 3 и более знаков БойляМариота(не помню дословно)) пиши конкретику ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 20:39 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov ну что, тогда потестим? говори версии, я делаю соответствие. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 21:06 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя, ты с ума сошел - давай ddl и раунд-заполнение, зачем мне твои мегА по твоим данным проверять не будем, твою задачу решай сам ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 21:11 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя Alex_Ustinov ну что, тогда потестим? говори версии, я делаю соответствие. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2020, 21:12 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
8.0.19 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
полный скан - 12 сек Код: sql 1. 2. 3.
4748228 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2020, 14:48 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
раньше не было таких обращений к диску после первого скана всей таблицы ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2020, 16:01 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
при апграде переписывается ini. поставил innodb_buffer_pool_size = 4G innodb_buffer_pool_instances = 4 первый поиск 9 сек последующие только в памяти 2.3 сек (это при вводе заранее отсутствующих наборов) для 4 748 228 это много или терпимо? моё мнение что послу 1 000 000 надо уже другое использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2020, 16:39 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
результаты сравнения никто не смотрит, приведем еще одно, на здоровье всем сравним поиск 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.
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.
Лень крутить версию 5.6, где в плане не будет "Using index", но по результатам прошлого сравнения должно быть практически то же самое. Чуть позже посмотрим, так ли это. Вадяпроверилперепроверь сам лично. скрипты все выложены. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 00:40 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov Код: sql 1. 2. 3.
Почему при уменьшении количества знаков в искомой строке время уменьшается? Это точно время всей выборки, а не первой записи? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 01:02 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft, да, ошибочка ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 01:16 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft Alex_Ustinov Код: sql 1. 2. 3.
Почему при уменьшении количества знаков в искомой строке время уменьшается? Это точно время всей выборки, а не первой записи? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 01:20 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov miksoft, да, ошибочка запускаю в dbForge , постраничный вывод у меня отключен. Или я не прав? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 01:26 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
да, в консоли 1,85сек. для 8.0.19 и для 4-знаков и для 5-ти. значит и для 5,7 тоже самое. dbForge дал время по 1-й странице вывода, получается так ну, хотел сравнение, получил только сравнение... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 01:37 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
продолжаем утреннюю зарядку с версией 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.
самое интересное - это план в 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 - не знаю это чисто сравнительный тест. С учетом "равномерного заполнения" повторяемость теста есть... имхо ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 11:06 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
результаты интересные но вот толко это ColForSearch char(30) смущает у меня varchar(255) как бы разница до 8,5 раз ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 15:51 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
я взял данные тут https://github.com/papyrussolution/UhttBarcodeReference/releases удалил дубликаты ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 16:04 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
для 8 таблица Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
хранимка Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
"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с. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 16:45 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
ЗЫ сравнивать с 5.7 - нет желания, потому как много чего там нет... даже если мои ранишние данные 5.7 и ошибочны. ЗЫ сделал так что отправка на сервер осуществляется только если после ввода символа есть пауза в 300 мс. надо сказать - очень не удобно. делать паузу ещё больше - общее время поиска увеличивается на эту паузу. отравлять на сервер по Enter - может быть... для "малого количества" отправка после ввода каждого символа - не сильно напрягает сервер. зато удобство - очень привлекательно. тут надо выбирать решение по месту , исходя из конкретных условий. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 17:00 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя результаты интересные но вот толко это ColForSearch char(30) смущает у меня varchar(255) как бы разница до 8,5 раз я просто не хочу долго ждать наполнения, будет 100% то же самое я тебе показал что ничего не поменялось на 3 версиях. Потому что я понял, что ничего ты НЕ Вадяпроверил---даже если мои ранишние данные 5.7 и ошибочны. ---- они и не ошибочны. Ошибочно у тебя воображение. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 19:00 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov какая разница, в прошлый раз было varchar(50) ты защищаешь старые версии - ну ради бога. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 19:41 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя, я не защищаю старые версии, где ты это увидел. Проделай мои тесты с полем 255. выложи и покажи нам. Если ты считаешь что Бтри дерево при 30-50 работает не также как при 255 - покажи пожалуйста результаты сравнения ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 19:53 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov я не защищаю старые версии, где ты это увидел. Проделай мои тесты с полем 255. выложи и покажи нам. Если ты считаешь что Бтри дерево при 30-50 работает не также как при 255 - покажи пожалуйста результаты сравнения проверил на 5.7.28 результаты одинаковые с 8.0.19 сам счас в недоумении почему тогда такая разница была.... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 20:33 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя да не большая. только до 5 раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 20:52 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft Для поля varchar неважно как оно объявлено, число - это лишь ограничение на длину значения. Важно фактическое наполнение. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 21:06 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя miksoft Для поля varchar неважно как оно объявлено, число - это лишь ограничение на длину значения. Важно фактическое наполнение. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 21:13 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
miksoft Если наполнять поле всегда на 30 символов (Alex_Ustinov именно так и сделал), то неважно объявлено оно varchar(50) или varchar(255). Никакого "до 5 раз" не возникает ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2020, 21:30 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадяно реально 30 это слишком мало.для чего мало? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 08:33 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov для чего мало? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 13:56 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя, а причем здесь название товаров в сравнении скорости поиска LIKE "%строка%" ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 14:35 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov а причем здесь название товаров в сравнении скорости поиска LIKE "%строка%" одно из значимых применений - поиск наименования товара, как при вводе нового, так и при наборе товара в корзину. чем быстрее будет поиск - тем удобнее для оператора/клиента ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 15:17 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя, масло масляное LIKE %строка% быстрее работать не будет. Товар или звезды на небе. ты еще умудряешься этажерки строить LIKE %строка% LIKE %строка% LIKE %строка% с FullText проверял? какие результаты? Покажи,сравним ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 16:34 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
революции в алгоритмах поиска подстроки в последние годы не было, какой смысл все это проверять? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 17:48 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov с FullText проверял? какие результаты? Покажи,сравним а эти этажерки я придумал ещё в начале нулевых. показали себя очень удобным вариантом. вопрос о ускорении - это надежда что что-то меняется в нативных кодах и прочее. вопрос о границах применения - у меня реальное значение 30к - подходит идеально. я дал ссылку с 4.7м записями - dbForge под окнами показывает 1.9 сек, но если в полном цикле - ввод в браузере - вывод в браузере - это уже до 3 сек (накапливается и манера ввода и прочее) тут есть вопрос - по работе "этажерки" если первый like не сработал - продолжается ли работа следующих или переходит к новой записи? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 18:11 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
или может задать тип поля другой? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 18:18 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Дегтярев Евгений революции в алгоритмах поиска подстроки в последние годы не было, какой смысл все это проверять? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 18:51 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадя, DdForge показывает в окне выполнения время постраничного вывода. Точное время надо смотреть в профилировщике. miksoft меня поправил, если ты читаешь внимательно FullText - конечно он другой. Но он ~ в 4 раза быстрее чем LIKE %строка%. ИНдекс может быть построен по нескольким полям. Может тогда и не надо будет поле в 255 символов... Ну ищет от 3 символов, зато базу лишний раз не дергает. Товарные сайты с контекстным LIKE %строка% ищут по вводу от 2-3 символов. LIKE %СТО% ищет кучу мусора, что очень модно но и совершенно не надо... найдет и СТОЛ и ТЕСТО и ПУСТО, он ищет вхождение подстроки а не СЛОВА. впрочем, дело вкуса, а то боюсь ты будешь трактовать что я "защищаю" фуллтекст. тут надо понять, что на 10млн LIKE %слово% вадятут есть вопрос - по работе "этажерки" если первый like не сработал - продолжается ли работа следующиха ты проверял? что у тебя получилось? на твоих данных? вадяFullText это совсем не то. тут сравнивать нечего.а вот это поясни, не понял, может я что-то не знаю? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 19:37 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov, точное время как таковое не важно. я сравниваю время когда like отфильтровывает намного менее 1000. Alex_Ustinov LIKE %СТО% ищет кучу мусора, что очень модно но и совершенно не надо... найдет и СТОЛ и ТЕСТО и ПУСТО, он ищет вхождение подстроки а не СЛОВА. FullText он ищет с начала слов. из опыта применения - операторы (после некоторого времени работы с этим поиском) начинают вводить символы не только с начала слова , а именно характерные части слов, что сразу ограничивает набор выбора. Alex_Ustinov впрочем, дело вкуса, а то боюсь ты будешь трактовать что я "защищаю" фуллтекст. тут надо понять, что на 10млн LIKE %слово% Alex_Ustinov а вот это поясни, не понял, может я что-то не знаю? Alex_Ustinov он ищет вхождение подстроки а не СЛОВА. вхождение нескольких специфичных групп символов позволяет произвести быстрый выбор нужного. насколько это важно - у меня есть многолетний опыт наблюдения как с эти работали операторши и как это помогало быстро найти нужное наименование. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 20:23 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
--- тут надо понять, что на 10млн LIKE %слово% * это тупик если в качестве контекстного поиска это и используется, то с LIMIT 10-20 для выпадающего списка. (типа магазин ВсеИНструменты) Если речь идет только об этом - то вообще не вижу смысла об этом размышлять. у меня MySql говорит что умный и после неверного условия дальше не идет Код: sql 1. 2. 3. 4.
COUNT(*) @a0 1 Код: sql 1. 2. 3. 4.
COUNT(*) @a0 2 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 20:44 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
вадявот в этом вся фишка. вхождение нескольких специфичных групп символов позволяет произвести быстрый выбор нужного. насколько это важно - у меня есть многолетний опыт наблюдения как с эти работали операторши и как это помогало быстро найти нужное наименование. условно-иногда-удобно для каких-то редких случаев. У операторов это привычка, не показатель для оценки пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 22:05 |
|
Можно ли ускорить и прочее..
|
|||
---|---|---|---|
#18+
Alex_Ustinov условно-иногда-удобно для каких-то редких случаев. У операторов это привычка, не показатель для оценки пользователя. и всё благодаря возможности быстро найти товар в базе по названию. к концу заказа - счёт уже был распечатан и засунут в факс.... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2020, 01:21 |
|
|
start [/forum/topic.php?all=1&fid=47&tid=1828610]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
148ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 270ms |
0 / 0 |