大きなテーブルでLEFT JOINを使用して非常に遅いSELECTを最適化する方法

私は何時間もグーグルで独学で解決策を探していましたが、運がありませんでした。ここではいくつかの同様の質問を見つけましたが、この場合は見つかりませんでした。

私のテーブル：

• 人（〜1000万行）
• 属性（場所、年齢、...）
• 人と属性の間のリンク（M：M）（〜40M行）

フルダンプ〜280MB

状況：person_idいくつかの場所（location.attribute_value BETWEEN 3000 AND 7000）、性別（gender.attribute_value = 1）、生まれた年（bornyear.attribute_value BETWEEN 1980 AND 2000）、目の色（eyecolor.attribute_value IN (2,3)）から すべての個人ID（）を選択しようとしています。

これは私の魔女が3〜4 分かかったクエリです。最適化したい：

SELECT person_id
FROM person
    LEFT JOIN attribute location ON location.attribute_type_id = 1 AND location.person_id = person.person_id
    LEFT JOIN attribute gender ON gender.attribute_type_id = 2 AND gender.person_id = person.person_id
    LEFT JOIN attribute bornyear ON bornyear.attribute_type_id = 3 AND bornyear.person_id = person.person_id
    LEFT JOIN attribute eyecolor ON eyecolor.attribute_type_id = 4 AND eyecolor.person_id = person.person_id
WHERE 1
    AND location.attribute_value BETWEEN 3000 AND 7000
    AND gender.attribute_value = 1
    AND bornyear.attribute_value BETWEEN 1980 AND 2000
    AND eyecolor.attribute_value IN (2,3)
LIMIT 100000;

結果：

+-----------+
| person_id |
+-----------+
|       233 |
|       605 |
|       ... |
|   8702599 |
|   8703617 |
+-----------+
100000 rows in set (3 min 42.77 sec)

拡張機能の説明：

+----+-------------+----------+--------+---------------------------------------------+-----------------+---------+--------------------------+---------+----------+--------------------------+
| id | select_type | table    | type   | possible_keys                               | key             | key_len | ref                      | rows    | filtered | Extra                    |
+----+-------------+----------+--------+---------------------------------------------+-----------------+---------+--------------------------+---------+----------+--------------------------+
|  1 | SIMPLE      | bornyear | range  | attribute_type_id,attribute_value,person_id | attribute_value | 5       | NULL                     | 1265229 |   100.00 | Using where              |
|  1 | SIMPLE      | location | ref    | attribute_type_id,attribute_value,person_id | person_id       | 5       | test1.bornyear.person_id |       4 |   100.00 | Using where              |
|  1 | SIMPLE      | eyecolor | ref    | attribute_type_id,attribute_value,person_id | person_id       | 5       | test1.bornyear.person_id |       4 |   100.00 | Using where              |
|  1 | SIMPLE      | gender   | ref    | attribute_type_id,attribute_value,person_id | person_id       | 5       | test1.eyecolor.person_id |       4 |   100.00 | Using where              |
|  1 | SIMPLE      | person   | eq_ref | PRIMARY                                     | PRIMARY         | 4       | test1.location.person_id |       1 |   100.00 | Using where; Using index |
+----+-------------+----------+--------+---------------------------------------------+-----------------+---------+--------------------------+---------+----------+--------------------------+
5 rows in set, 1 warning (0.02 sec)

プロファイリング：

+------------------------------+-----------+
| Status                       | Duration  |
+------------------------------+-----------+
| Sending data                 |  3.069452 |
| Waiting for query cache lock |  0.000017 |
| Sending data                 |  2.968915 |
| Waiting for query cache lock |  0.000019 |
| Sending data                 |  3.042468 |
| Waiting for query cache lock |  0.000043 |
| Sending data                 |  3.264984 |
| Waiting for query cache lock |  0.000017 |
| Sending data                 |  2.823919 |
| Waiting for query cache lock |  0.000038 |
| Sending data                 |  2.863903 |
| Waiting for query cache lock |  0.000014 |
| Sending data                 |  2.971079 |
| Waiting for query cache lock |  0.000020 |
| Sending data                 |  3.053197 |
| Waiting for query cache lock |  0.000087 |
| Sending data                 |  3.099053 |
| Waiting for query cache lock |  0.000035 |
| Sending data                 |  3.064186 |
| Waiting for query cache lock |  0.000017 |
| Sending data                 |  2.939404 |
| Waiting for query cache lock |  0.000018 |
| Sending data                 |  3.440288 |
| Waiting for query cache lock |  0.000086 |
| Sending data                 |  3.115798 |
| Waiting for query cache lock |  0.000068 |
| Sending data                 |  3.075427 |
| Waiting for query cache lock |  0.000072 |
| Sending data                 |  3.658319 |
| Waiting for query cache lock |  0.000061 |
| Sending data                 |  3.335427 |
| Waiting for query cache lock |  0.000049 |
| Sending data                 |  3.319430 |
| Waiting for query cache lock |  0.000061 |
| Sending data                 |  3.496563 |
| Waiting for query cache lock |  0.000029 |
| Sending data                 |  3.017041 |
| Waiting for query cache lock |  0.000032 |
| Sending data                 |  3.132841 |
| Waiting for query cache lock |  0.000050 |
| Sending data                 |  2.901310 |
| Waiting for query cache lock |  0.000016 |
| Sending data                 |  3.107269 |
| Waiting for query cache lock |  0.000062 |
| Sending data                 |  2.937373 |
| Waiting for query cache lock |  0.000016 |
| Sending data                 |  3.097082 |
| Waiting for query cache lock |  0.000261 |
| Sending data                 |  3.026108 |
| Waiting for query cache lock |  0.000026 |
| Sending data                 |  3.089760 |
| Waiting for query cache lock |  0.000041 |
| Sending data                 |  3.012763 |
| Waiting for query cache lock |  0.000021 |
| Sending data                 |  3.069694 |
| Waiting for query cache lock |  0.000046 |
| Sending data                 |  3.591908 |
| Waiting for query cache lock |  0.000060 |
| Sending data                 |  3.526693 |
| Waiting for query cache lock |  0.000076 |
| Sending data                 |  3.772659 |
| Waiting for query cache lock |  0.000069 |
| Sending data                 |  3.346089 |
| Waiting for query cache lock |  0.000245 |
| Sending data                 |  3.300460 |
| Waiting for query cache lock |  0.000019 |
| Sending data                 |  3.135361 |
| Waiting for query cache lock |  0.000021 |
| Sending data                 |  2.909447 |
| Waiting for query cache lock |  0.000039 |
| Sending data                 |  3.337561 |
| Waiting for query cache lock |  0.000140 |
| Sending data                 |  3.138180 |
| Waiting for query cache lock |  0.000090 |
| Sending data                 |  3.060687 |
| Waiting for query cache lock |  0.000085 |
| Sending data                 |  2.938677 |
| Waiting for query cache lock |  0.000041 |
| Sending data                 |  2.977974 |
| Waiting for query cache lock |  0.000872 |
| Sending data                 |  2.918640 |
| Waiting for query cache lock |  0.000036 |
| Sending data                 |  2.975842 |
| Waiting for query cache lock |  0.000051 |
| Sending data                 |  2.918988 |
| Waiting for query cache lock |  0.000021 |
| Sending data                 |  2.943810 |
| Waiting for query cache lock |  0.000061 |
| Sending data                 |  3.330211 |
| Waiting for query cache lock |  0.000025 |
| Sending data                 |  3.411236 |
| Waiting for query cache lock |  0.000023 |
| Sending data                 | 23.339035 |
| end                          |  0.000807 |
| query end                    |  0.000023 |
| closing tables               |  0.000325 |
| freeing items                |  0.001217 |
| logging slow query           |  0.000007 |
| logging slow query           |  0.000011 |
| cleaning up                  |  0.000104 |
+------------------------------+-----------+
100 rows in set (0.00 sec)

テーブル構造：

CREATE TABLE `attribute` (
  `attribute_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `attribute_type_id` int(11) unsigned DEFAULT NULL,
  `attribute_value` int(6) DEFAULT NULL,
  `person_id` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`attribute_id`),
  KEY `attribute_type_id` (`attribute_type_id`),
  KEY `attribute_value` (`attribute_value`),
  KEY `person_id` (`person_id`)
) ENGINE=MyISAM AUTO_INCREMENT=40000001 DEFAULT CHARSET=utf8;

CREATE TABLE `person` (
  `person_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `person_name` text CHARACTER SET latin1,
  PRIMARY KEY (`person_id`)
) ENGINE=MyISAM AUTO_INCREMENT=20000001 DEFAULT CHARSET=utf8;

SSDと1GB RAMを搭載したDigitalOcean仮想サーバーでクエリが実行されていました。

データベースの設計に問題があるかもしれません。この状況をより良く設計するための提案はありますか？または、上記の選択を調整するだけですか？

に含める属性をいくつか選択しますperson。いくつかの組み合わせでインデックスを作成します。単一列インデックスではなく、複合インデックスを使用します。

それは本質的に、あなたがいるところにあるEAV-suck-at-performanceから抜け出す唯一の方法です。

詳細は次のとおりです。http： //mysql.rjweb.org/doc.php/eavには、キー値テーブルの代わりにJSONを使用する提案が含まれています。

にインデックスを追加attribute：

• (person_id, attribute_type_id, attribute_value) そして
• (attribute_type_id, attribute_value, person_id)

説明

現在の設計でEXPLAINは、クエリがで1,265,229 * 4 * 4 * 4 = 80,974,656行を調べることを想定していますattribute。あなたは追加することで、この数を減らすことができ、複合インデックスを上attributeのため(person_id, attribute_type_id)。このインデックスを使用すると、クエリはlocation、eyecolorおよびのそれぞれについて4行ではなく1行のみを検査しますgender。

そのインデックスを拡張して、次のattribute_type_valueものも含めることができます(person_id, attribute_type_id, attribute_value)。これにより、このインデックスがこのクエリのカバーリングインデックスに変わり、パフォーマンスも向上するはずです。

さらに、にインデックスを追加すること(attribute_type_id, attribute_value, person_id)により（を含むことによりカバーするインデックスperson_id）attribute_value、より多くの行を調べる必要がある場所にインデックスを使用するよりもパフォーマンスが向上するはずです。この場合、Explainの最初のステップ、つまりからの範囲の選択が固定されますbornyear。

これらの2つのインデックスを使用すると、システムでのクエリの実行時間が約2.0秒から約0.2秒に短縮され、Explain出力は次のようになります。

+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+
| id | select_type | table    | type   | possible_keys                       | key               | key_len | ref                            |    rows | filtered | Extra                    |
+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+
|  1 | SIMPLE      | bornyear | range  | person_type_value,type_value_person | type_value_person |       9 |                                | 1861881 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | location | ref    | person_type_value,type_value_person | person_type_value |       8 | bornyear.person_id,const       |       1 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | eyecolor | ref    | person_type_value,type_value_person | person_type_value |       8 | bornyear.person_id,const       |       1 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | gender   | ref    | person_type_value,type_value_person | person_type_value |      13 | bornyear.person_id,const,const |       1 |   100.00 | Using index              |
|  1 | SIMPLE      | person   | eq_ref | PRIMARY                             | PRIMARY           |       4 | bornyear.person_id             |       1 |   100.00 | Using index              |
+----+-------------+----------+--------+-------------------------------------+-------------------+---------+--------------------------------+---------+----------+--------------------------+

データベースの設計に問題があるかもしれません。

いわゆるEntity-Attribute-Value設計を使用しています。これは、設計上、パフォーマンスが低い場合がよくあります。

この状況をより良く設計するための提案はありますか？

これを設計するための古典的なリレーショナルな方法は、属性ごとに個別のテーブルを作成することです。一般的に、あなたはこれらの別々のテーブルを持つことができますlocation、gender、bornyear、eyecolor。

以下は、特定の属性が常に個人に対して定義されているかどうかによって異なります。また、人が属性の値を1つだけ持つことができるかどうか。たとえば、通常、人の性別は1つだけです。現在のデザインでは、性別の値が異なる同じ人物の3つの行を追加することを妨げるものはありません。性別の値を1または2ではなく、987などの意味をなさない数値に設定することもできます。データベースにはそれを妨げる制約はありません。ただし、これはEAV設計でデータの整合性を維持する別の別の問題です。

あなたは、常に人の性別を知っていれば、それは別のテーブルにそれを置くために意味をなさない、それがnull以外の列持つことは良い方法であるGenderID内personのリストを参照テーブルへの外部キーになるテーブルを、すべての可能な性別とその名前。常にではありませんが、ほとんどの場合にその人の性別を知っている場合は、この列をヌル可能にしてNULL、情報が利用できないときに設定できます。ほとんどの場合、その人の性別がわからない場合は、1：1にgenderリンクしperson、性別がわかっている人だけの行を持つ別のテーブルを用意する方がよい場合があります。

同様の考察が適用にeyecolorしてbornyear-人がために2つの値を持っていることはほとんどありませんeyecolorかbornyear。

人が1つの属性に対して複数の値を持つことができる場合は、必ず別のテーブルに入れてください。たとえば、人が複数の住所（自宅、勤務先、郵便、休日など）を持っていることは珍しいことではないため、それらをすべて表にリストしますlocation。テーブルpersonとlocationリンクされます1：M。

または、上記の選択を調整するだけですか？

EAV設計を使用する場合、少なくとも次のことを行います。

• セットの列attribute_type_id、attribute_value、person_idへNOT NULL。
• そのリンク外部キーの設定attribute.person_idとをperson.person_id。
• 3列に1つのインデックスを作成します(attribute_type_id, attribute_value, person_id)。ここでは列の順序が重要です。
• 私の知る限り、MyISAMは外部キーを尊重しないため、使用しないでください。代わりにInnoDBを使用してください。

このようなクエリを作成します。結合のINNER代わりに使用しLEFT、各属性に対して明示的にサブクエリを記述して、オプティマイザーにインデックスを使用するすべての機会を与えます。

SELECT person.person_id
FROM
    person
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 1
            AND location.attribute_value BETWEEN 3000 AND 7000
    ) AS location ON location.person_id = person.person_id
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 2
            AND location.attribute_value = 1
    ) AS gender ON gender.person_id = person.person_id
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 3
            AND location.attribute_value BETWEEN 1980 AND 2000
    ) AS bornyear ON bornyear.person_id = person.person_id
    INNER JOIN
    (
        SELECT attribute.person_id
        FROM attribute
        WHERE attribute_type_id = 4
            AND location.attribute_value IN (2, 3)
    ) AS eyecolor ON eyecolor.person_id = person.person_id
LIMIT 100000;

また、テーブルをパーティション分割する価値があるかもしれません。attributeattribute_type_id

私は十分な解決策を見つけたと思います。この記事に触発されています。

短い答え：

1. すべての属性を持つ1つのテーブルを作成しました。1つの属性に対して1つの列。プラス主キー列。
2. 属性値は、テキストセル（全文検索用）にCSV形式の形式で保存されます。
3. フルテキストインデックスを作成しました。その前にft_min_word_len=1、[mysqld]セクションでinnodb_ft_min_token_size=1（MyISAMの場合）およびmy.cnfファイルで（InnoDbの場合）設定することが重要です。mysql サービスを再起動します。
4. 検索例：SELECT * FROM person_index WHERE MATCH(attribute_1) AGAINST("123 456 789" IN BOOLEAN MODE) LIMIT 1000ここで123、456a 789は、人が関連付けるべきID attribute_1です。このクエリは1秒未満で完了しました。

詳細な回答：

手順1. フルテキストインデックスを使用してテーブルを作成します。InnoDbはMySQL 5.7のフルテキストインデックスをサポートしているため、5.5または5.6を使用する場合はMyISAMを使用する必要があります。InnoDbよりもFT検索の方が高速な場合があります。

CREATE TABLE `person_attribute_ft` (
  `person_id` int(11) NOT NULL,
  `attr_1` text,
  `attr_2` text,
  `attr_3` text,
  `attr_4` text,
  PRIMARY KEY (`person_id`),
  FULLTEXT KEY `attr_1` (`attr_1`),
  FULLTEXT KEY `attr_2` (`attr_2`),
  FULLTEXT KEY `attr_3` (`attr_3`),
  FULLTEXT KEY `attr_4` (`attr_4`),
  FULLTEXT KEY `attr_12` (`attr_1`,`attr_2`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

手順2. EAV（エンティティ属性値）テーブルからデータを挿入します。たとえば、質問で述べたように、1つの単純なSQLで実行できます。

INSERT IGNORE INTO `person_attribute_ft`
SELECT
    p.person_id,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 1 AND a.person_id = p.person_id LIMIT 10) attr_1,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 2 AND a.person_id = p.person_id LIMIT 10) attr_2,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 3 AND a.person_id = p.person_id LIMIT 10) attr_3,
    (SELECT GROUP_CONCAT(a.attribute_value SEPARATOR ' ') FROM attribute a WHERE a.attribute_type_id = 4 AND a.person_id = p.person_id LIMIT 10) attr_4
FROM person p

結果は次のようになります。

mysql> select * from person_attribute_ft limit 10;
+-----------+--------+--------+--------+--------+
| person_id | attr_1 | attr_2 | attr_3 | attr_4 |
+-----------+--------+--------+--------+--------+
|         1 | 541    | 2      | 1927   | 3      |
|         2 | 2862   | 2      | 1939   | 4      |
|         3 | 6573   | 2      | 1904   | 2      |
|         4 | 2432   | 1      | 2005   | 2      |
|         5 | 2208   | 1      | 1995   | 4      |
|         6 | 8388   | 2      | 1973   | 1      |
|         7 | 107    | 2      | 1909   | 4      |
|         8 | 5161   | 1      | 2005   | 1      |
|         9 | 8022   | 2      | 1953   | 4      |
|        10 | 4801   | 2      | 1900   | 3      |
+-----------+--------+--------+--------+--------+
10 rows in set (0.00 sec)

ステップ3.次のようなクエリを含むテーブルから選択します。

mysql> SELECT SQL_NO_CACHE *
    -> FROM `person_attribute_ft`
    -> WHERE 1 AND MATCH(attr_1) AGAINST ("3000 3001 3002 3003 3004 3005 3006 3007" IN BOOLEAN MODE)
    -> AND MATCH(attr_2) AGAINST ("1" IN BOOLEAN MODE)
    -> AND MATCH(attr_3) AGAINST ("1980 1981 1982 1983 1984" IN BOOLEAN MODE)
    -> AND MATCH(attr_4) AGAINST ("2,3" IN BOOLEAN MODE)
    -> LIMIT 10000;
+-----------+--------+--------+--------+--------+
| person_id | attr_1 | attr_2 | attr_3 | attr_4 |
+-----------+--------+--------+--------+--------+
|     12131 | 3002   | 1      | 1982   | 2      |
|     51315 | 3007   | 1      | 1984   | 2      |
|    147283 | 3001   | 1      | 1984   | 2      |
|    350086 | 3005   | 1      | 1982   | 3      |
|    423907 | 3004   | 1      | 1982   | 3      |
... many rows ...
|   9423907 | 3004   | 1      | 1982   | 3      |
|   9461892 | 3007   | 1      | 1982   | 2      |
|   9516361 | 3006   | 1      | 1980   | 2      |
|   9813933 | 3005   | 1      | 1982   | 2      |
|   9986892 | 3003   | 1      | 1981   | 2      |
+-----------+--------+--------+--------+--------+
90 rows in set (0.17 sec)

クエリはすべての行を選択します。

• 以下のIDの少なくとも1つに一致しattr_1ます。3000, 3001, 3002, 3003, 3004, 3005, 3006 or 3007
• 同時にマッチングに1内attr_2（この列表す性別をこの溶液を、カスタマイズされた場合、それがなければならないので、smallint(1)単純なインデックスと、等...）
• のと同じ時間マッチング少なくとも1つの1980, 1981, 1982, 1983 or 1984中にattr_3
• 同時にマッチングで、2または3中attr_4

結論：

このソリューションは完璧ではなく、多くの状況に理想的ではありませんが、EAVテーブル設計の優れた代替手段として使用できます。

私はそれが誰かを助けることを願っています。

適切に見えるクエリインデックスヒントを使用してみてください

Mysqlインデックスヒント