[ZhukV]

На мой взляд нет.
Даже по логике действий МуСКЛ...
Любой дампер начинает считывать сначала БД, после того, переходит каждую БД и достает все таблицы и т.д. по цепочке.
Припустим есть две БД -- бд1, бд2, у нех есть куча таблиц.
Сначала читает бд1. Прочитал, создал бекап. Читает бд2. На это время, все, что будет подано в бд1, не будет в бекапе, поскольку бекап уже создан. Также происходит из таблицами.

Если нужно бекапить все бд, то лучше делать это крном, где-то в часом 5 утра, когда онлайна на сервере будет очень мало, и потери будут незначительные, тем более, лучше делать бекап прямо на сервере!!! Из-за того, что если делать с удаленного хоста, то огромные БД будут очень долго бекапится.
Был собственный пример.
На серве БД -- 148 МБ.
Друг бекапил из своего компа, зайняло приблизительно -- 10 мин.
Я бекапил при помощи -- backup-manager, и минуты не зайняло.

Добавлено через 11 часов 28 минут
Да, еще один совет.

В любой БД есть множество таблиц, записи которых давно уже не используются!!!
Желательно после бекапа производить чистку таблиц, чтобы они не засорялись и на время следующего бекапа не были по 1 Гб.
Сделать можно просто (только алгоритм):
1. Делаем бекап.
2. Проверям БД собственными скриптами, поскольку автоматизировать такой процес под всех не возможно. Припустим если у нас запись уже не будет использоватся, и она там стоит уже 1 месяц, так нах она.
3. Варианта два - Удаляем запись, либо переносим в резервное хранилище (таже копия БД, то в ней сохраняются старые записи)

В результате, старые записи будет удалены из активной БД, что ускорит работу БД + уменьшит нагрузку при более сложных запросах + в любой момент Вы сможете востоновить то или инное поле с резервной БД.

На заметку:
Если на сервере БД используются сложные запросы, то тогда нужно проставлять индексы в таблицах, что достаточно ускорит поиск. Дело в том, что если установлен первичный индекс, то при поиске [WHERE], если искомое поле совпадает с названием индекса, первоначально проверяются индексы, а аж потом вся таблица.
Для элементарного примера:
Некая таблица
id, iw, im
11 12 13
21 22 23
31 32 33
41 42 43

Предположим, что индекса нет, то при запросе типа -- SELECT * FROM table WHERE id=41 -- буду проверятся все ячейки по порядку (11 - 12 - 13 - 21 - 22 - 23 ...). А если записей милион, и полей 100?
Предположим, что индекс -- id. При таком же запросе, сначала проверится поле индекса так же по порядку (11 - 21 - 31 - 41), а потом, если уже не найдет, начнет искать далее.
--------------
ПРИ УСЛОВИИ, ЧТО ЕСТЬ НЕСКОЛЬКО ВЫБОРОК
--------------
Также следует знать, что есть замечательная фича, как Views.
Припустим в запросе Вы очень часто юзаете LEFT JOIN | RIGHT JOIN, либо делаете груповые запросы. Такие запросы дают нагрузку на серв, и иногда даже фатальную.
Виход. Создать вюшку (в инете есть документации), а потом обращатся к вюшке как к обычной таблице -- SELECT * FROM name_view WHERE `field` = '123123';
Когда вюшка создается она проверяет таблицы, достает результаты и формирует вюшку. Данные вюшки летят в кеш. После, при запросе, все берется с кеша, а не а активным таблицам. Также при создании вюшки создаються типа тригеры (в МуСКЛ они тоже есть, но не то) на редактирование таблиц, которые принадлежат вюшке. В результате, при редактировании одной из таблиц, кеш немного перезапишется (именно то что было поправлено).
Результат: При более сложных запросах и при их ОГРОМНОМ количестве, можно снизить нагрузку БД в 2, а то и более раз.

P.S.
С БД нужно быть немного острожным, поскольку на ней держится все -- сервер, сайт, фтп, квоты и т.д (кто что придумает). И если впадет мускула, можно сказать, УПАЛО ВСЕ!!!