web-dev-qa-db-ja.com

MySQLは別のテーブルに対して結合するときにインデックスを使用しません

2つのテーブルがあります。最初のテーブルには、CMS内のすべての記事/ブログ投稿が含まれています。これらの記事の一部は雑誌にも掲載される場合があります。その場合、それらの記事は雑誌固有の情報を含む別のテーブルと外部キー関係を持っています。

以下は、これらの2つのテーブルの作成テーブル構文の簡略化されたバージョンで、重要でない行が一部削除されています。

_CREATE TABLE `base_article` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `date_published` datetime DEFAULT NULL,
  `title` varchar(255) NOT NULL,
  `description` text,
  `content` longtext,
  `is_published` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `base_article_date_published` (`date_published`),
  KEY `base_article_is_published` (`is_published`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `mag_article` (
    `basearticle_ptr_id` int(11) NOT NULL,
    `issue_slug` varchar(8) DEFAULT NULL,
    `rubric` varchar(75) DEFAULT NULL,
    PRIMARY KEY (`basearticle_ptr_id`),
    KEY `mag_article_issue_slug` (`issue_slug`),
    CONSTRAINT `basearticle_ptr_id_refs_id` FOREIGN KEY (`basearticle_ptr_id`) REFERENCES `base_article` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
_

CMSには合計で約250,000の記事が含まれており、この問題をローカルで再現したい場合に、テストデータベースにサンプルデータを入力するために使用できる簡単な Pythonスクリプト を作成しました。

これらのテーブルのいずれかから選択した場合、MySQLは適切なインデックスを選択したり、記事をすばやく取得したりしても問題ありません。ただし、2つのテーブルが次のような単純なクエリで結合されている場合：

_SELECT * FROM `base_article` 
INNER JOIN `mag_article` ON (`mag_article`.`basearticle_ptr_id` = `base_article`.`id`)
WHERE is_published = 1
ORDER BY `base_article`.`date_published` DESC
LIMIT 30
_

MySQLは適切なクエリの選択に失敗し、パフォーマンスは急激に低下します。拡張された関連する説明は次のとおりです（実行時間が1秒を超えています）：

_+----+-------------+--------------+--------+-----------------------------------+---------+---------+----------------------------------------+-------+----------+---------------------------------+
| id | select_type |    table     |  type  |           possible_keys           |   key   | key_len |                  ref                   | rows  | filtered |              Extra              |
+----+-------------+--------------+--------+-----------------------------------+---------+---------+----------------------------------------+-------+----------+---------------------------------+
|  1 | SIMPLE      | mag_article  | ALL    | PRIMARY                           | NULL    | NULL    | NULL                                   | 23830 | 100.00   | Using temporary; Using filesort |
|  1 | SIMPLE      | base_article | eq_ref | PRIMARY,base_article_is_published | PRIMARY | 4       | my_test.mag_article.basearticle_ptr_id |     1 | 100.00   | Using where                     |
+----+-------------+--------------+--------+-----------------------------------+---------+---------+----------------------------------------+-------+----------+---------------------------------+
_
  • 9月30日の編集：このクエリからWHERE句を削除できますが、EXPLAINは同じように見え、クエリはまだ低速です。

解決策の1つは、インデックスを強制することです。 FORCE INDEX (base_articel_date_published)を使用して同じクエリを実行すると、クエリは約1.6ミリ秒で実行されます。

_+----+-------------+--------------+--------+---------------+-----------------------------+---------+-------------------------+------+-----------+-------------+
| id | select_type |    table     |  type  | possible_keys |             key             | key_len |           ref           | rows | filtered  |    Extra    |
+----+-------------+--------------+--------+---------------+-----------------------------+---------+-------------------------+------+-----------+-------------+
|  1 | SIMPLE      | base_article | index  | NULL          | base_article_date_published |       9 | NULL                    |   30 | 833396.69 | Using where |
|  1 | SIMPLE      | mag_article  | eq_ref | PRIMARY       | PRIMARY                     |       4 | my_test.base_article.id |    1 | 100.00    |             |
+----+-------------+--------------+--------+---------------+-----------------------------+---------+-------------------------+------+-----------+-------------+
_

いくつかの理由により、回避できる場合は、このクエリにインデックスを強制する必要がないようにしたいと思います。特に、この基本的なクエリは、さまざまな方法（_issue_slug_によるフィルタリングなど）でフィルタリング/変更できます。その後、_base_article_date_published_は、使用するのに最適なインデックスではなくなります。

誰もがこのクエリのパフォーマンスを改善するための戦略を提案できますか？

mysqlperformanceindexjoinorder-by
11
Joshmaker

これはどうですか？データは既に正しいソートになっているので、「一時的な使用; filesortの使用」の必要がなくなります。

その必要性を取り除くために、MySQLが「一時的な使用; filesortの使用」を必要とする理由を知る必要があります。

必要性の除去についての説明は、2番目のsqlfriddleを参照してください

SELECT
      *
    FROM base_article

    STRAIGHT_JOIN 
      mag_article
    ON
      (mag_article.basearticle_ptr_id = base_article.id)

    WHERE
      base_article.is_published = 1

    ORDER BY
      base_article.date_published DESC

参照 http://sqlfiddle.com/#!2/302710/2

これはかなり前に必要でしたが、Country/cityテーブルの場合はこれも先ほど必要でした。ここにサンプルデータを含むデモを参照してください http://sqlfiddle.com/#!2/b34870/41

編集されたbase_article.is_published = 1が常に1つのレコードを返す場合、この回答を分析することもできます。説明はINNER JOIN配信テーブルが以下の回答のクエリのようにパフォーマンスを向上させる場合がある

https://stackoverflow.com/questions/18738483/mysql-slow-query-using-filesort/18774937#18774937

5
Raymond Nijland

クエリをリファクタリングする

SELECT * FROM
(SELECT * FROM base_article
WHERE is_published = 1
ORDER BY date_published LIMIT 30) A
INNER JOIN mag_article B
ON A.id = B.basearticle_ptr_id;

または

SELECT B.*,C.* FROM
(SELECT id FROM base_article
WHERE is_published = 1
ORDER BY date_published LIMIT 30) A
LEFT JOIN base_article ON A.id = B.id
LEFT JOIN mag_article C ON B.id = C.basearticle_ptr_id;

インデックスを変更する

ALTER TABLE base_article DROP INDEX base_article_is_published;
ALTER TABLE base_article ADD INDEX ispub_datepub_index (is_published,date_published);

試してみる ！！！

4
RolandoMySQLDBA