MYSQLパフォーマンス最適化-inサブクエリ

MYSQLパフォーマンス最適化-inサブクエリ

inの中のサブクエリ、有名な老大難調優問題

シーン

元の状況

以降の場合

解釈

inの中のサブクエリ、有名な老大難調優問題
この問題はあまりにも有名で、説明しないで、要するにいくつかの特定の情況の下で、mysqlは自分で最適化する問題があって、1つのinクエリーの効率、inの中のサブクエリー+結果より直接copyで外部クエリーを行うことができて、1つの数量級を下げることができます.
シーン
PostとTypeは多対多で,Type自体は3級ツリーであり,クエリの際には上位から下級まですべて調べるよう要求される.
もとの状況
SELECT pf.* FROM PostFull pf WHERE pf.id in ( SELECT distinct(p. id ) from PostFull p left join postTypeMap ptm on ptm. postId = p. id WHERE ptm. typeId in ( SELECT 17 UNION SELECT t. id FROM Type t WHERE t. upTypeID = 17 UNION SELECT t3. id FROM Type t3 LEFT JOIN Type t2 on t3. upTypeID = t2. id WHERE t2. upTypeID = 17 ) );
Execution PlanのQuery cost:5909.42
その後の状況
SELECT pf.* FROM PostFull pf WHERE pf.id in ( SELECT distinct(p. id ) from PostFull p left join postTypeMap ptm on ptm. postId = p. id WHERE ptm. typeId in ( SELECT * FROM ( SELECT 17 UNION SELECT t. id FROM Type t WHERE t. upTypeID = 17 UNION SELECT t3. id FROM Type t3 LEFT JOIN Type t2 on t3. upTypeID = t2. id WHERE t2. upTypeID = 17) allt ) );
Execution PlanのQuery cost:668.08
説明する
複数セットSELECTは余計な感じがしますが、MYSQLの理解を助けることができます.INの中の検索は外のPとは関係ありません.
1桁の効率の違いが出てきます.
リファレンスhttps://www.cnblogs.com/wxw16/p/6105624.html?utm_source=itdadao&utm_medium=referralああ、もっとはっきり説明します.