Select by datetime range is very slow in MySQL - mysql

Question

I have table posts with 6.5M+ records. Each post is represented using fixed length name. I use MySQL Community 5.7, SSD disk with around 10K-20K IOPS and 1GB memory, key-buffer-size set to 512M (BTW mostly I drive with default MySQL config). I have limited resources therefore I have choosed MyISAM as my storage engine. My benchmarks showed me that in my case MyISAM is faster. Also I don't care about data so much because it can be renewed.
So, here is my scheme info:
+------------+--------+------------+
| 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 | | |
+-------+------------+---------------------+--------------+---------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
The query I run:
SELECT COUNT(*) FROM `posts` WHERE `posts`.`worker_id` = 1 AND (last_processed_at >= '2017-11-04 22:20:27.203761')
MySQL needs 3676.4ms to execute this query.
Query explained:
+----+-------------+-------+------------+------+-----------------------------+-----------+---------+-------+--------+----------+-------------+
| 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 |
+----+-------------+-------+------------+------+-----------------------------+-----------+---------+-------+--------+----------+-------------+
Do you have any ideas how it can be optimized?

Answer 1

You could create a combined key with worker_id and last_processed_at, replacing the worker_id key.

Answer 2

If you are cramped for space:
CHAR(30) for variable length names possibly makes your .MYD file 50% bigger than it needs to be if Ascii or latin1, or 3 times as big as needed if utf8.
Don't blindly index every column; that wastes space in the .MYI file. In particular, INDEX(processing_priority) is probably never used.
Let's see SHOW CREATE TABLE and some of the queries to further critique the setup for space.
1GB of RAM with 512MB for key_buffer is really bad. First, the key_buffer is only for caching index blocks (1KB each). Secondly, you need room for caching data, which the OS does. Third, you need room for code and other data. Recommend no more than key_buffer_size = 50M.
(As for your actual question, #Turo gives an excellent answer.) But did you remove the now-redundant INDEX(worker_id)? (That will save about 70MB.)
More on index creation: http://mysql.rjweb.org/doc.php/index_cookbook_mysql