Медленный SQL-запрос - более 15000 мс - простой запрос SELECT, процессор более 100%

Question

Медленный SQL-запрос - более 15000 мс - простой запрос SELECT, процессор более 100%

0

У меня есть страница с простыми sql-запросами:

Посетитель находится на странице 940, поэтому мне нужно найти продукты, чтобы показать на этой странице:

SELECT * 
FROM items 
WHERE stock = 1 AND hide = 0 
ORDER BY id DESC 
LIMIT 36 
OFFSET 33804

этот запрос занимает 15463.242 ms.

Также мне нужно показать фильтр с производителями, размеры и информацию о магазине для всех продуктов на складе:

SELECT MANUFACTURER, sizes, store 
FROM items 
WHERE stock = 1 AND hide = 0

это занимает 17996.684 ms.

Я не понимаю, почему так много времени.

Структура таблицы:

id  int(11) Auto Increment   
ID_PRODUCT  varchar(200)     
PRODUCT varchar(200)     
DESCRIPTION mediumtext   
URL varchar(300)     
PRICE_VAT   int(7)   
MANUFACTURER    varchar(150)     
CATEGORY    varchar(150)     
IMGSURL varchar(3000)    
catids  varchar(30)  
sizes   varchar(30)  
store   varchar(30)  
stock   int(1)   
hide    int(1)

Информация о таблице:

Data size: 327 974 912
Index size: 12 075 008
Free space: 4 194 304
Rows: 310 823

Он использует InnoDB и mysql 5.5.5-10.0.29-MariaDB-0 + deb8u1.

Не могли бы вы помочь мне, что не так с этими запросами? Посетители не могут ждать более 30 секунд. Кроме того, процессор выполняет более 100% при выполнении запроса hte.

JackDavis 20 май 2018, в 14:45

Источник

2

Каков индекс ваших таблиц? 300к строк кажутся не слишком много
Mạnh Quyết Nguyễn 20 май 2018, в 12:24
1

У вас есть индексы?
SQL Hacks 20 май 2018, в 12:24
0

Спасибо за ответ. Да, у меня есть индексы. PRIMARY - это идентификатор, а INDEX - это ID_PRODUCT. Я не знаю, правильно ли это. id - это уникальное значение int с автоматическим приращением, а ID_PRODUCT уникально для комбинации с хранилищем. (когда я обновляю базу данных, мне нужно найти товары с 'select * from items, где id_product =? и store =?')
JackDavis 20 май 2018, в 12:25
1

Создайте индекс для своего stock и hide поле и повторите запрос
Mạnh Quyết Nguyễn 20 май 2018, в 12:25
0

Благодарю. Я попробовал это, и это быстрее. Первый запрос занимает 4253,172 мс, а второй - 3876,506 мс. В любом случае, я бы сделал это быстрее.
JackDavis 20 май 2018, в 12:32
1

известно, что производительность MySQL плохая, когда вы используете большое число смещений в пределах лимита. MySQL требуется сохранение 33804 + 36 = 33840 записей в памяти. Если вы используете EXPLAIN, вы увидите, что MySQL, вероятно, использует «использование файловой сортировки с использованием временной таблицы». для этого запроса эта комбинация является настоящим убийцей производительности в MySQL ... Наиболее оптимальный индекс для этого запроса - items(stock, hide, id)
Raymond Nijland 20 май 2018, в 12:38
0

Спасибо за ответ. Да, он использует сортировку файлов. Есть ли более быстрая альтернатива сортировке файлов или как крупные сайты сортируют свои данные?
JackDavis 20 май 2018, в 12:41
0

@JackDavis - Ваш последний комментарий делает «предположения, которых нет в доказательствах». INDEX имеет вещи предварительно отсортированы; Индекс Раймонда обеспечивает этот трюк. Большие сайты избегают сортировки. Один способ указан в моем ответе.
Rick James 27 май 2018, в 00:52

Показать ещё 6 комментариев

Теги:

mysql

mariadb

1 ответ

Ещё вопросы

Каков индекс ваших таблиц? 300к строк кажутся не слишком много
Спасибо за ответ. Да, у меня есть индексы. PRIMARY - это идентификатор, а INDEX - это ID_PRODUCT. Я не знаю, правильно ли это. id - это уникальное значение int с автоматическим приращением, а ID_PRODUCT уникально для комбинации с хранилищем. (когда я обновляю базу данных, мне нужно найти товары с 'select * from items, где id_product =? и store =?')
Создайте индекс для своего stock и hide поле и повторите запрос
Благодарю. Я попробовал это, и это быстрее. Первый запрос занимает 4253,172 мс, а второй - 3876,506 мс. В любом случае, я бы сделал это быстрее.
известно, что производительность MySQL плохая, когда вы используете большое число смещений в пределах лимита. MySQL требуется сохранение 33804 + 36 = 33840 записей в памяти. Если вы используете EXPLAIN, вы увидите, что MySQL, вероятно, использует «использование файловой сортировки с использованием временной таблицы». для этого запроса эта комбинация является настоящим убийцей производительности в MySQL ... Наиболее оптимальный индекс для этого запроса - items(stock, hide, id)
Спасибо за ответ. Да, он использует сортировку файлов. Есть ли более быстрая альтернатива сортировке файлов или как крупные сайты сортируют свои данные?
@JackDavis - Ваш последний комментарий делает «предположения, которых нет в доказательствах». INDEX имеет вещи предварительно отсортированы; Индекс Раймонда обеспечивает этот трюк. Большие сайты избегают сортировки. Один способ указан в моем ответе.

Rick James · Answer 1 · 2018-05-26T22-57-00.000Z

Tough.

Как пользователь добрался до страницы 940? Конечно, не нажав [Далее] 939 раз? Или, может быть, это робот Google?

Какой тип данных стоит в такой степени? Например, я бы нашел другой способ структурирования данных, которые не включают более нескольких сотен элементов на уровень иерархического дерева. Если на каждом уровне было ровно 36 элементов, дерево было бы всего 4 уровня для строк 310K. 3 клика лучше, чем 939. И базовый запрос будет быстрее. Даже простая двухуровневая иерархия магазина + продукта очень помогла бы.

ХОРОШО. Я дам вам несколько подсказок о том, что можно сделать.

Первый. Предоставьте SHOW CREATE TABLE; вы оставили кучу полезной информации.

Является ли ID_PRODUCT уникальным? Если это так, возможно, это должен быть PRIMARY KEY? Комментарий подразумевает, что PRIMARY KEY(id_product, store) (в любом порядке) будет полезен.
INDEX(stock, hide) (в любом порядке) может помочь в производительности.
INDEX(stock, hide, id), а также изменение разбивки на страницы, чтобы "запомнить, где вы остановились", сделало бы разбивку на страницы намного быстрее. Дальнейшее обсуждение здесь.
Какова ценность 'innodb_buffer_pool_size?
100% процессор подразумевает, что вы не привязаны к I/O, и нам нужно сосредоточиться на индексах и формулировке запросов. (Аппаратное обновление не полезно - все процессоры сегодня имеют одинаковую скорость).
Вы говорите ORDER BY id DESC; это необходимо? Или какой-нибудь другой порядок будет в порядке? Обратите внимание, что страница 940, вероятно, содержит смесь продуктов из смеси магазинов.
Знаете ли вы, что "разбиение на страницы с помощью смещения и ограничения" подвержено пропуску и/или дублированию элементов на выходе?