ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Можно ли ускорить и прочее..
25 сообщений из 68, страница 2 из 3
  2  все
Можно ли ускорить и прочее..
    #39948788
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
Alex_Ustinov
вадя
пропущено...
проверил
давай по существу. В прошлый раз я потерял часов 6 ночью думал у тебя это горит, оказалось что ты просто собирал статистику.
Я сейчас подниму свои скрипты, ты посмотри свои. сверимся по параметрам.
у меня есть ПК на винде и я подниму любой скаченыый МайСкуль за 2 минуты максимум. Это я о том что ты сидишь на Дебе и не упорядочить-поднять два МайСкуля
*не можешь упорядочить как поднять разные версии. Такое ощущение что ты делаешь просто опрос - "а как ребята у вас? а у них так..."
можно удалить не глядя...
...
Рейтинг: 0 / 0
19.04.2020, 18:26
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948797
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Alex_Ustinov
*не можешь упорядочить как поднять разные версии. Такое ощущение что ты делаешь просто опрос - "а как ребята у вас? а у них так..."
можно удалить не глядя...
ну поднимать - у меня всё и 5.7. и 8 развернуты
вот только не вижу смысла что-либо на 5.7 пробовать...
...
Рейтинг: 0 / 0
19.04.2020, 19:05
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948804
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
ну что, тогда потестим? говори версии, я делаю соответствие.
У меня будут нулевые БД
Делаем таблицу для теста с одинаковым наполнением.
Ты можешь оказаться и правым, не стесняйся, я готов к поражению, тем более все на скл ру
...
Рейтинг: 0 / 0
19.04.2020, 20:32
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948805
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
условие - таблица до 2-3 млн с одним полем 10-12 знаков char() поиск 4 знака (ну как ты приводил пример с Майскуру, что там используется сепер пупер поиск для 3 и более знаков БойляМариота(не помню дословно)) пиши конкретику
...
Рейтинг: 0 / 0
19.04.2020, 20:39
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948809
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Alex_Ustinov
ну что, тогда потестим? говори версии, я делаю соответствие.
давай потестим - я могу скинуть таблицу
...
Рейтинг: 0 / 0
19.04.2020, 21:06
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948811
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
вадя,

ты с ума сошел - давай ddl и раунд-заполнение, зачем мне твои мегА
по твоим данным проверять не будем, твою задачу решай сам
...
Рейтинг: 0 / 0
19.04.2020, 21:11
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948812
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
вадя
Alex_Ustinov
ну что, тогда потестим? говори версии, я делаю соответствие.
давай потестим - я могу скинуть таблицу
версии майскуля пиши, и 5.7 и 8(плюсы круто, но лучше точную цифру)
...
Рейтинг: 0 / 0
19.04.2020, 21:12
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #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
20.04.2020, 14:48
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39948997
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Ещё одним сюрпризом может стать отсутствие в MySQL 8 встроенного механизма кэширования запросов 
query cache, который широко использовался в предыдущих версиях. Данная функция уже довольно давно 
значилась как deprecated и вот, наконец, момент настал.

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

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

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

моё мнение что послу 1 000 000 надо уже другое использовать.
...
Рейтинг: 0 / 0
20.04.2020, 16:39
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951228
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
25.04.2020, 00:40
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951234
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
25.04.2020, 01:02
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951237
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
miksoft,

да, ошибочка
...
Рейтинг: 0 / 0
25.04.2020, 01:16
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951238
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
25.04.2020, 01:20
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951239
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
Alex_Ustinov
miksoft,

да, ошибочка
не 1,8 это профилировщик, сам запрос так и есть 0,2
запускаю в dbForge , постраничный вывод у меня отключен.
Или я не прав?
...
Рейтинг: 0 / 0
25.04.2020, 01:26
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951242
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex_Ustinov
Участник
да, в консоли 1,85сек. для 8.0.19 и для 4-знаков и для 5-ти.
значит и для 5,7 тоже самое.
dbForge дал время по 1-й странице вывода, получается так
ну, хотел сравнение, получил только сравнение...
...
Рейтинг: 0 / 0
25.04.2020, 01:37
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951287
Фотография Alex_Ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
25.04.2020, 11:06
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951356
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
результаты интересные но вот толко это
ColForSearch char(30)
смущает
у меня
varchar(255)
как бы разница до 8,5 раз
...
Рейтинг: 0 / 0
25.04.2020, 15:51
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951360
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
я взял данные тут https://github.com/papyrussolution/UhttBarcodeReference/releases
удалил дубликаты
...
Рейтинг: 0 / 0
25.04.2020, 16:04
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #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
25.04.2020, 16:45
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951391
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
ЗЫ
сравнивать с 5.7 - нет желания, потому как много чего там нет...
даже если мои ранишние данные 5.7 и ошибочны.

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

я не защищаю старые версии, где ты это увидел.
Проделай мои тесты с полем 255. выложи и покажи нам.
Если ты считаешь что Бтри дерево при 30-50 работает не также как при 255 - покажи пожалуйста результаты сравнения
...
Рейтинг: 0 / 0
25.04.2020, 19:53
| Ответить | Цитировать | Написать  
Можно ли ускорить и прочее..
    #39951462
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Alex_Ustinov
я не защищаю старые версии, где ты это увидел.
Проделай мои тесты с полем 255. выложи и покажи нам.
Если ты считаешь что Бтри дерево при 30-50 работает не также как при 255 - покажи пожалуйста результаты сравнения
каюсь, каюсь....
проверил на 5.7.28
результаты одинаковые с 8.0.19
сам счас в недоумении почему тогда такая разница была....
...
Рейтинг: 0 / 0
25.04.2020, 20:33
| Ответить | Цитировать | Написать  
25 сообщений из 68, страница 2 из 3
  2  все
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Можно ли ускорить и прочее..
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=39951238&tid=1828610]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 145ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 16ms
total:  270ms
созд. / загр.: 270ms
x
x
Закрыть


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