mysql - 2 つの内部結合を使用してクエリのパフォーマンスを向上させる方法は?

Question

私は3つのテーブルを持っています:

CREATE TABLE `t_event` (
  `id` int(10) NOT NULL auto_increment,
  `title` varchar(100) NOT NULL,
  `kind` int(10) NOT NULL,
  `type` int(10) NOT NULL,
  `short_desc` varchar(500) default NULL,
  `long_desc` varchar(1500) default NULL,
  `location` int(10) NOT NULL,
  `price` decimal(11,0) NOT NULL,
  `currency` int(11) NOT NULL default '1',
  `remark_price` varchar(250) default NULL,
  `remark_prerequisite` varchar(250) default NULL,
  `date_start` date NOT NULL,
  `date_end` date default NULL,
  `date_remark` varchar(300) default NULL,
  `time_start` time default NULL,
  `time_end` time default NULL,
  `remark_time` varchar(50) default NULL,
  `leader` int(50) NOT NULL,
  `leader2` int(100) NOT NULL,
  `eve_contact_name` varchar(50) default NULL,
  `eve_contact_phone` varchar(50) default NULL,
  `eve_contact_email` varchar(50) default NULL,
  `eve_contact_url` varchar(150) default NULL,
  `eve_image_path` varchar(250) default NULL,
  `provider` int(10) default NULL,
  `timestamp` datetime NOT NULL,
  `last_change` datetime NOT NULL default '0000-00-00 00:00:00',
  `quality` int(10) default NULL,
  `min_number` int(10) NOT NULL,
  `max_number` int(10) NOT NULL,
  `active_for_reservation` tinyint(1) NOT NULL,
  `cancellation_day1` int(10) NOT NULL,
  `cancellation_day2` int(10) NOT NULL,
  `cancellation_fee1` varchar(255) NOT NULL,
  `cancellation_fee2` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `FK_t_event_t_event_kind` (`kind`),
  KEY `FK_t_event_t_event_type` (`type`),
  KEY `FK_t_event_t_location` (`location`),
  KEY `FK_t_event_t_currency` (`currency`),
  KEY `FK_t_event_t_leader` (`leader`),
  KEY `FK_t_event_t_provider` (`provider`),
  KEY `FK_t_event_t_quality` (`quality`),
  CONSTRAINT `FK_t_event_t_currency` FOREIGN KEY (`currency`) REFERENCES `t_currency` (`id`),
  CONSTRAINT `FK_t_event_t_event_kind` FOREIGN KEY (`kind`) REFERENCES `t_event_kind` (`id`),
  CONSTRAINT `FK_t_event_t_event_type` FOREIGN KEY (`type`) REFERENCES `t_event_type` (`id`),
  CONSTRAINT `FK_t_event_t_leader` FOREIGN KEY (`leader`) REFERENCES `t_leader` (`id`),
  CONSTRAINT `FK_t_event_t_location` FOREIGN KEY (`location`) REFERENCES `t_location` (`id`),
  CONSTRAINT `FK_t_event_t_provider` FOREIGN KEY (`provider`) REFERENCES `t_provider` (`id`),
  CONSTRAINT `FK_t_event_t_quality` FOREIGN KEY (`quality`) REFERENCES `t_quality` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8432 DEFAULT CHARSET=latin1

CREATE TABLE `t_location` (
  `id` int(10) NOT NULL auto_increment,
  `loc_name` varchar(50) NOT NULL,
  `loc_detail` varchar(50) default NULL,
  `loc_adress1` varchar(50) NOT NULL,
  `loc_adress2` varchar(50) default NULL,
  `loc_country` int(50) NOT NULL default '1',
  `loc_zip` varchar(50) NOT NULL,
  `loc_loc` varchar(50) NOT NULL,
  `loc_shortdesc` varchar(250) default NULL,
  `loc_contact_name` varchar(250) default NULL,
  `loc_contact_gender` int(10) default NULL,
  `loc_contact_phone` varchar(250) default NULL,
  `loc_contact_email` varchar(250) default NULL,
  `loc_contact_url` varchar(250) default NULL,
  `loc_image_path` varchar(250) default NULL,
  `latitude` varchar(100) default NULL,
  `longitude` varchar(100) default NULL,
  `created` datetime NOT NULL,
  `last_change` datetime NOT NULL default '0000-00-00 00:00:00',
  `provider` int(10) NOT NULL default '1',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `id` USING BTREE (`id`),
  KEY `FK_t_location_t_country` (`loc_country`),
  KEY `FK_t_location_t_gender` (`loc_contact_gender`),
  KEY `FK_t_location_t_provider` (`provider`),
  CONSTRAINT `FK_t_location_t_country` FOREIGN KEY (`loc_country`) REFERENCES `t_country`(`id`),
  CONSTRAINT `FK_t_location_t_provider` FOREIGN KEY (`provider`) REFERENCES `t_provider` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1287 DEFAULT CHARSET=latin1

CREATE TABLE `t_dates` (
  `id` int(10) NOT NULL auto_increment,
  `events_id` int(10) NOT NULL,
  `events_start_date` date NOT NULL,
  `events_end_date` date NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `IND_id` (`id`),
  KEY `IND_events_id` (`events_id`),
  CONSTRAINT `t_dates_ibfk_1` FOREIGN KEY (`events_id`) REFERENCES `t_event` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=32048 DEFAULT CHARSET=latin1

私のクエリは次のとおりです。

SELECT e.*,I.* ,d.*
FROM t_event AS e
INNER JOIN t_location AS I ON   I.id = e.location
INNER JOIN t_dates  AS d ON  d.events_id  = e.id
;

このクエリの実行には 90 秒かかり、return = 27727

PROFILE コマンドは、セクション「データの送信」が実行にほとんど時間を要していることを示しています。EXPLAIN コマンドは次のとおりです。

+----+------------+------+------+----------------------------+--------------------+---------+-----------+-------+-------+
| id | select_type | table | type | possible_keys               | key                | key_len | ref       | rows | Extra |
+----+------------+------+------+----------------------------+--------------------+---------+-----------+-------+-------+
|  1 | SIMPLE     | I    | ALL | PRIMARY,id                 | NULL               | NULL    | NULL      |  1143 |       |
|  1 | SIMPLE     | e    | ref  | PRIMARY,FK_t_event_t_location | FK_t_event_t_location | 4       | wu_db.I.id |     4 |       |
|  1 | SIMPLE     | d    | ref  | IND_events_id               | IND_events_id       | 4       | wu_db.e.id |     3 |       |
+----+------------+------+------+----------------------------+--------------------+---------+-----------+-------+-------+

私の見解では、多数の列がこの速度低下の原因であるということですが、「SELECT e.id、I.events_id、d.id」と書いても 16 秒かかります。

LIMIT 句と OFFSET 句を使用してクエリを書き直す必要があると思いますが、どう思いますか?

各テーブルのレコード数:

t_event = 7991
t_location = 1086
t_dates = 27727

score 1 · Accepted Answer

大まかに言えば、MySQL はクエリ内の各テーブルから1 つのインデックスを使用してのみレコードをフィルタリングできます。

つまり、テーブルにはとのt_event両方に定義されたインデックスがありますが、クエリを満たすために使用できるのはこれらのインデックスの 1 つだけです。出力でこれを確認できます。これは、とキーの両方がおそらく有用であると識別されたことを示しています (後者は実際に使用するために選択されています)。idlocationEXPLAINPRIMARYFK_t_event_t_location

t_datesしたがって、列のテストを含むとの結合はid、インデックスルックアップではなくテーブルスキャンで実行されます。繰り返しますが、これは、 (テーブルスキャン) と(インデックスが使用されていない)EXPLAINを示す出力の最初の行から確認できます。type = ALLkey = NULL

テーブルの複合インデックスを作成する必要があり(id, location)ます。t_event

ALTER TABLE t_event ADD INDEX (id, location);

score 0 · Accepted Answer

私の見解では、多数の列がこの速度低下の原因であるということですが、 > "SELECT e.id, I.events_id, d.id" と書いても、それでも 16 秒かかります。

LIMIT 句と OFFSET 句を使用してクエリを書き直す必要があると思いますが、どう思いますか?

私はあなたが正しいと思います。

infiniteJOINの係数でを高速化できる場合は、「選択」フェーズをゼロに減らし、「データの送信」部分をそのままにしておきます。それが残りの 74 秒です。

つまり、クエリの最適化を無限に行うと、90 秒中 16 秒、全体で約 18% のアドバンテージが得られます。

これがバッチクエリの場合、時間はそれほど重要ではありません。そうでない場合は、私が信じているように、誰かが約 27,000 のアイテムの表示や概要を望んでいる可能性はほとんどないと思います。

「ページング」アプローチとは別に、またはページングアプローチが実用的でないことが判明した場合、またはページングアプローチに加えて、アプリケーションが何らかの「フィルター」クエリ (日付範囲、場所範囲) を使用できるかどうかを確認できます。）。

WHEREそのため、その選択をよりスリムにするためにどのような条件を使用できるかを研究しました。

それが Web アプリケーションの場合はSELECT、ID (既に試したクエリで 16 秒しかかからなかったクエリ、および WHERE を使用した場合はさらに少ないクエリ)、または可能な限り少ない列しか使用できませんでした。たとえば、すべての情報を保持する多くの「フォーム」を含む非常に長いページを表示しているとします。

...
+----------------------------------------+
| Date: ....  Place: ...... Notes: ....  |
| Leader: .... Cost: ....                |
  ... and so on and so forth ...
+----------------------------------------+
| Date: ....  Place: ...... Notes: ....  |
  ... and so on and so forth ...
+----------------------------------------+
...

代わりに、フェッチした列に対応する非常に基本的な最小限の情報セットのみを表示できます。

...
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
...

この時点で、ユーザーはリストをすばやくブラウズできるようになりますが、ほとんどの場合、すべてのフォームを開くことはなく、2 つまたは 3 つしか開くことができません。ユーザーがをクリックするOPENと、jQuery 関数はサーバーに対して非常に高速な AJAX 呼び出しを発行し、データに ID を提供します。次に、3 つの個別のクエリが関連するすべてのデータをミリ秒単位で取得します。

データが変換さjson_encode()れて jQuery に送り返され、フォームが「開き」、すべての情報が「アコーディオン」形式で表示されます。

+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......       <CLOSE>|
| large form with all the information
| ...
| ...
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|

この方法では、すべての列、特にとのような大きな列をすぐに取得する必要はありません。それらの間で 2 KB に達する可能性がありますが、ユーザーは非常に高速な応答を経験します。short_desclong_desc

mysql - 2 つの内部結合を使用してクエリのパフォーマンスを向上させる方法は?

2 に答える 2

Related

Reference