phpMyAdmin exports a database inside a PHP request, so it is bounded by max_execution_time, memory_limit, the web server’s own timeout and the browser staying open. Somewhere around a few hundred megabytes all four start mattering at once. wp db export is not doing any of that — it reads the credentials out of wp-config.php and executes mysqldump.
# credentials from wp-config.php; no PHP limits involved anywhere
wp db export backup-$(date +%F).sql
# unknown arguments are handed straight to mysqldump
wp db export --single-transaction --quick backup.sql
# stdout, so a 9 GB dump never lands on disk uncompressed
wp db export - | gzip > backup-$(date +%F).sql.gz
# just the tables that matter, when the stats plugin is most of the size
wp db export --tables=wp_posts,wp_postmeta,wp_options content.sql
wp db import backup-2014-09-23.sqlThe pass-through is the part worth remembering, because it means every mysqldump flag is available without a wrapper: --single-transaction for a consistent InnoDB dump that does not lock writers, --no-data for a schema-only copy to diff against staging. Nothing is happening in PHP, so the job that phpMyAdmin abandoned finishes and there is a real exit status to check in a cron entry. Two cautions. It needs a shell on the machine and mysqldump on the path, which rules out most shared hosting. And wp db import will overwrite whatever database wp-config.php points at without asking, so on a server hosting several sites the --path argument is the difference between a restore and an incident.