【发布时间】:2009-07-23 02:49:03
【问题描述】:
我有一个正在尝试优化的浏览类别查询。我以使用临时结束;在解释中使用文件排序,并且查询在具有 60,000 行的类别上很慢。如果我删除 Order By 子句,查询运行速度非常快 0.05 秒以执行 60,000 行。使用 Order By 子句,它的速度非常慢,大约 5 秒。 Parts 和 Parts_Category 一样包含大约 500,000 行。
我有一个名为 sort_index 的部件组索引(状态、级别、仓库、更新)
在解释的顶部我有 |全部 |使用临时的;使用文件排序
所有其他索引都显示正常。有人可以告诉我可能是什么问题吗?我没主意了。也许我应该重新排列这个查询,以便获得更好的性能?
查询。
SELECT Parts.*, Image.type, Image.width, Image.height,
(SELECT name FROM Location_State WHERE id = Parts.state_id) AS state,
(SELECT name FROM Location_Region WHERE id = Parts.region_id) AS region,
(SELECT start_date FROM Promotion WHERE id = Parts.promotion_id) AS promotion_start_date,
(SELECT end_date FROM Promotion WHERE id = Parts.promotion_id) AS promotion_end_date
FROM ( SELECT parts_id FROM Parts_Category WHERE Parts_Category.category_id = '40'
UNION SELECT parts_id FROM Parts_Category WHERE Parts_Category.main_category_id = '40') cid
LEFT JOIN Image ON Parts.image_id = Image.id
JOIN Parts ON Parts.id = cid.parts_id AND Parts.status = 'A'
ORDER BY Parts.level DESC, Parts.warehouse DESC, Parts.updated DESC LIMIT 0, 15
表格部件的表格结构
字段类型 Null 默认值
id int(11) 无 auto_increment
image_id int(11) 是 0
gallery_id int(11) 是 0
image_count int(3) 是 0
Promotion_id int(11) 是 0
country_id int(11) 是 NULL
state_id int(11) 是 NULL
region_id int(11) 是 NULL
city_id int(11) 是 NULL
area_id int(11) 是 NULL
更新日期时间 是 0000-00-00 00:00:00
输入日期时间 是 0000-00-00 00:00:00
续订日期 是 0000-00-00
discount_id varchar(10) 是 NULL
标题 varchar(100) 是
search_title varchar(255) 是
仓库 varchar(50) 是
url varchar(255) 是
display_url varchar(255) 是
friendly_url varchar(100) 是 NULL
说明 varchar(255) 是
关键字 varchar(1000) 是 NULL
附件文件 varchar(255) 是
attachment_caption varchar(255) 是
状态字符(1) 是
级别 tinyint(3) 是 0
全球 tinyint(1) 是 0
random_number int(11) 是 NULL
提醒 tinyint(4) 是 NULL
category_search varchar(1000) 是
video_sn -p varchar(1000) 是
importID int(11) 是 0
索引
主要编号 518623
随机数索引 32201 随机数
country_id 索引 1 country_id
state_id 索引 8 state_id
region_id 索引 5 region_id
更新日期索引 1 更新日期
全球 INDEX 1 全球
友好的 URL 索引 518623 友好的 URL
Promotion_id 索引 1 Promotion_id
city_id 索引 1 city_id
area_id 索引 1 area_id
邮编索引 2790 邮编
进口 ID 索引 518623 进口 ID
image_id 索引 10 image_id
--------------
index_browse_category 索引 52
等级
地位
仓库
更新
-----------------
关键词全文 1
描述
关键词
类别搜索
Parts_Category
id int(11) 无 auto_increment
parts_id int(11) 否 0
category_id int(11) 否 0
main_category_id int(10) 否 0
指数
初级 初级 519330 id
category_id 索引 519330 category_id
零件编号
main_category_id 索引 519330 main_category_id
零件编号
【问题讨论】:
-
约翰,我在下面给出了初步答案。不过,为了充分优化您的查询,请在我的回答中提供要求的项目。
-
别忘了手册! MySQL 有一个特定页面处理 ORDER BY 优化:dev.mysql.com/doc/refman/5.0/en/order-by-optimization.html
-
@John:检查您的综合索引。它应该按这个顺序在
(status, level, warehouse, updated)上创建(这很重要)。似乎它现在以错误的方式创建(首先是level,然后是status),这似乎就是我的查询缓慢的原因。发布查询结构时,只需运行SHOW CREATE TABLE parts并发布其输出:它将输出易于复制和粘贴的CREATE TABLE语句。 -
@John:创建索引,不要依赖工具,我见过变量以错误顺序进入索引的情况。只需运行
CREATE INDEX ix_parts_order ON parts (status, level, warehouse, updated)
标签: sql mysql optimization sql-order-by