I did a write-up on the significance of network latency in the DBI to a remote RDBMS that you will probably find useful, which you can find here. As I demonstrate in that discussion, the impact of per-row commits (all done inside a single transaction) is highly significant if your RTT to the database server is much larger than a local LAN.

In my lab setup (using normal delays we get at $work between 2 cross-country data-centers,) I show a 5400% slowdown using a per-row approach. Based on this evidence, I disagree with the earlier suggestions to only ever insert 1 row at a time; if you are on a local network, this might be fine, but as always, you should do your own testing and tuning. Many times there's no need to complicate things early (also known as premature optimization.)

As long as you use prepared statements, the "built" query will be safe. The fact that you're dynamically building the (?),(?) sequence makes no difference in the protection you get by using a placeholder and executing by passing in the data you want.

The one hint I will give you is that it's usually also a good idea to cap the number of rows you send; if you're inserting many thousands of rows, you may want to batch them in groups of no larger than 500 or 1000, committing after each. This limits the impact of a network or other error partway into an insert of a 1 million rows, for instance.

I hope my writeup and findings can be useful for you. Good luck!