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秒。在进行查询时，CPU也超过100％。

Answer 1

坚韧。

用户如何访问第940页？当然不是点击[下一步] 939次？或者它可能是一个谷歌机器人？

哪种类型的数据值得分到那个程度？我会找到一些其他方法来构造数据，例如，每个级别的分层树不涉及超过几百个项目。如果每个级别只有36个项目，那么对于310K行，树只有4个级别。 3次点击比939好。和基础查询会更快。即使是直接的2级商店+产品层次结构也会有很大帮助。

行。我会给你一些可以做些什么的线索。

首先。请提供SHOW CREATE TABLE;你遗漏了一堆有用的信息。

ID_PRODUCT是唯一的吗？如果是，也许它应该是PRIMARY KEY？评论意味着PRIMARY KEY(id_product, store)（以任何顺序）都是有益的。
INDEX(stock, hide)（按任意顺序）可能有助于提升表现。
INDEX(stock, hide, id)，加上将分页更改为＆＃34;记住你离开的地方＆＃34;会使分页速度极快。进一步讨论here。
`innodb_buffer_pool_size？
100％CPU意味着您不受I / O约束，我们需要关注索引和查询公式。（硬件升级没有用 - 今天所有CPU的速度大致相同。）
你说ORDER BY id DESC;那有必要吗？或者其他一些订单可以吗？请注意，第940页可能包含混合商店的混合产品。
您是否知道＆＃34;分页通过偏移和限制＆＃34;是否容易在输出中跳过和/或复制项目？

慢sql查询 - 超过15000ms - 简单的SELECT查询，CPU超过100％

1 个答案: