powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Ускорение LIKE '%str%' в версии 5.7
25 сообщений из 121, страница 4 из 5
Ускорение LIKE '%str%' в версии 5.7
    #39092680
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_UstinovLumix,

это наверное шутка (?........) тащить по инету 84М popotable c popopole varchar(50)? )))
вы же кодер... накодьте на коленке... примерно следующее....
[
Не шутка, а дотошный подход экспериментатора.
Пусть вываливает в точности то, что там у него "ускоряется". Другие уж посмотрят и поймут что и почему там "ускоряется".
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39092842
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот 89М сжата 7zip, скрипт снят с 5.7.9
действующее поле name.
первое выполение -15 сек, чтение в память
последующее 5 сек
5 сек это если в like находится заведомо не существующее

тестируемый запрос
Код: sql
1.
2.
3.
4.
5.
SELECT
  pass.id,
  pass.name
FROM pass
WHERE pass.name LIKE '%wretwrtvwre rtwerctwretwrtcertyt5y3twwcrtwc%' LIMIT 5;  


для использования как у меня генерится такой запрос
Код: sql
1.
2.
3.
4.
5.
SELECT SQL_SMALL_RESULT
  pass.id,
  pass.name
FROM pass
WHERE pass.name LIKE '%st1%' and pass.name LIKE '%st2%' and pass.name LIKE '%st3%' LIMIT 5


где st1, st2, st3 части строки , не обязательно с начала или конца слова , таких str может быть любое число, но практика показывает, что 4 это уже пербор, т.е. находится строка раньше.
для особенно пытливых такой варант 18354478
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39092849
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
особое влияние оказывает
innodb_buffer_pool_size = 512M
тут уже у кого что позволяет система , рекомендуют до 80% от всего озу....
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39093023
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

ну это несерьезно, сравнивать надо при одинаковых конфигах и с SQL_NO_CACHE
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39093063
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
Параметр SQL_NO_CACHE запрещает MySQL хранить результат запроса в кэше запросов
неужели я не пробывал перед запуском менять параметр like?
и если он из кэша берёт за 4 сек - это что за кэш?
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39093065
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторну это несерьезно, сравнивать надо при одинаковых конфигах
я не жду подтверждения моих цифр (4 сек)
я хочу увидеть значительную разницу
зы
на оракле такое же время выборки ~4-6сек
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097406
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

развивеваю миф об ускорении на фактах

продолжу, пока появилось время
MySQL 5.5.46
MySQL 5.7
MariaDB-10.1.8 (основана на MySQL-5.7)
идентичные конфиги, запуск раздельно
кэш запросов отключен
все в ДБфорж, он добавляет к запросам LIMIT 1000
таблица и заполнение здесь
поле поменял на pole varchar(50) UTF-8


MySQL 5.7 table popotable 2 млн больше не стал заполнять, нет времени идентично предыдущей БД

5.7
Код: 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.
innodb_buffer_pool_size = 128M
SELECT COUNT(id) FROM popotable
SELECT COUNT(*) FROM popotable
идентичны
SQL.sql: Запрос открыт за 3,341c [3,341c выполнение, < 0,001c выборка]
SQL.sql: Запрос открыт за 3,783c [3,783c выполнение, < 0,001c выборка]
2000000 записей

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%sfhox%"; /*5 символов*/
/*SQL1.sql: Запрос открыт за 70,665c [9,303c выполнение, 61,362c выборка]
215 записей*/
1	SIMPLE	p	index	(null)	IDX_popo	53	(null)	1853560	Using where; Using index

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%wulsf%"; /*5 символов*/
/*SQL1.sql: Запрос открыт за 81,848c [4,367c выполнение, 77,481c выборка]
929 записей*/

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%nxyagg%"; /*6 символов*/
/*SQL1.sql: Запрос открыт за 71,541c [12,979c выполнение, 58,562c выборка]
200 записей */
SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%xglgbqvh%"; /*8 символов*/
/* SQL1.sql: Запрос открыт за 69,894c [69,877c выполнение, 0,017c выборка]
SQL1.sql: Запрос открыт за 46,584c [46,569c выполнение, 0,015c выборка]
1 запись */
все запросы с начала строки LIKE "ЧТО-ТО%" выполняются за < 0,5 сек
innodb_buffer_pool_size = 5M 
первый запуск после рестарта - SQL1.sql: Запрос открыт за 168,337c [22,146c выполнение, 146,191c выборка]
1. SQL1.sql: Запрос открыт за 80,732c [9,454c выполнение, 71,278c выборка]
2. SQL1.sql: Запрос открыт за 81,848c [4,367c выполнение, 77,481c выборка]
все по 80 - предсказуемо, таблица не в пуле
EXPLAIN просто чудо
1	SIMPLE	p	index	(null)	IDX_popo	153	(null)	1951036	Using where; Using index


тайминги по 50-70 сек
MariaDB 10.1.8 (основа - 5.7) table popotable 2 млн больше не стал заполнять, нет времени идентично предыдущей БД

все показатели аналогичны MySQL 5.7 , так как набор данных генерировался под каждую версию с "нуля",
расхождение в +- 5 сек для каждого запроса.

MySQL 5.5.46 table popotable 2 млн больше не стал заполнять, нет времени

вот те бабушка и юрьев день...
Код: 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.
innodb_buffer_pool_size = 128M
SELECT COUNT(id) FROM popotable
SELECT COUNT(*) FROM popotable
идентичны
SQL.sql: Запрос открыт за 2,345c [2,345c выполнение, < 0,001c выборка]
SQL.sql: Запрос открыт за 2,260c [2,260c выполнение, < 0,001c выборка]
2000000 записей

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%sfhox%"; /*5 символов*/
/*SQL1.sql: Запрос открыт за 2,536c [0,441c выполнение, 2,095c выборка]
208 записей*/
1	SIMPLE	p	ALL	(null)	(null)	(null)	(null)	1992609	Using where

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%wulsf%"; /*5 символов*/
/*SQL1.sql: Запрос открыт за 2,312c [0,112c выполнение, 2,200c выборка]
929 записей*/

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%nxyagg%"; /*6 символов*/
/*SQL1.sql: Запрос открыт за 2,554c [0,343c выполнение, 2,211c выборка]
197 записей */
SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%xglgbqvh%"; /*8 символов*/
/* SQL1.sql: Запрос открыт за 2,327c [2,276c выполнение, 0,051c выборка]
5 записей */

innodb_buffer_pool_size = 5M 
ТЕ ЖЕ результаты

время выполнения всех операций - не более 3 сек
во время выполнения запросов сразу после перезапуска MySQL нет никаких 30-35 секунд, сразу по ~2.5сек
тесты специально делались под напряжным дефолтным конфигом
my.cnf# Example MySQL config file for small systems.
# The MySQL server
[mysqld]
key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 240K
query_cache_size = 0
default_storage_engine = InnoDB

#skip-networking
server-id = 1

# Uncomment the following if you want to log updates
#log-bin=mysql-bin

# binary logging format - mixed recommended
#binlog_format=mixed

# Causes updates to non-transactional engines using statement format to be
# written directly to binary log. Before using this option make sure that
# there are no dependencies between transactional and non-transactional
# tables such as in the statement INSERT INTO t_myisam SELECT * FROM
# t_innodb; otherwise, slaves may diverge from the master.
#binlog_direct_non_transactional_updates=TRUE

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = C:\\mysql\\data\\
#innodb_data_file_path = ibdata1:50M:autoextend
#innodb_log_group_home_dir = C:\\mysql\\data\\
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 2M
#innodb_additional_mem_pool_size = 5M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

во всех БД поиск с начала строки - 0.1-0.3 сек (а-ля LIKE "трынь-трынь%")
не комментирую, не делаю выводы, только голые факты....
-------------
суббота, я просто убил 2 часа
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097463
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov,
я что—то не понял в тврих отчетах....
заголовки перепутаны?
у меня в like %что-то%
вот этого что-то определённо нет в данных , поэтому происходит поиск по всей таблице.
что такое "развивеваю" ?
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097637
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадяAlex_Ustinov,
1. я что—то не понял в тврих отчетах....
заголовки перепутаны?
2. у меня в like %что-то%
вот этого что-то определённо нет в данных , поэтому происходит поиск по всей таблице.
3. что такое "развивеваю" ?
1. ничего не перепутано, в ДБФорже нажав в списке слева на подключение, можно увидеть версию сервера
2. у меня тоже везде like %что-то%, под спойлером же все очевидно
если таких данных нет = (а с чем связана проверка когда нет данных? какая разница индексу, есть данные или нет?)
но все же (мусорные таблицы я не удалял, проверить не долго)
5.7.9
SELECT * FROM test.popotable p WHERE p.pole LIKE "%123456%" -
первый запуск 110сек
повторные 50-60 сек
5.5.46
SELECT * FROM popotable p WHERE p.pole LIKE "%1144456%"
первый запуск - 3 сек.
3. очепятка, правильно должно быть развеиваю миф , это тоже самое что у вас - "я что—то не понял в тврих отчетах..."
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097642
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

и я же указал - запускаю сервера по одному, раздельно, и ручками (mysqld -- console)? перепутать я не мог
MySQL 5.6 скачивать не стал, сразу взял еще ниже 5.5
сейчас качну выложу тайминги по 5.6
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097660
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov,
по твоим опытам получается 5.5 использует индексы , а 5.7 нет?
когда я ищу не существующее — я заставляю сканировать все данные, это самая длительная операция. если поиск существующего , то оно может встретиться и раньше — нельзя серьёзно говорить о времени. и 10 000 000 намного больше 2 000 000.....
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097691
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

5.6.27
Код: 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.
innodb_buffer_pool_size = 128M
SELECT COUNT(id) FROM popotable
SELECT COUNT(*) FROM popotable
идентичны
SQL.sql: Запрос открыт за 1,269c [1,269c выполнение, < 0,001c выборка]
SQL.sql: Запрос открыт за 1,303c [1,303c выполнение, < 0,001c выборка]

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%123456%"; /* нет такого значения*/
SQL.sql: Запрос открыт за 2,928c [2,923c выполнение, 0,005c выборка]
0 записей

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%sfhox%"; /*5 симв*/
SQL.sql: Запрос открыт за 3,251c [0,696c выполнение, 2,555c выборка]
217 записей

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%nxyagg%";/*6 симв*/
SQL.sql: Запрос открыт за 3,181c [0,758c выполнение, 2,423c выборка]
165 записей

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%xglgbqvh%"; /*8 симв*/
SQL.sql: Запрос открыт за 3,258c [3,256c выполнение, 0,002c выборка]
4 записи

и т.д. больше не вижу смысла, и так понятно
EXPLAIN
1	SIMPLE	p	ALL	(null)	(null)	(null)	(null)	1991801	Using where


я не говорю что используется индекс , но используется алгоритм, который теперь в 5.7 отсутствует
и наоборот, заявленное в 5.7 использование индекса для like %poioi% совершенно не работает
никакого ускорения я не вижу.
Теперь наоборот не советую даже ставить 5.7
Я сам дурак, пользуюсь только Марией и воткнул уже 10.1.8, буду даунгрейтится. В других местах могут быть такие же непредсказуемости...
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097710
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinovя не говорю что используется индекс , но используется алгоритм, который теперь в 5.7 отсутствует
и наоборот, заявленное в 5.7 использование индекса для like %poioi% совершенно не работаетЯ где-то видел упоминание, что like %poioi% может использовать два разных алгоритма поиска подстроки в строке в зависимости от длины искомой подстроки. Если это так, то имело смысл в эксперименте и длинные подстроки поискать. Возможно, в новых версиях изменился этот порог или даже сам принцип.

А еще, помнится, тут на форуме кто-то показывал, что функция LOCATE работает быстрее, чем LIKE %poioi%. Интересно, так ли это в новых версиях.
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097714
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я показывал план - 5.7 индекс использует
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097720
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автори наоборот, заявленное в 5.7 использование индекса для like %poioi% совершенно не работает
никакого ускорения я не вижу.
Теперь наоборот не советую даже ставить 5.7
что-то ты не то делаешь...
у тебя совершенно противоположные результаты.
ч проверял на множестве установок на debian 7 и 8..
и на ноуте под win7
результат повторяемость.
поле текстовое проиндексировано , и под 5.7. план показывает использование индекса
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097729
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА еще, помнится, тут на форуме кто-то показывал, что функция LOCATE работает быстрее, чем LIKE %poioi%. Интересно, так ли это в новых версиях.
Код: sql
1.
2.
3.
4.
5.
 SELECT   
  pass.id,
  pass.name
FROM pass
WHERE LOCATE('ыы',IFNULL(pass.name,'')) > 0 LIMIT 5 ;


№idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra11SIMPLEpass(null)index(null)IDX_pass_name153(null)8931276100Using where; Using index
время такое же как и like....
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097731
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ыы отсутствует в данных
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097738
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,

открой мой спойлер - там тоже показан план 5.7 - якобы индекс используется
я же все показываю, вадя
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097741
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
Код: sql
1.
LOCATE('ыы',IFNULL(pass.name,'')) > 0

Замените на
Код: sql
1.
LOCATE('ыы',pass.name)


вадявремя такое же как и like....Насколько точно такое же (с учетом моей правки)? Да и тогда разница была всего на единицы процентов, хотя и устойчивая.
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097751
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,
да я проверил и до твоей правки :)
время одного порядка - 4-6 сек
видимо влияет работа процессора над другими задачами.
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097755
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в общем говорить о разнице не приходится - в пределах точности измерения
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097757
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

это MySQL 5.6
1
SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%sfhox%";
SQL.sql: Запрос открыт за 3,180c [0,952c выполнение, 2,228c выборка]
SELECT p.id, p.pole FROM popotable p WHERE LOCATE( "sfhox",p.pole)>0;
SQL.sql: Запрос открыт за 4,110c [0,619c выполнение, 3,491c выборка]
223 записи


2
SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%nxyagg%";
SQL.sql: Запрос открыт за 2,856c [0,444c выполнение, 2,412c выборка]
SELECT p.id, p.pole FROM popotable p WHERE LOCATE( "nxyagg",p.pole)>0;
SQL.sql: Запрос открыт за 3,887c [0,599c выполнение, 3,288c выборка]
155 записей

неоднозначно
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097765
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov,
ещё раз, тестирование на просмотр всей таблицы - поиск отсутствкющих
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097766
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MySQL 5.7

SELECT p.id, p.pole FROM popotable p WHERE p.pole like "%sfhox%";
SQL.sql: Запрос открыт за 88,565c [12,290c выполнение, 76,275c выборка]

SELECT p.id, p.pole FROM popotable p WHERE LOCATE("sfhox", p.pole);
SQL.sql: Запрос открыт за 80,777c [4,451c выполнение, 76,326c выборка]
201 записей
...
Рейтинг: 0 / 0
Ускорение LIKE '%str%' в версии 5.7
    #39097768
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Ustinov,
ты где-то путаешь....
...
Рейтинг: 0 / 0
25 сообщений из 121, страница 4 из 5
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Ускорение LIKE '%str%' в версии 5.7
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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