|
|
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
Alex_UstinovLumix, это наверное шутка (?........) тащить по инету 84М popotable c popopole varchar(50)? ))) вы же кодер... накодьте на коленке... примерно следующее.... [ Не шутка, а дотошный подход экспериментатора. Пусть вываливает в точности то, что там у него "ускоряется". Другие уж посмотрят и поймут что и почему там "ускоряется". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2015, 13:30:58 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вот 89М сжата 7zip, скрипт снят с 5.7.9 действующее поле name. первое выполение -15 сек, чтение в память последующее 5 сек 5 сек это если в like находится заведомо не существующее тестируемый запрос Код: sql 1. 2. 3. 4. 5. для использования как у меня генерится такой запрос Код: sql 1. 2. 3. 4. 5. где st1, st2, st3 части строки , не обязательно с начала или конца слова , таких str может быть любое число, но практика показывает, что 4 это уже пербор, т.е. находится строка раньше. для особенно пытливых такой варант 18354478 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2015, 15:13:44 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
особое влияние оказывает innodb_buffer_pool_size = 512M тут уже у кого что позволяет система , рекомендуют до 80% от всего озу.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2015, 15:15:54 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя, ну это несерьезно, сравнивать надо при одинаковых конфигах и с SQL_NO_CACHE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2015, 17:08:28 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
Код: plaintext и если он из кэша берёт за 4 сек - это что за кэш? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2015, 17:51:41 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
авторну это несерьезно, сравнивать надо при одинаковых конфигах я не жду подтверждения моих цифр (4 сек) я хочу увидеть значительную разницу зы на оракле такое же время выборки ~4-6сек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2015, 17:54:25 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя, развивеваю миф об ускорении на фактах продолжу, пока появилось время 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. тайминги по 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. во время выполнения запросов сразу после перезапуска 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 часа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2015, 22:25:44 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinov, я что—то не понял в тврих отчетах.... заголовки перепутаны? у меня в like %что-то% вот этого что-то определённо нет в данных , поэтому происходит поиск по всей таблице. что такое "развивеваю" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 02:27:40 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя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. очепятка, правильно должно быть развеиваю миф , это тоже самое что у вас - "я что—то не понял в тврих отчетах..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 16:12:13 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя, и я же указал - запускаю сервера по одному, раздельно, и ручками (mysqld -- console)? перепутать я не мог MySQL 5.6 скачивать не стал, сразу взял еще ниже 5.5 сейчас качну выложу тайминги по 5.6 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 16:30:12 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinov, по твоим опытам получается 5.5 использует индексы , а 5.7 нет? когда я ищу не существующее — я заставляю сканировать все данные, это самая длительная операция. если поиск существующего , то оно может встретиться и раньше — нельзя серьёзно говорить о времени. и 10 000 000 намного больше 2 000 000..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 17:02:09 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя, 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. и наоборот, заявленное в 5.7 использование индекса для like %poioi% совершенно не работает никакого ускорения я не вижу. Теперь наоборот не советую даже ставить 5.7 Я сам дурак, пользуюсь только Марией и воткнул уже 10.1.8, буду даунгрейтится. В других местах могут быть такие же непредсказуемости... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 18:06:39 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinovя не говорю что используется индекс , но используется алгоритм, который теперь в 5.7 отсутствует и наоборот, заявленное в 5.7 использование индекса для like %poioi% совершенно не работаетЯ где-то видел упоминание, что like %poioi% может использовать два разных алгоритма поиска подстроки в строке в зависимости от длины искомой подстроки. Если это так, то имело смысл в эксперименте и длинные подстроки поискать. Возможно, в новых версиях изменился этот порог или даже сам принцип. А еще, помнится, тут на форуме кто-то показывал, что функция LOCATE работает быстрее, чем LIKE %poioi%. Интересно, так ли это в новых версиях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 18:58:20 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
я показывал план - 5.7 индекс использует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 19:05:32 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
автори наоборот, заявленное в 5.7 использование индекса для like %poioi% совершенно не работает никакого ускорения я не вижу. Теперь наоборот не советую даже ставить 5.7 что-то ты не то делаешь... у тебя совершенно противоположные результаты. ч проверял на множестве установок на debian 7 и 8.. и на ноуте под win7 результат повторяемость. поле текстовое проиндексировано , и под 5.7. план показывает использование индекса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 19:19:39 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
авторА еще, помнится, тут на форуме кто-то показывал, что функция LOCATE работает быстрее, чем LIKE %poioi%. Интересно, так ли это в новых версиях. Код: sql 1. 2. 3. 4. 5. №idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra11SIMPLEpass(null)index(null)IDX_pass_name153(null)8931276100Using where; Using index время такое же как и like.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 19:43:36 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
ыы отсутствует в данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 19:45:05 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя, открой мой спойлер - там тоже показан план 5.7 - якобы индекс используется я же все показываю, вадя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 19:55:34 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
вадя Код: sql 1. Замените на Код: sql 1. вадявремя такое же как и like....Насколько точно такое же (с учетом моей правки)? Да и тогда разница была всего на единицы процентов, хотя и устойчивая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 19:59:56 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
miksoft, да я проверил и до твоей правки :) время одного порядка - 4-6 сек видимо влияет работа процессора над другими задачами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 20:20:27 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
в общем говорить о разнице не приходится - в пределах точности измерения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 20:24:37 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
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 записей неоднозначно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 20:32:19 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinov, ещё раз, тестирование на просмотр всей таблицы - поиск отсутствкющих ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 20:49:49 |
|
||
|
Ускорение LIKE '%str%' в версии 5.7
|
|||
|---|---|---|---|
|
#18+
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 записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2015, 20:49:59 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39097768&tid=1832526]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
45ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 343ms |

| 0 / 0 |
