Question

我有两张桌子：

第一：

CREATE TABLE `dialog_projects` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`creator_user_id` INT(11) UNSIGNED NOT NULL,
`add_users_allowed` INT(1) NULL DEFAULT '1',
`dlg_name` VARCHAR(200) NOT NULL,
`dlg_date` DATETIME NOT NULL,
PRIMARY KEY (`id`),
INDEX `dialog_projects_creator_user_id_ind` (`creator_user_id`),
INDEX `dialog_projects_add_users_allowed_ind` (`add_users_allowed`),
INDEX `dialog_projects_dlg_date_ind` (`dlg_date`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=220094
/*!50100 PARTITION BY KEY (id)
PARTITIONS 10  */;

第二：

CREATE TABLE `dialog_users` (
`dialog_projects_id` INT(11) UNSIGNED NOT NULL,
`user_id` INT(11) UNSIGNED NOT NULL,
`num_new_msgs` INT(11) UNSIGNED NOT NULL,
`accepted` TINYINT(1) NULL DEFAULT '0',
`last_visit` DATETIME NOT NULL,
PRIMARY KEY (`dialog_projects_id`, `user_id`, `num_new_msgs`),
INDEX `dialog_projects_accepted_ind` (`accepted`),
INDEX `dialog_projects_last_visit_ind` (`last_visit`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
/*!50100 PARTITION BY HASH (dialog_projects_id + user_id + num_new_msgs)
PARTITIONS 10  */;

此查询执行约5.5秒，但没有＆＃34;由du.num_new_msgs desc＆＃34; - 需要0,005秒。如何提高速度？怎么了？

#explain 
select SQL_NO_CACHE dp.id
from `dialog_users` as du 
left join `dialog_projects` as dp
 on (du.dialog_projects_id = dp.id) 
where dp.id > 300 and du.num_new_msgs > -1 
    and dp.add_users_allowed = 0 and du.user_id = 10990 

order by du.num_new_msgs desc, dp.id desc 
limit 10

以下解释：

"id"    "select_type"   "table" "type"  "possible_keys" "key"   "key_len"   "ref"   "rows"  "Extra"
"1" "SIMPLE"    "dp"    "ref"   "PRIMARY,dialog_projects_add_users_allowed_ind" "dialog_projects_add_users_allowed_ind" "5" "const" "100246"    "Using where; Using index; Using temporary; Using filesort"
"1" "SIMPLE"    "du"    "ref"   "PRIMARY"   "PRIMARY"   "8" "sport-event.dp.id,const"   "1" "Using where; Using index"

由于

Answer 1

为什么在LIMIT子句之前放置ORDER BY子句会降低性能？因为没有ORDER BY，MySQL查询引擎只需返回十个方便的行，然后就可以停止了。对于where dp.id > 300 and dp.add_users_allowed = 0 and du.num_new_msgs > -1 and du.user_id = 10990，它需要检查结果集中的每一行以找到所需的行。

您的查询说明了这一点。为了清楚起见，我已经重新安排了这些条款。

dialog_projects

您可以尝试在(add_users_allowed, id)列的{{1}}上添加复合索引。这可能有助于加速该表的查找。

您似乎正在为相对较小的表（300K行）使用分区。这可能会破坏您的查询性能。大多数MySQL用户甚至不会考虑将他们的表分区，直到他们的行数至少是你的表的一百倍。然后他们非常仔细地计划他们的查询，因此大多数查询都会触及有限数量的分区;希望只有一个。

索引有问题

1 个答案: