Database design for a lot of rows with data archive
A sliding time scale is very efficient by using PARTITIONs.  Implement 14 hourly partitions using PARTITION BY RANGE(..).  Use REORGANIZE PARTITION to create a new partition every hour.  Use "transportable tablespaces" (assuming you are using 5.6, or preferably 5.7, and InnoDB) to move the 'old' partition away from the main table to the archive table.

More on timed partitions (including code).

More thoughts:


Although TRIGGERs may be functional, I worry that they are costly in your situation.  Can you elaborate.  Perhaps partitioning can serve a purpose there, too.
I hope the Query cache is completely turned off:  query_cache_type = 0 and query_cache_size = 0; otherwise it could be causing some of the slowdown.
How do you do the millions(?) of INSERTs per day?  One row at a time?  Or batched (much better)?
For the 'data analysis', do you build and maintain "Summary tables"?  With such, you may not need the triggers, archive, etc.  Reporting from a summary table is easily 10x faster, and does not touch the main table.
Have you looked into Master-Slave as a way of (1) archiving the data, and (2) providing a Reporting platform separate from the main table.  This, too, could eliminate the need for triggers/archive/etc.


Could you provide more numbers -- how many users?  inserts/sec?