Where MySQL is taking time either in disk read or computation?
Rule of Thumb:  If the necessary data is cached, the query will run 10x faster than if not.  I have seen this in a wide variety of queries.  (Of course, the "10" varies a lot, too.)

Assuming

 SELECT yeard, COUNT(*) FROM t GROUP BY yeard;

 INDEX(yeard)


The Optimizer will scan the entire INDEX(yeard) of 150M 'rows'.  It does not have to do much more (at a high level) than count rows until yeard changes.  That is the INDEX and the GROUP BY work well together; they are not two separate steps.


About 400 index entries per 16KB block.
100 blocks/second is a more realistic estimate for InnoDB hitting HDD.  (This goes away for any blocks that are cached.)
150M/400/100 = 3750 seconds.  So, 54s for SSD seems about optimistic.  Or some of the blocks were cached.


If you run the query a second time (after all the blocks are cached), it may run 10x faster.

It's hard to say how many CPU cycles a query will take.  The code to "get the next row" (even of an index) is somewhat generic, and meanwhile, it is building (probably) an in-memory hash of the results.  There are also steps to parse the query, decide how to optimize it, deliver the results, etc.

The EXPLAIN in this example will say "Using index", meaning that it only used the index's BTree and did not need to touch the data's BTree.

The BTree is really a B+Tree, meaning that consecutive blocks are linked, making linear scans (as with your query) efficient.