Александр Гладченко абсолютно прав, говоря об отличиях переиндексирования и дефрагментирования. Однако у них есть одна общая неприятная деталь: они аллоцируют под себя доп.пр-во, к-е затем забывают отдавать. Рассмотрим простейший пример:
use Northwind
exec sp_spaceused 'Order Details', 'true'
У меня получилось 72 KB под данные, 200 KB под индексы и 0 неиспользованного пространства. Поскольку таблица имеет кластерный индекс, под данными здесь понимаются его листовые страницы: то, что в выдаче dbcc tab обозначается типом 0 (при IndexID = 1). Cделаем dbcc dbreindex('Northwind.dbo.[Order Details]') или dbcc indexdefrag(0, 'Order Details', 1) - без разницы. Теперь exec sp_spaceused 'Order Details', 'true' по прежнему говорит про 9 страниц данных и 25 индексных, а вот в unused space появилось 48 КВ, что увеличило общий размер таблицы до 320 КВ.
Сначала я подумал, что первоначально у индекса был филлфактор, который реиндекс восстановил, от чего таблица слегка раздулась. Но филлфактор только раздвигает индексные записи по страницам, они не перестают от этого числиться как used. dbcc extentinfo показывавает следующую вещь:
1 208 8 8 325576198 1 0x4040404040404040
1 368 2 8 325576198 1 0x4040000000000000
1 361 1 1 325576198 2 0x6000000000000000
...
Из 2-й строчки видно, что эти непонятные 48 КВ кучно лежат во втором экстенте кластерного индекса. Кроме reindex / defrag подозреваемых, как мы видим, нет. Зачем они их резервируют и почему не отдают взад, я не знаю. Во всяком случае dbcc shrinkdatabase('Northwind'), когда проходит по таблице, видит, что pg_alloc < ext_size и выкидывает их нафиг. Поэтому я думаю, что посл-ть Ваших действий абсолютно правильная: реиндекс перестроил листики по порядку, уменьшив кол-во перепрыжек с экстента на экстент, а шринк за ним подчистил.

Без разницы в том плане, что и после того, и после другого появились 6 зарезервированных, но не задействованных страниц. После дефрагментации индекс, конечно, имеет fillfactor, как и после переиндексации. Из BOL: DBCC INDEXDEFRAG also compacts the pages of an index, taking into account the FILLFACTOR specified when the index was created. Any empty pages created as a result of this compaction will be removed. Просто в моем примере с Northwind пустых страниц и мусора, неизбежного в случае интенсивной работы с серьезной базой, просто не было. Что касается их разницы, то опять же цитата из BOL: Unlike DBCC DBREINDEX or any general index build, DBCC INDEXDEFRAG is an online operation, so it does not hold long-term locks that can block running queries or updates. Depending on the amount of fragmentation, DBCC INDEXDEFRAG can be considerably faster than running DBCC DBREINDEX because a relatively unfragmented index can be defragmented much faster than a new index can be built. Another advantage is that with DBCC INDEXDEFRAG, the index is always available, unlike DBREINDEX . A large amount of fragmentation can cause DBCC INDEXDEFRAG to run considerably longer than DBCC DBREINDEX, which may or may not outweigh the benefit of the command's online capabilities. DBCC INDEXDEFRAG will not help if two indexes are interleaved on the disk because INDEXDEFRAG shuffles the pages in place. To improve the clustering of pages, rebuild the index.