Столкнулся тут с SQL-сервером FireBird.
Забавное, такое решение, но с некоторыми сюрпризами.
С базой работали в течение нескольких лет, и в результате данные в файле базы данных были сильно фрагментированы.
Простой запрос SELECT COUNT(*) с любой заполненной таблицей подвисал примерно на минуту.
Сначала было сделано копирование файла на другое место, чтобы сам файл стал без фрагментов, но это не спасло ситуацию.
Потом была попытка удалить часть старых данных, но она так и не завершилась - система несколько часов показывала загрузку 100%, но процесс до конца так и не дошёл.
Была запущена проверка базы, которая тоже выполнялась очень долго, но сказала, что в базе всё в порядке.
Потом было принято разумное решение - выгрузить базу в BackUp - для проверки, и выгрузилась она успешно и не сказать, чтобы процесс был долгим.
Потом этот BackUp был загружен обратно в новый файл базы (команда с создать базу) - загрузка шла ещё быстрее.
После была проверена функциональность базы - всё просто летало - все селекты выполнялись в одну-две секунды.
Собственно, и удаление старых данных было выполнено достаточно быстро и без проблем (хотя, по скорости работы "новой" базы можно было сказать, что удаление и не нужно).
Насколько я понимаю, проблема с базой была в том, что из-за частого добавления данных в разные таблицы произошла сильная фрагментация файла базы данных, что очень замедлило работу SQL-сервера.
Насколько я понимаю, эта проблема существует для любого SQL-сервера.
Интересно, кто что про это думает ...
P.S. просто даже в нормальном MS SQL есть задания по оптимизации свободного пространства, но насколько они реально оптимизируют расположение таблиц, найти не удалось.

Суперокна?

Для Firebird backup/restore это, можно сказать, штатный способ дефрагментации.
Ну, ещё есть рекомендация как с этой фрагментацией бороться:
http://www.firebirdfaq.org/faq335/

Для sql server дефрагментация выполняется путем реорганизации или перестроения индексов (reorganize/rebuild).
Для оценки степени фрагментации есть системная вьюха sys.dm_db_index_physical_stats

(2) Проблема не в дефрагментации файла (которая решается копированием файла и перемещением новой на место старого), а в дефрагментации таблиц внутри файла, когда страницы выделяются не блоками, а по очереди для каждой растущей таблицы - в результате - получается "бутерброд".

(0)SELECT COUNT(*) это простой запрос? Что же у вас тогда сложным будет?

(4) На самом деле, SELECT COUNT(*) для FireBird - самый сложный запрос, так как требует полного сканирования таблицы.
Если в запросе используется какое-то индексное поле, то он выполняется не прямым сканированием таблицы, а выборкой по индексу, которая, кстати, выполняется быстрее.
Просто, любой SQL-сервер выполняет процедуры оптимизации индексов, в вот оптимизацию хранения данных под прямое сканирование никто не делает - очень большие затраты на оптимизацию и непонятный результат - нормальные запросы не должны выполняться прямым сканированием.