How to break down MySQL big table into multiple to solve operational issue
There are other things you could and should do, also.

Normalization.  For example, how many different values are there of GROUP_ID or SYSTEM_ID?  Rather than using a string, use a TINYINT UNSIGNED -- 1 byte and a range of 0..255, or maybe a SMALLINT UNSIGNED -- 2 bytes and 0.65K.  Etc.
Are any of the columns &quot;rare&quot;?  I mean are they NULL in many of the rows?  If so, design the split so that a new row is not a full 4 billion rows, but, instead, has only the needed rows.  Then use LEFT JOIN when you need to get NULLs back.
How were the UUIDs generated?  If they are standard, it is simple to compress down to BINARY(16) (16 bytes) from 36 bytes.
Don't blindly use (255), find a sensible, but conservative limit.  (This has a small impact on performance.)
What are the main queries now?  And after moving to 3 tables?  We should make sure the indexes are 'right' for all of them.  If the split is done 'wrong' certain queries will become much slower and cannot be fixed by indexes.
DETAILS takes about 2.5TB?  Probably that will shrink to less than 1TB if you compress it.  But do it in the client, not the server.  And then put the result in a MEDIUMBLOB.  And uncompress in the client after fetching.
Consider PARTITION.  It is unlikely to help anything.  However, if you purge &quot;old&quot; data, the process is much faster than DELETE.  It will not help with ALTER TABLE.
What do you use ALTER for?  There are some cheap tricks to perform for some tasks.
The PK being varchar(255) sounds awful; let's discuss alternatives.  Does any combination of other columns provide a unique key?
Do SELECT AVG(LENGTH(...)), AVG(LENGTH(...)), ... FROM t to see what is likely to be the benefit from each column.

&quot;Alter is used mainly for adding column and adding index&quot; --

MySQL 8.0 has faster ALTER operations.  Some are &quot;INSTANT&quot;.  You need to look carefully at the details to see which are fast versus which need a copy.  And some flavors block other actions more than others.
If the only goal is to add a new column, consider adding a new table instead.  This is similar to your original idea but without any of the downtime.  It can also take advantage of having rows only where necessary (see my LEFT JOIN comment above).
But...  If you need to search the new set (with multiple tables), some queries can be efficient, some will be terribly inefficient.  Please provide some concrete examples of what you have done in the past or might do in the future; I will explain in more detail.  Perhaps start a new Question and show the old CREATE TABLE and the new one, together with the SELECT that involves the new column; then ask about performance.