再次提问关于更新不到就插入的问题?
这是什么原理~
[解决办法]
我听老程序员的解释是，当主键是整数自整长数据加入的时候，内部机制会有重新排序，内部的排序并非使用该int型主键，而是使用uniqueidentifier，因为主键建立的时候会自动成为index。
所以大数据量表都建议使用uniqueidentifier作为主键。查询，添加删除数据整体效率更高。
[解决办法]
受教~我去查查资料呵呵
[解决办法]
不知道你的表格中数据有多少，如果数据很多（百万级别以上），那么也有可能是其他列上index排序造成。
[解决办法]
这个没有绝对，如果你的自增列是有聚集索引的话，insert几乎不产生任何影响，因为必然会插入到最后一个数据页的最后一行。除非你还有什么where条件之类的，使得插入操作发生在中间，这样会导致insert进去的那个位置以下的数据重新排序。而创建聚集索引的话，强烈建议加上unique，否则SQLServer会在内部增加一个4bit的隐藏列，和这个表的列组合成一个唯一的键。我觉得你那个“老程序员”说的应该是这个意思。Uniqueidentifier也不是不可以用，但是建议不要用newid()来生成，而用NEWSEQUENTIALID() 这个来生成，这样效能上会更加有优势。以上是在《SQLServer 2008 internal》上说的。
频繁插入、更新会导致碎片、统计信息过期的发生，重编译使得执行计划能获得当时最优化的信息。所以会觉得快一点。对于这些情况，保持统计信息的自动更新、降低索引的填充因子可能会对性能有帮助。
[解决办法]
对你说的没错，就是他的意思。
但是NEWSEQUENTIALID() 生成的Uniqueidentifier 和newid（）生成的Uniqueidentifier 在本质上有什么区别？
还有就是我有遇到过一个含有int类型的主键列的表格，内部数据都是排序过的，插入的数据尽管是排在最后，但是还是有明显的延迟，这个是什么原因？
（插入的时候不一定需要where条件，int型ID数据中间有遗漏再插入就是典型的情况。）
[解决办法]
联机丛书的说明：
在启动 Windows 后在指定计算机上创建大于先前通过该函数生成的任何 GUID 的 GUID。在重新启动 Windows 后，GUID 可以再次从一个较低的范围开始，但仍是全局唯一的。在 GUID 列用作行标识符时，使用 NEWSEQUENTIALID 可能比使用 NEWID 函数的速度更快。其原因在于，NEWID 函数导致随机行为并且使用更少的缓存数据页。使用 NEWSEQUENTIALID 还有助于完全填充数据和索引页。
重要提示：
如果涉及保密问题，则不要使用该函数。可以猜想下一个生成的 GUID 的值，从而访问与该 GUID 关联的数据。
然后我看到你那句话有一个地方，不知道是不是我想的那样，你的int只是主键，但是未设置自增，这样的话顺序就会造成影响因为主键会有聚集索引，然后会对表的顺序有影响，如果非自增，那么插入一个中间值而不是最大值的时候，就会导致页面重新组织、排序。这就是慢的理由之一，我不敢说就是唯一原因。
[解决办法]
以讹传讹，老程序员说的是uniqueifier不是uniqueidentifier，而且和主键是否整数无关。
uniqueifier是SQL强制聚集索引内部唯一的技术手段，因为所有的索引都指向聚集键（RID），所以聚集键内部必须能唯一标识一行数据，MSDN很清楚地说明这一点。