我有一個下面的查詢，我不知道如何解釋它的計劃。所以我擁有的是臨時表創建查詢和表結構。
create temporary table if not exists tmp_staging_task_ids as
select distinct s.usr_task_id
from ue_events_staging s
where s.queue_id is null
limit 6500;
以上選擇查詢解釋計劃；
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: s
partitions: NULL
type: ref
possible_keys: ue_events_staging_queue_id,usr_task_id,queue_id_usr_task_id,queue_id_app_id
key: queue_id_usr_task_id
key_len: 303
ref: const
rows: 17774428
filtered: 100.00
Extra: Using where; Using index; Using temporary
詢問;
update ue_events_staging s
join tmp_staging_task_ids t on t.usr_task_id = s.usr_task_id
set s.queue_id = 'queue_id';
表結構；
Create Table: CREATE TABLE `ue_events_staging` (
`id` bigint NOT NULL AUTO_INCREMENT,
`queue_id` varchar(100) DEFAULT NULL,
`usr_task_id` bigint NOT NULL,
`app_id` bigint NOT NULL,
`platform` tinyint NOT NULL,
`capture_time` bigint NOT NULL,
`input_type` varchar(50) NOT NULL,
`type` varchar(100) NOT NULL,
`event_type` varchar(10) NOT NULL,
`screen` varchar(100) NOT NULL,
`object_name` varchar(255) DEFAULT NULL,
`app_custom_tag` varchar(255) DEFAULT NULL,
`exception_class_name` varchar(250) DEFAULT NULL,
`exception_tag` varchar(250) DEFAULT NULL,
`non_responsive` tinyint(1) DEFAULT '0',
`is_first` tinyint(1) DEFAULT '0',
`is_second` tinyint(1) DEFAULT '0',
`is_last` tinyint(1) DEFAULT '0',
`is_quit` tinyint(1) DEFAULT '0',
`x_coordinate` double DEFAULT NULL,
`y_coordinate` double DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `ue_events_staging_queue_id` (`queue_id`),
KEY `usr_task_id` (`usr_task_id`),
KEY `screen` (`app_id`,`platform`,`screen`),
KEY `app_id_queue_id` (`app_id`,`queue_id`),
KEY `queue_id_usr_task_id` (`queue_id`,`usr_task_id`),
KEY `queue_id_app_id` (`queue_id`,`app_id`)
請檢查大約需要 3.5K 秒并導致負載的可能性。
uj5u.com熱心網友回復：
這看起來像您正在以 6500 行為單位進行更新。
如果您不需要該臨時表，則可以將更新查詢重構為獨立。您不需要臨時表，因為您可以將其WHERE queue_id IS NULL直接放入 UPDATE 的 WHERE 中。
UPDATE ue_events_staging
SET queue_id = 'queue_id'
WHERE queue_id IS NULL
LIMIT 6500;
您的臨時表創建步驟從您的表中提取 6500 個不同的（任意選擇的）usr_task_id值。其中一些值可能與表中的多行相關，因此您的 UPDATE 陳述句可能會更新表中的 6500 多行。
我建議的重構將更新表中任意選擇的 6500 行。在陳述句結束時，某些具有特定usr_task_id值的行可能會被更新，而其他行可能不會。如果這對您的業務規則是可以接受的，那么它會更快。
如果您的業務規則要求一次更新具有每個特定usr_task_id值的所有行，您可以嘗試這樣做來簡化這兩個陳述句。
create temporary table if not exists tmp_staging_task_ids as
select s.usr_task_id
from ue_events_staging s
where s.queue_id is null
limit 6500;
update ue_events_staging
set queue_id = 'queue_id'
where usr_task_id IN
(select usr_task_id from tmp_staging_task_ids);
這在創建臨時表時擺脫了 DISTINCT 運算子，并且可以節省一點時間。IN 子句暗示 DISTINCT 值。
“任意選擇”？沒有 ORDER BY 和 LIMIT 子句的陳述句指示 MySQL 任意選擇行。MySQL 選擇檢索速度最快的行（希望如此）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/510536.html