我正在嘗試使用“物化視圖”來優化連接來提高查詢的性能。下面的第一個查詢是使用連接的原始查詢。第二個是針對我生成的表撰寫的查詢，其中包含所有連接的資料（相當于物化視圖）。它們都回傳相同的結果集。不幸的是，不知何故，在處理一組很長的輸入 id（IN 子句）時，第二個查詢要慢得多。我不明白這怎么可能！！！！執行所有連接必須有相當數量的過熱，這可以通過“物化視圖”來節省，對嗎？
SELECT
clinical_sample.INTERNAL_ID AS "internalId",
sample.STABLE_ID AS "sampleId",
patient.STABLE_ID AS "patientId",
clinical_sample.ATTR_ID AS "attrId",
cancer_study.CANCER_STUDY_IDENTIFIER AS "studyId",
clinical_sample.ATTR_VALUE AS "attrValue"
FROM clinical_sample
INNER JOIN sample ON clinical_sample.INTERNAL_ID = sample.INTERNAL_ID
INNER JOIN patient ON sample.PATIENT_ID = patient.INTERNAL_ID
INNER JOIN cancer_study ON patient.CANCER_STUDY_ID =
cancer_study.CANCER_STUDY_ID
WHERE cancer_study.CANCER_STUDY_IDENTIFIER = 'xxxxx'
AND sample.STABLE_ID IN
('P-0068343-T02-IM7' , 'P-0068353-T01-IM7' ,
'P-0068363-T01-IM7' , 'P-0068364-T01-IM7' )
AND clinical_sample.ATTR_ID IN
(
'CANCER_TYPE'
);
SELECT
internalId,
sampleId,
patientId,
attrId,
studyId,
attrValue
FROM test
WHERE
sampleId IN ('P-0068343-T02-IM7' , 'P-0068353-T01-IM7' ,
'P-0068363-T01-IM7' , 'P-0068364-T01-IM7' )
AND studyId = 'xxxxx'
AND attrId = 'CANCER_TYPE';
更新：我確實在 Workbench 報告中注意到，帶有連接的查詢似乎掃描的行要少得多。對于第二個無連接查詢，大約 829k 與 ~2400k。所以加入似乎實際上是一個主要的優化。我在 sampleId、studyId、attrId 和這三者的復合中有索引。
表“test”和“clinical_sample”都具有相同的行數。
uj5u.com熱心網友回復：
這將有助于查看PRIMARY KEY每個表的內容。
其中一些索引可能會有所幫助：
clinical_sample: INDEX(ATTR_ID, INTERNAL_ID, ATTR_VALUE)
sample: INDEX(STABLE_ID, INTERNAL_ID, PATIENT_ID)
patient: INDEX(INTERNAL_ID, STABLE_ID, CANCER_STUDY_ID)
cancer_study: INDEX(CANCER_STUDY_IDENTIFIER, CANCER_STUDY_ID)
我同意 Barmar 的INDEX(studyId, attrId, sampleId)物化視圖。
我在 sampleId、studyId、attrId 和這三者的復合中有索引。
讓我們看看EXPLAIN。它可能表明它(sampleId)在應該使用復合索引的時候使用了您的索引。
也將IN列放在最后，而不是第一，無論基數如何。更確切地說，把=列第一的綜合指數。
uj5u.com熱心網友回復：
深思熟慮：資料庫連接何時以及為何成本高昂？ 這讓我相信帶有索引的規范化表實際上可能比我的非規范化嘗試（物化視圖）更快。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/342404.html
下一篇：與Web開發中的用戶資料相關