_Промешан_,

Оно в определенной степени не лучше и не хуже.
Как по мне единственная проблема с identity increment это contention на последней странице при энтенсивной вставке, о чем говорит Гавриленко. Тут может помочь :
•Use a random Clustered Key value (like a UNIQUEIDENTIFIER). But be aware of the side-effects: larger logical pointer in EVERY Non-Clustered Index, Page Splits…)
•Implement Hash Partitioning, if you are using the Enterprise Edition of SQL Server.
•Eliminate latching through the use of In-Memory OLTP, that is part of SQL Server 2014.
•Use a so-called Reverse Index. Unfortunately SQL Server doesn’t provide you that kind of index out-of-the box, like Oracle. But you can implement it at your own…
Как и многое связанное с SQL здесь также можно сказать It depends...
Если вы будете бездумно добавлять везде GUID то можете получить сильную фрагментацию, Page Split, плюс это 16 байт, которые также будут в каждом некласт. индексе, а при использовании identity increment вы получите hotspot в виде последней стрницы. Я к чему, надо нагрузку знать знать на таблицу, только тогда можно что-то решать.

aleks222,

И только каждый раз новая последовательность при перезгрузке сервака. Из Bol:
Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique.
И
The UuidCreateSequential function has hardware dependencies. On SQL Server, clusters of sequential values can develop when databases (such as contained databases) are moved to other computers. When using Always On and on SQL Database, clusters of sequential values can develop if the database fails over to a different computer.

И раумеется использовать его для того чтобы убрать last page contention полностью бесмысленно ибо это практически тот же identity с определенными оговорками.

_Промешан_,

Не быстрые диски, не много памяти тут не помогут. В чем суть, это проблема возникает из-за латчей. Латчи это (вырезка из Internals 2016):
Latches are lightweight synchronization objects that protect the consistency of SQL Server internal data
structures. As the opposite of locks, which protect transactional data consistency, latches prevent the
corruption of the data structures in memory.
Consider a situation where multiple sessions need to update different rows on the same data page.
Those sessions would not block each other, because they don’t acquire incompatible locks on the same
objects. SQL Server, however, must prevent the situation where multiple sessions simultaneously update
a data page structure in-memory, making it inconsistent and corrupting it. Moreover, SQL Server needs to
prevent other sessions from accessing the data page structure at the time of modification. SQL Server uses
latches to achieve this.
When the thread cannot obtain a latch on the data structure, it is placed into the FIFO queue, where it
stays suspended - и вот здесь как раз возникает проблема. Хоть латчи и кратковременны, но когда множество потоков вставляют на одну и туже страницу это становится проблемой.
К примеру можете прочесть тут

_Промешан_,

Нет, но они получают другие проблемы, о которых было сказано выше. Вы похоже не читаете что вам пишут. Из ссылки которую я привел выше:
Another solution is to use a non-sequential key in order to load data all over the index and not only at the end of it. By doing this, we spread the load and not creating a hotspot. This sounds like a very bad idea at first, because it generates lots of page splits and fragmentation when inserting the data, but it turns out page splits are less problematic for insert performance than latch contention. Also, in order to limit the amount of fragmentation, you can work with a low fillfactor (even 10%), and by doing so, you basically create “buckets” that will be ready for each row, instead of generating fragmentation when the insert occurs. If you use this method, watch out for your table size, as it can make your table quite larger than in other methods.

TaPaK,

Если честно прочел по диагонали этот абзац:) с fillfactor здесь конечно автор погаричился.