When range partitioning, should I drop primary UUID-like key?
Assuming


Some queries involve a date range, usually "recent" dates,
Other queries are point-queries, which involves a unique key
You can purge data older than 18 months.


Anything else?

UUIDs are terrible for performance when the dataset size becomes too big to cache.

It would take some work, but this is what I recommend:

id INT UNSIGNED NOT NULL AUTO_INCREMENT -- or `BIGINT` if might go past 4 billion
dt DATETIME NOT NULL  -- or TIMESTAMP if you prefer
PRIMARY KEY(dt, id)
INDEX(id)


Characteristics:


The data is in datetime order, thereby making those queries very efficient,
Tacking id onto the PK assures that the it is unique,
id replaces your uuid_short in the application (so, code change),
There is a PK, which InnoDB really likes to have,
You won't need to keep adding RAM -- most of the activity is near the "end" of the table,
INSERTs are very efficient -- both the data (&amp; PK) and the secondary key (id) are being added to at the end.


Now, I will add on the purging.

PARTITION BY RANGE(TO_DAYS(dt)) is the optimal way to do it.  Define the ranges as months.  Each month: DROP (instantly) the oldest month and ADD a new month.  See my blog for more details.

How to transition from uuid_short to id?


Add the AUTO_INCREMENT id and INDEX(id) to the existing table in a single ALTER, 
Convert the app's use of uuid_short to id,
Drop the uuid_short column and change the indexes (all in a single ALTER),
Add PARTITIONing.


Steps 1,3,4 will each require copying over the entire table; the sooner you do it, the less downtime you will suffer.  Or consider pt-online-schema-change or gh-ost for doing them "online".

Another tip:  See if you can shrink any of the datatypes of other columns.