Deciding what columns to use for partitioning
Always have an explicit PRIMARY KEY for any InnoDB table.  If practical, use a "natural" key -- a column, or combination of columns, that is unique.  Otherwise, add an AUTO_INCREMENT.

Learn about "composite indexes" -- this is using more than one column in an index.  It is often a good optimization.  It is not the same as having an index on each column.

It is OK for the indexes to take up more space than the data.  A quick survey showed 1/4 of my tables have that.  Having good indexes improves performance far more than the bulkiness hurts performance.

Each Index is updated for each row INSERTed, so having too many indexes hurts INSERTs (some).

You mentioned partitioning; did you mean "PARTITION BY ..."?  Don't do it unless you have a particular purpose.  I know of only 4 use cases; see my blog.

Do not bother to index low-cardinality columns (flags, enums, etc).  They won't be used.  If you have a status flag that is 10/90, then an index on just that column would be used for the 10, but not for the 90.  A composite index starting with that column may be always useful when all the columns (in the index) are in the WHERE clause.

The most important performance setting for InnoDB is to set innodb_buffer_pool_size to about 70% of available RAM.

It is usually a bad idea split DATE and TIME into two fields.  Look at how messy your SELECTs have to be.

How to create good indexes: http://mysql.rjweb.org/doc.php/index_cookbook_mysql

Show us some of the SELECTs; we can advise further.