質問編集履歴
2
テーブルの設計を表からcreate文に変更
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -3,15 +3,24 @@
|
|
|
3
3
|
|
|
4
4
|
検索対象となるのは、例としてイベントへの応募データを管理する下記のようなテーブル(enters)です。
|
|
5
5
|
|
|
6
|
-
|
|
6
|
+
```ここに言語を入力
|
|
7
|
-
|
|
7
|
+
CREATE TABLE `enters` (
|
|
8
|
-
|
|
8
|
+
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
|
|
9
|
-
|
|
9
|
+
`event_id` BIGINT UNSIGNED NOT NULL,
|
|
10
|
+
FOREIGN KEY (event_id) REFERENCES events(id),
|
|
10
|
-
|
|
11
|
+
`name` varchar(255),
|
|
11
|
-
|
|
12
|
+
`status` TINYINT UNSIGNED NOT NULL,
|
|
12
|
-
|
|
13
|
+
`created_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
|
13
|
-
|
|
14
|
+
`edited_at` TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
|
|
15
|
+
);
|
|
14
16
|
|
|
17
|
+
CREATE TABLE `events` (
|
|
18
|
+
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
|
|
19
|
+
`name` varchar(255),
|
|
20
|
+
(省略)
|
|
21
|
+
);
|
|
22
|
+
```
|
|
23
|
+
|
|
15
24
|
このテーブルの更新対象カラムはstatusとedited_atのみ。
|
|
16
25
|
event_idでイベントテーブル(events)と結合し、イベント名(varchar型)を取得します。
|
|
17
26
|
|
1
誤字修正、補足説明追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -34,16 +34,16 @@
|
|
|
34
34
|
|
|
35
35
|
```ここに言語を入力
|
|
36
36
|
[SELECT...] ORDER BY created_at ASC LIMIT 1000
|
|
37
|
-
[SELECT...]
|
|
37
|
+
[SELECT...] WHERE event_id = 1 ORDER BY created_at DESC
|
|
38
|
-
[SELECT...]
|
|
38
|
+
[SELECT...] WHERE event_id = 1 AND status = 0 ORDER BY created_at ASC LIMIT 1000
|
|
39
|
-
[SELECT...]
|
|
39
|
+
[SELECT...] WHERE event_id = 1 AND status = 0 AND created_at >= '2020-01-01 00:00:00'
|
|
40
|
-
[SELECT...]
|
|
40
|
+
[SELECT...] WHERE created_at BETWEEN '2020-01-01 00:00:00' AND '2020-12-31 23:59:59' ORDER BY created_at DESC
|
|
41
41
|
```
|
|
42
42
|
|
|
43
43
|
### 実現したいこと
|
|
44
44
|
|
|
45
45
|
上記を踏まえ、まず最初の画面初期表示時に発行されるクエリの為に、"created_at"カラムにインデックスが必要だとは思うのですが、
|
|
46
|
-
それ以外のカラムについてはクエリのパターンが多く、どのようにすべきか悩んでいます。
|
|
46
|
+
それ以外のカラムについては"発行されるクエリ例"のようにクエリのパターンが多く、どのようにすべきか悩んでいます。
|
|
47
47
|
あらゆるパターンを考慮して複合インデックス含め作成しておくべきでしょうか。
|
|
48
48
|
|
|
49
49
|
なお、現状のレコード数は1000件にも満たないので、インデックスの有効性は無いと思っていますが、
|