Just a few points I'm wondering about:

• Since the script only installs data on one server per run, and all the host/user/db-name params are needed on the command line for each run, is it really any more convenient than just doing the appropriate mysql command the same number of times?

• Why do you modify the content of the dump file as it goes through your script? I'm referring to the part that replaces every non-ascii byte with a space in the main foreach loop -- this seems especially strange, considering that your connection process includes "SET NAMES 'utf8'". What if some of the database tables are supposed to contain non-ascii data?

• (The other parts where you modify the dump file contents, removing lines that start with "--" and "/*...*/", strike me as good reasons to stick with the native "mysql" command-line tool, which already knows what to do with these things.)

• Have you benchmarked this against using the comparable mysql command line? I suspect that for doing lots of inserts to tables that are being created, the DBI::do() method will end up being many times slower than the native utility provided by mysql. (You could add stuff to your script to try optimizing, but you would just be re-inventing the stuff that the mysql command-line tool can already do, and the result would still be slower.)

• Why load the entire "batch file" (which I assume is a normal dump created by "mysqldump") into scalar variable in memory -- and then also make a complete copy of it as an in-memory array? What if it's a really huge database?

• Do you really need to specify the port number for the connection?

If the goal is to load the same data to several hosts/servers, I think you would want a script that works with a mysqldump file and a list of targeted servers (giving hostname, username, password for each one), so that one command line run can do all the loads. This would be easy, esp. if you just have a script that will build and run the native "mysql" command line for each server in the list.