Create a new table, that has all the columns of the existing table, but also a time column, which is set to the value of the time the snapshot was initiated. You're adding a new fact to store about an existing set of facts (each table should store one kind of fact, ideally). The value of the time column identifies each snapshot.
If you need to query across the whole table, then that's a practical disk IO problem. But, by keeping the data in plain old columns from the DB, you can add indexes to columns that are used by those time-consuming queries. If you need to keep aggregate data on the information, there's a disk IO problem with it being big, and the answer is to design views that perform those aggregations on updates, with intermediate historical data being maintained, instead of going over the whole data set every time. Keep as much large IO in the DB as possible.
A large table can be a problem for your memory and hard drives, should you need to access more than a small part of it, and is going to need a human touch to manage any large queries over it, with any design. MySQL, OTOH, will be fine with a very large table. Over-complicating it with many tables, or JSON stores, will do no good, and could come back to bite you if you ever need to perform any historical queries over it.