mysqlのサブクエリの概要
7219 ワード
mysqlのサブクエリの最適化はずっと友好的ではなく、業界から批判されていることが多く、私がsqlの最適化で最も多くの問題に遭遇した一つでもあります.mysqlはサブクエリを処理するとき、サブクエリを書き換えます.通常、私たちは内から外まで、つまりサブクエリの結果を先に完成し、サブクエリで外クエリのテーブルを駆動し、クエリを完成したいと思っています.しかし、逆に、サブクエリは先に実行されません.今日は、mysqlサブクエリの理解を深めるための実際のケースを紹介します.
ケース:ユーザーのフィードバックデータベースの応答が遅く、多くのビジネスの更新が詰まっています.データベースにログインして観察すると、長時間実行されたsqlが見つかります.
| 10437 | usr0321t9m9 | 10.242.232.50:51201 | oms | Execute | 1179 | Sending
Sqlは:select tradedto 0_.*from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; 2.他のテーブルの更新がブロックされている:update a 1 set tradesign='DAB 67634-795 C-4 EAC-B 4 A 0-78 F 0 D 531 D 62 F',markColor='#CD 5555',memotime='2012-09-22',markPerson='?'where tradeoid in ('gy2012092204495100032') ; できるだけ早くアプリケーションを復元するために、長い間実行していたsql killを落とした後、アプリケーションは正常に戻ります.3.分析実行計画:db@3306 :explain select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; +----+--------------------+------------+------+---------------+------+---------+------+-------+----- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+------------+------+---------------+------+---------+------+-------+----- | 1 | PRIMARY | tradedto0_ | ALL | NULL | NULL | NULL | NULL | 27454 | Using where; Using filesort | | 2 | DEPENDENT SUBQUERY | orderdto1_ | ALL|NULL|NULL|NULL|NULL|40998|Using where|+----+----+----+----+----+----+----+----+----+----+----+----実行計画から一歩一歩最適化を始めます.まず、実行計画の2行目、つまりサブクエリの部分を見てみましょう.orderdto 1_全テーブルのスキャンを行い、適切なインデックスを追加できるかどうかを確認します.A.上書きインデックスを使用します.db@3306:alter table a2 add index ind_a2(proname,procode,tradeoid); ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes追加コンビネーションインデックスは最大key length制限を超えています:B.このテーブルのフィールド定義を表示します:
C.表フィールドの平均長を表示する:
D.フィールド長の縮小
さらに実行計画分析を行います.db@3306 :explain select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; +----+--------------------+------------+-------+-----------------+----------------------+---------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+------------+-------+-----------------+----------------------+---------+ | 1 | PRIMARY | tradedto0_ | ref | ind_tradestatus | ind_tradestatus | 345 | const,const,const,const | 8962 | Using where; Using filesort | | 2 | DEPENDENT SUBQUERY | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index|+----+----+----+----+----+----+----+----+----+----性能が向上していないことを発見しました.肝心なのは2つのテーブルのスキャンの行数が減少していません(8962*41005)、上に追加したインデックスはあまり効果がありません.今、tテーブルの実行結果を見てみましょう.db@3306 :select orderdto1_.tradeoid from t orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%'; Empty set(0.05 sec)の結果セットは空なので、tテーブルの結果セットを駆動テーブルとする必要がある.4.上記のテストで検証すると、通常のmysqlサブクエリの書き方は性能的に劣り、mysqlのサブクエリの天然の弱点であり、sqlを関連書き方に書き換える必要がある:select tradedto 0_.*from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; 5.実行計画の表示:db@3306 :explain select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; +----+-------------+------------+-------+---------------+----------------------+---------+------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+-------+---------------+----------------------+---------+------+ | 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Impossible WHERE noticed after reading const tables | | 2 | DERIVED | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index | +----+-------------+------------+-------+---------------+----------------------+---------+------+ 6.実行時間:db@3306 :select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; Empty set(0.03 sec)はミリ秒に短縮された.
ケース:ユーザーのフィードバックデータベースの応答が遅く、多くのビジネスの更新が詰まっています.データベースにログインして観察すると、長時間実行されたsqlが見つかります.
| 10437 | usr0321t9m9 | 10.242.232.50:51201 | oms | Execute | 1179 | Sending
Sqlは:select tradedto 0_.*from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; 2.他のテーブルの更新がブロックされている:update a 1 set tradesign='DAB 67634-795 C-4 EAC-B 4 A 0-78 F 0 D 531 D 62 F',markColor='#CD 5555',memotime='2012-09-22',markPerson='?'where tradeoid in ('gy2012092204495100032') ; できるだけ早くアプリケーションを復元するために、長い間実行していたsql killを落とした後、アプリケーションは正常に戻ります.3.分析実行計画:db@3306 :explain select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; +----+--------------------+------------+------+---------------+------+---------+------+-------+----- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+------------+------+---------------+------+---------+------+-------+----- | 1 | PRIMARY | tradedto0_ | ALL | NULL | NULL | NULL | NULL | 27454 | Using where; Using filesort | | 2 | DEPENDENT SUBQUERY | orderdto1_ | ALL|NULL|NULL|NULL|NULL|40998|Using where|+----+----+----+----+----+----+----+----+----+----+----+----実行計画から一歩一歩最適化を始めます.まず、実行計画の2行目、つまりサブクエリの部分を見てみましょう.orderdto 1_全テーブルのスキャンを行い、適切なインデックスを追加できるかどうかを確認します.A.上書きインデックスを使用します.db@3306:alter table a2 add index ind_a2(proname,procode,tradeoid); ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes追加コンビネーションインデックスは最大key length制限を超えています:B.このテーブルのフィールド定義を表示します:
db@3306 ：desc a2 ;
+---------------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------------+---------------+------+-----+---------+-------+
| OID | varchar(50) | NO | PRI | NULL | |
| TRADEOID | varchar(50) | YES | | NULL | |
| PROCODE | varchar(50) | YES | | NULL | |
| PRONAME | varchar(1000) | YES | | NULL | |
| SPCTNCODE | varchar(200) | YES | | NULL | |C.表フィールドの平均長を表示する:
db@3306 ：select max(length(PRONAME)),avg(length(PRONAME)) from a2;
+----------------------+----------------------+
| max(length(PRONAME)) | avg(length(PRONAME)) |
+----------------------+----------------------+
| 95 | 24.5588 |D.フィールド長の縮小
alter table modify column PRONAME varchar(156);さらに実行計画分析を行います.db@3306 :explain select tradedto0_.* from a1 tradedto0_ where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid in (select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; +----+--------------------+------------+-------+-----------------+----------------------+---------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+------------+-------+-----------------+----------------------+---------+ | 1 | PRIMARY | tradedto0_ | ref | ind_tradestatus | ind_tradestatus | 345 | const,const,const,const | 8962 | Using where; Using filesort | | 2 | DEPENDENT SUBQUERY | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index|+----+----+----+----+----+----+----+----+----+----性能が向上していないことを発見しました.肝心なのは2つのテーブルのスキャンの行数が減少していません(8962*41005)、上に追加したインデックスはあまり効果がありません.今、tテーブルの実行結果を見てみましょう.db@3306 :select orderdto1_.tradeoid from t orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%'; Empty set(0.05 sec)の結果セットは空なので、tテーブルの結果セットを駆動テーブルとする必要がある.4.上記のテストで検証すると、通常のmysqlサブクエリの書き方は性能的に劣り、mysqlのサブクエリの天然の弱点であり、sqlを関連書き方に書き換える必要がある:select tradedto 0_.*from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; 5.実行計画の表示:db@3306 :explain select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; +----+-------------+------------+-------+---------------+----------------------+---------+------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+-------+---------------+----------------------+---------+------+ | 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Impossible WHERE noticed after reading const tables | | 2 | DERIVED | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index | +----+-------------+------------+-------+---------------+----------------------+---------+------+ 6.実行時間:db@3306 :select tradedto0_.* from a1 tradedto0_ ,(select orderdto1_.tradeoid from a2 orderdto1_ where orderdto1_.proname like '%??%' or orderdto1_.procode like '%??%')t2 where tradedto0_.tradestatus='1' and (tradedto0_.tradeoid=t2.tradeoid ) and tradedto0_.undefine4='1' and tradedto0_.invoicetype='1' and tradedto0_.tradestep='0' and (tradedto0_.orderCompany like '0002%') order by tradedto0_.tradesign ASC, tradedto0_.makertime desc limit 15; Empty set(0.03 sec)はミリ秒に短縮された.