Growing database pains Happy new year everyone.  I'm hoping for some general guidance in the following situation...
I have an application that has been running for about 10 years.  The datastore is in mysql, (now on AWS Aurora).
Some of the tables that are in one-to-many relations are starting to have a larger number of rows:
Records (~1.4million rows) 
        |
        V
    (1 to many)
        |
        V
SubRecords (~10million rows)
        |
        V
    (1 to many)
        |
        V
SubSubRecords (~22million rows)

There is not a lot of actual data being stored in these rows (ie subSubRecords is about 5gb in total), and the queries I run are very straightforwards, using indexed keys with no joins.  For example...
SELECT ... FROM Records WHERE id = ?;
SELECT ... FROM SubRecords WHERE recordId = ?;
SELECT ... FROM SubSubRecords WHERE subRecordId = ?;

So far, everything continues to be highly performant.
However, I'm starting to worry about how this design will hold up over time.  While it took 10 years to get to 22 million rows in SubSubRecords, the db is growing a lot faster now.  I wouldn't be surprised to see that table climb to 100million rows over the next 5 years, which feels like a lot.  And I'm not sure at what point it will become a problem.
I realize this is a rather broad question, and is situation-dependent.  But what what types of solutions are generally recommended in these cases?

Setup partitions? (The tables use foreign keys to enforce integrity
and my understanding is that this is incompatible with partitions.)

Convert the data in subRecords and subSubRecords to a json payload
and store that directly in a json column in the main records table?
(Same amount of data, but less rows, if it matters.)

Move to an entirely different db?  (Mongo?  I know nothing about it
but have heard is better at scaling in certain situations.)

Ignore it until it becomes an issue? :D


Any suggestions / pearls of wisdom from those who have wrestled with
similar problems is welcome.  Thanks (in advance) for your help!
Addendum:
As requested, here is the CREATE TABLE syntax for the above tables...
CREATE TABLE records (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    typeId TINYINT(1) UNSIGNED NOT NULL,
    userId INT UNSIGNED NOT NULL, 
    updated TIMESTAMP DEFAULT NOW() NOT NULL,
    savename VARCHAR(100) NOT NULL,
    title VARCHAR(100) NOT NULL,
    instructions TEXT NOT NULL,
    FULLTEXT ftRecords(savename, title),
    PRIMARY KEY(id),
    FOREIGN KEY(typeId) REFERENCES recordTypes(id),
    FOREIGN KEY(userId) REFERENCES users(id) ON DELETE CASCADE
) ENGINE=InnoDB CHARACTER SET=utf8;

CREATE TABLE subRecords (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    recordId INT UNSIGNED NOT NULL,
    thumbnailId INT UNSIGNED NULL,
    sortOrder SMALLINT NOT NULL,
    enabled TINYINT(1) DEFAULT 0 NOT NULL,
    title VARCHAR(100) NOT NULL,
    instructions TEXT NOT NULL,
    parameters VARCHAR(500) NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(recordId) REFERENCES records(id) ON DELETE CASCADE,
    FOREIGN KEY(thumbnailId) REFERENCES thumbnails(id) ON DELETE SET NULL
) ENGINE=InnoDB CHARACTER SET=utf8;

CREATE TABLE subSubRecords (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    subRecordId INT UNSIGNED NOT NULL,
    thumbnailId INT UNSIGNED NULL,
    sortOrder SMALLINT NOT NULL,
    caption VARCHAR(200) NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(subRecordId) REFERENCES subRecords(id) ON DELETE CASCADE,
    FOREIGN KEY(thumbnailId) REFERENCES thumbnails(id) ON DELETE SET NULL
) ENGINE=InnoDB CHARACTER SET=utf8;
100M rows is not scary.
Partitioning -- No.  It is unlikely to add any performance benefit.  If, however, you need to purge &quot;old&quot; data, there might be a use for partitioning.
If recordId is an INDEX of SubRecords -- Good.
If recordId is the first column in the PRIMARY KEY of SubRecords -- better.
Show us SHOW CREATE TABLE for further advice.
Your 3 SELECTs would run faster if you JOINed the 3 tables in a single SELECT.
Clustering
A slight improvement would be to improve the &quot;clustering&quot; of the rows that you fetch at the same time.  For SubRecords,
ALTER TABLE SubRecords
    DROP PRIMARY KEY(id),
    ADD PRIMARY KEY(recordId, id),
    ADD INDEX(id);

That way, when you get the several SubRecords for one Record, they will be located next to each other.  This is because the PRIMARY KEY (in InnoDB) is 'clustered' with the data.  The INDEX(id) is to keep AUTO_INCREMENT happy.
This change may not show any noticeable improvement until the dataset is bigger than RAM.
A similar thing can be done with SubSubRecords.