mysql - large table - index performance and query issue
ASPECT #1: Indexing
There is no need to add the PRIMARY KEY value id to the index. Why ?
According to the MySQL Documentation of Clustered and Secondary Indexes, Paragraphs 1,2 under the Subheading How Secondary Indexes Relate to the Clustered Index say the following:

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.
If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

Thus, the primary key is automatically added to a secondary index.
The proof of this is in the XML output
  &quot;used_key_parts&quot;: [
    &quot;loc_country&quot;,
    &quot;job&quot;,
    &quot;loc_city&quot;,
    &quot;id&quot;
  ],

and
  &quot;used_columns&quot;: [
    &quot;id&quot;,
    &quot;loc_country&quot;,
    &quot;job&quot;
  ],

ASPECT #2: Table Compression
Compression might be greatly contributing to the slowness. After all, InnoDB must decompress data coming from that table for it to reside in the InnoDB Buffer Pool. In addition, the InnoDB Buffer Pool holds both compressed and uncompressed data and index pages. How so ???
According to the MySQL Documentation on How Compression Works for InnoDB Tables
, Paragraphs 1,2 under the Subheading Compression and the InnoDB Buffer Pool say the following:

In a compressed InnoDB table, every compressed page (whether 1K, 2K, 4K or 8K) corresponds to an uncompressed page of 16K bytes (or a smaller size if innodb_page_size is set). To access the data in a page, MySQL reads the compressed page from disk if it is not already in the buffer pool, then uncompresses the page to its original form. This section describes how InnoDB manages the buffer pool with respect to pages of compressed tables.
To minimize I/O and to reduce the need to uncompress a page, at times the buffer pool contains both the compressed and uncompressed form of a database page. To make room for other required database pages, MySQL can evict from the buffer pool an uncompressed page, while leaving the compressed page in memory. Or, if a page has not been accessed in a while, the compressed form of the page might be written to disk, to free space for other data. Thus, at any given time, the buffer pool might contain both the compressed and uncompressed forms of the page, or only the compressed form of the page, or neither.

SUGGESTION #1
Since the Buffer Pool holds both compressed and uncompressed pages, maybe increasing the InnoDB Buffer Pool size might slightly improve things. How ?
InnoDB has to evict unused pages from the Buffer Pool. A larger buffer pool reduces the number of times the Buffer Pool hasd to be cleared to make waves for new pages.
SUGGESTION #2
Perhaps changing the size of compressed pages might slightly improve things. This would require reloading the table with the new compression size. Please see my old post innodb_file_format Barracuda on changing the KEY_BLOCK_SIZE would be needed.
UPDATE 2020-12-12 19:52
Here is a crazy trick to try
Instead of your query
SELECT id FROM core
WHERE id!=518601449
AND loc_country='Mongolia'
AND id &lt; 518601449 AND job='a'  LIMIT 151\G

Try refactoring as follows
SELECT id FROM (SELECT id FROM core WHERE loc_country='Mongolia' AND job='a') A 
WHERE id &lt; 518601449 LIMIT 151\G

This will force the loc_country_2 index to gather ids in the subqueries first. Then, all IDs &lt; 518601449 are dismissed. Finally, the LIMIT 151 is imposed.
I do not guarantee the result will be better. It could be worse.
You won't know until you try it out and see or at least look at the EXPLAIN plan !!!