The difference should be negligible, assuming you fix one problem with your first example.
ServerA is sending the database to ServerB:
dbadm1@serverA:~$ mysqldump -C ... database | mysql -h serverB ... database
You have the
--compress) option in the wrong place, here. Move it to the remote machine:
dbadm1@serverA:~$ mysqldump ... database | mysql -C -h serverB ... database
--compress option compresses data on the socket, between the utility and the host it is connecting to. Using
--compress against whichever machine is local is going to accomplish nothing except waste CPU cycles. The data crossing the
| pipe is not compressed by this option.
Note also that this approach is problematic with large databases, because the pipe blocks, which means
mysqldump blocks, which means it stops reading from the network, which means the source server eventually blocks, while data is being written to the network. If this ever exceeds the value of
net_write_timeout on the source server for one continuous block of time, the source server will throw an error and terminate the connection. Increasing
net_write_timeout on the source server is a somewhat-viable workaround, but use caution, since the server blocking while writing to the network can cause other threads to stall while waiting for the table that's being blocked under certain circumstances.
I have an internal tool that eliminates this timeout issue, by implementing something resembling a ring buffer made up of gzipped temporary files, to allow the source server to write as fast as it can while allowing the buffer to drain into the target server as fast as it can (usually slower), while requiring no more temporary space disk than absolutely necessary by freeing each temporary "chunk" as soon as it's been sent down the pipe... it's invoked like
mysqldump | my-buffer-tool | mysql... though I don't have it in a releasable state yet. It's also useful for piping
mysqldump out to a compression utility without holding up the server.