When I’m in doubt I usually look at the OH 2 docs to see if there are any differences. If not I try it out and see how it goes. While there are some new concepts introduced in OH 2, the vast majority of OH 1 stuff works just fine unchanged in OH 2.
Now THAT is a question I can answer. 
OK, I’ve no experience with OpenEnergyMonitor so cannot address that. As a general rule though a more specific binding will be easier and more feature complete than a more generic binding. So I would look at OpenEnergyMonitor first.
MQTT would be a really good second choice. It provides a bit more flexibility and control over things but it does require running a separate broker which you may not want to do in this deployment. I personally really like MQTT and found that once I had it set up I find more and more things to do with it.
I would probably put either the HTTP binding or the HTTP actions at about the same level as MQTT. The reason I would put this after MQTT is that by its very nature it becomes a polling/pull of the data rather than a subscribe/push.
Exec would be my last choice but mainly because a lot of people have a hard time getting it to work. You already have it working so you can either follow the old adage “If it ain’t broke, don’t fix it” rather than Red Green’s (an old Canadian tv show) motto of “if it ain’t broke, you aren’t trying hard enough.”
So persistence is strictly Item based. If you want to store three values separately you must use three Items which will result in three entries into whatever database you use for persistence (I like InfluxDB). You can correlate them by time as each entry is a tuple (state and datetime). You cannot define your own table space in MySQL and expect OH to populate it.
Also, each Item will be saved to the database as a separate transaction (assuming the underlying database supports transactions). So there is no way to force all the values to be saved in a single transaction.
The only thing I can think of would be to merge the three values into a String Item and persist that, but then you lose the numerical aspects of the measurements and will need to pull them out and parse them back into numbers in order to chart, calculate, or otherwise process them individually.
Presumably, you want to analyze and display this data in charts so I will recommend the InfluxDB+Grafana to get much more flexible graphing possibilities. I do believe that Grafana recently added support for MySQL so if you want to use that it might work.