Select all rows (700000) very long time - hours - mysql

Question

I use mysql mariadb(Server version: 10.3.20-MariaDB-1:10.3.20+maria~stretch mariadb.org binary distribution).
I have ~700 000 records with columns:
id
html (mediumtext) with very big average length in field: ~150000
date
+2 small other
In html I have very long text (it's html's).
Now I need select * from table;, to analyse this html but this query takes over ~0.03819s per query (I tested on smaller part) so: total rows 700000*0.03819s per query = (700000*0.03819s)/60/60 = over 7 hours of selecting!
I have 8 cores and 60GB of RAM. Profiling query shows that time of transferring data is very very long.
How to speed it up? It's is possible, or that much of data it's too much for mysql and I need mongodb?
query_cache_limit = 64M
query_cache_size = 1024M
max_allowed_packet = 64M
net_buffer_length = 16384
max_connect_errors = 1000
thread_concurrency = 32
concurrent_insert = 2
read_rnd_buffer_size = 8M
bulk_insert_buffer_size = 8M
query_cache_limit = 64M
query_cache_size = 1024M
query_cache_type = 1
query_prealloc_size = 262144
query_alloc_block_size = 65536
transaction_alloc_block_size = 8192
transaction_prealloc_size = 4096
max_write_lock_count = 16
innodb_buffer_pool_size=30G
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=16
innodb_flush_method=O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 16
innodb_buffer_pool_instances = 20
MariaDB [db]> explain select id, href, html from raw limit 10;
+------+-------------+-------+------+---------------+------+---------+------+--------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+------+---------------+------+---------+------+--------+-------+
| 1 | SIMPLE | raw | ALL | NULL | NULL | NULL | NULL | 658793 | |
+------+-------------+-------+------+---------------+------+---------+------+--------+-------+
1 row in set (0.227 sec)
after playing with indexes:
MariaDB [db]> show index from raw;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| raw | 0 | PRIMARY | 1 | id | A | 658793 | NULL | NULL | | BTREE | | |
| raw | 1 | id | 1 | id | A | 658793 | NULL | NULL | | BTREE | | |
| raw | 1 | href | 1 | href | A | 658793 | NULL | NULL | YES | BTREE | | |
| raw | 1 | date | 1 | date | A | 131758 | NULL | NULL | YES | BTREE | | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
4 rows in set (3.724 sec)

Answer 1

38ms to fetch 150Kb from a spinning disk is quite fast.
query_cache_size = 1024M -- This is much too high. Stop at about 50M.
A PRIMARY KEY is a unique index. So, if id is the primary key, do not also say KEY(id).
It's is possible, or that much of data it's too much for mysql and I need mongodb?
Assuming you are running at disk speed, you cannot expect any other product to run faster.
What will the client do with 100GB of data in one batch? MySQL will be happy to deliver it, but the client will probably choke to death.