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

Question

У меня есть страница с простыми запросами 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% при выполнении запроса.

Answer 1

Круто.

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

Какой тип данных стоит разбивать на страницы в такой степени?Например, я бы нашел другой способ структурирования данных, который включает не более нескольких сотен элементов на уровень иерархического дерева.Если бы на каждом уровне было ровно 36 элементов, дерево было бы всего 4 уровня в глубину для 310К строк.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, вероятно, содержит смесь товаров из разных магазинов.
• Знаете ли вы, что «разбиение на страницы через смещение и ограничение» склонно пропускать и / или дублировать элементы в выходных данных?