Чем больше записей, тем лучше будут сжиматься GUID ключи
Разницы в 14 раз конечно нет - сравни кол-во страниц идексов.
Правда, индекс по int оказался слабее заполнен - это от того, что ты задом наперёд INT ключи вставлял.
Если бы вставлял последовательно, то заполнение было бы гораздо выше.
Но для честного сравнения с GUID нужно генерить случайные значения.
Ну а для эмуляции ПК - каверное всё же последовательно возрастающие.

На кол-во расщеплений страниц индекса влияет как распределение значений ключей (случайное для GUID против последовательного для INT), так и заполненность страниц.
Так что я бы сказал, что для ПК-GUID конкуренция за вставку в индекс должна быть гораздо ниже, чем для последовательных INT значений.

ТаблоидА как можно понять, что при работе 100500 коннектов на вставку некоторые из них будут томиться в ожидании именно индекса (а не генератора, скажем; при условии, что я дёргаю gen_id с шагом 1, а не "пачками") ? Ни как. Разве что смотреть вывод lock print для классика.

ТаблоидВ логе сервера всё равно ничего не увидишь :(А при чём тут лог сервера ?
Напомню - он существует исключительно для информации о ошибках, в основном о фатальных (и для твоих любимых сетевых )

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

Только я тебе сразу скажу - при твоих десятках индексов на таблицу это не поможет :)