SELECT count(*) from table给了我3296869行。
该表仅包含4列，存储已删除的域。我试图通过以下方式转储sql：
$backupFile = $dbname . date("Y-m-d-H-i-s") . '.gz';
$command = "mysqldump --opt -h $dbhost -u $dbuser -p $dbpass $dbname | gzip > $backupFile";
但是，这只是转储一个空的20 KB gzip压缩文件。我的客户端正在使用共享主机，因此服务器规格和资源使用不是最重要的。
我甚至没有直接访问ssh或直接访问数据库，因此我必须通过FTP上传的PHP脚本进行查询（SFTP不再是一个选项）。
我是否可以通过某种方式顺序下载部分内容，或将参数传递给mysqldump以优化它？
我遇到了http://jeremy.zawodny.com/blog/archives/000690.html提到了-q旗帜并尝试了但是它似乎没有做任何不同的事情。
编辑：刚想出可能mysqldump未安装且仅执行gzip，但系统不抱怨..尝试错误检查..
编辑＃2： which mysqldump返回/usr/bin/mysqldump所以就在那里。
答案 0 :(得分：4)
尝试使用此命令（不含空格）：
$command = "mysqldump --opt -h $dbhost -u$dbuser -p$dbpass $dbname | gzip -c > $backupFile";
在你的情况下，mysqldump试图从数据库$ dbpass转储表$ dbname并且不会找到它。
如果使用InnoDB表，也可以使用flag --single-transaction。
答案 1 :(得分：1)
我实际上在使用这样的PHP脚本的共享主机上看到了更好的结果：http://davidwalsh.name/backup-mysql-database-php。
简单地说，共享主机对这种东西并不友好。如果mysqldump在系统上，那么一旦系统看到CPU / RAM开始出现峰值，它就可能被自动杀死。它不太可能杀死一个php进程，但仍然可能。 YMMV。
你也应该尝试没有gzip的msqldump。很可能gzip就是这里的罪魁祸首。共享主机有时很奇怪。
答案 2 :(得分：0)
这是我备份I DB的方式：
mysqldump -h $dbhost -u $dbuser -p $dbpass $dbname | bzip2 -c > /tmp/databasebackup.sql.bz2
这就是我从备份文件恢复数据库的方式：
bunzip2 < databasebackup.sql.bz2 | mysql -u$dbuser -p
or:
mysql -u$dbuser -p < databasebackup.sql
希望它有所帮助。