日時範囲で選択してください。

Question

私はテーブルpostsと6.5M +レコードを持っています。各投稿は固定長のnameで表されます。私はMySQL Community 5.7、約10K-20KのIOPSと1GBのメモリを持つSSDディスク、key-buffer-sizeを512Mに設定しています（ほとんどの場合、私はデフォルトのMySQL設定でドライブします）。私は限られたリソースしか持っていないので、MyISAMをストレージエンジンとして選択しました。私のベンチマークではMyISAMの方が速いことがわかりました。また、私はそれを更新することができるので、あまりデータを気にしません。

だから、ここに私スキームの情報です：

+------------+--------+------------+ 
| TABLE_NAME | ENGINE | row_format | 
+------------+--------+------------+ 
| posts  | MyISAM | Fixed  | 
+------------+--------+------------+ 

+---------------------+---------------------+------+-----+---------+----------------+ 
| Field    | Type    | Null | Key | Default | Extra   | 
+---------------------+---------------------+------+-----+---------+----------------+ 
| id     | int(11) unsigned | NO | PRI | NULL | auto_increment | 
| name    | char(30)   | NO | UNI | NULL |    | 
| worker_id   | tinyint(4) unsigned | NO | MUL | NULL |    | 
| processing_priority | tinyint(4) unsigned | NO | MUL | 0  |    | 
| last_processed_at | datetime   | YES | MUL | NULL |    | 
| scraped_at   | datetime   | NO | MUL | NULL |    | 
+---------------------+---------------------+------+-----+---------+----------------+ 

+-------+------------+---------------------+--------------+---------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| Table | Non_unique | Key_name   | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | 
+-------+------------+---------------------+--------------+---------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| posts |   0 | PRIMARY    |   1 | id     | A   |  6579588 |  NULL | NULL |  | BTREE  |   |    | 
| posts |   0 | name    |   1 | name    | A   |  6579588 |  NULL | NULL |  | BTREE  |   |    | 
| posts |   1 | last_processed_at |   1 | last_processed_at | A   |  6579588 |  NULL | NULL | YES | BTREE  |   |    | 
| posts |   1 | processing_priority |   1 | processing_priority | A   |   3 |  NULL | NULL |  | BTREE  |   |    | 
| posts |   1 | worker_id   |   1 | worker_id   | A   |   50 |  NULL | NULL |  | BTREE  |   |    | 
| posts |   1 | scraped_at   |   1 | scraped_at   | A   |  234985 |  NULL | NULL |  | BTREE  |   |    | 
+-------+------------+---------------------+--------------+---------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 

は、私が実行したクエリ：

SELECT COUNT(*) FROM `posts` WHERE `posts`.`worker_id` = 1 AND (last_processed_at >= '2017-11-04 22:20:27.203761') 

MySQLは、このクエリを実行する3676.4msを必要とします。

クエリは次のように説明し

+----+-------------+-------+------------+------+-----------------------------+-----------+---------+-------+--------+----------+-------------+ 
| id | select_type | table | partitions | type | possible_keys    | key  | key_len | ref | rows | filtered | Extra  | 
+----+-------------+-------+------------+------+-----------------------------+-----------+---------+-------+--------+----------+-------------+ 
| 1 | SIMPLE  | posts | NULL  | ref | last_processed_at,worker_id | worker_id | 1  | const | 232621 | 37.45 | Using where | 
+----+-------------+-------+------------+------+-----------------------------+-----------+---------+-------+--------+----------+-------------+ 

はあなたがそれを最適化することができますどのように任意のアイデアを持っていますか？

Answer 1

worker_idキーの代わりに、worker_idとlast_processed_atの組み合わせキーを作成できます。

Answer 2

あなたはスペースのために窮屈されている場合は、次の可変長namesため

• CHAR(30)は、おそらくそれは、必要に応じてASCIIまたはLATIN1、または3 回として大きな場合は必要以上に50％より大きく、あなたの.MYDファイルを作りますutf8の場合。
• すべての列に盲目的にインデックスを作成しないでください。それは.MYIファイル内のスペースを無駄にします。特に、INDEX(processing_priority)はおそらく使用されません。

SHOW CREATE TABLEと、スペースの設定をさらに批判するクエリのいくつかを見てみましょう。

1GBのRAMと512MBの場合は、key_bufferが本当に悪いです。まず、key_bufferはインデックスブロック（それぞれ1KB）をキャッシュするためだけです。第二に、OSにはデータをキャッシュする余地が必要です。第三に、コードやその他のデータのためのスペースが必要です。 key_buffer_size = 50M以下を推奨します。

（あなたの実際の質問については、@Turoが優れた答えを示しています）しかし、現在は冗長なINDEX(worker_id)を削除しましたか？ （これは70メガバイト程度保存されます。）

よりインデックス作成に：http://mysql.rjweb.org/doc.php/index_cookbook_mysql