相关疑难解决方法(0)

我是出于好奇而问这个问题的，受到这个问题的启发。

我们知道该VARCHAR(MAX)值超过8000个字节并不存储在行，但在不同的LOB页。随后检索具有此类值的行需要两个或多个逻辑 IO 操作（实际上，理论上需要多一个）。

我们可以将一VARCHAR(MAX)列作为INCLUDEd添加到唯一索引，如链接问题所示。如果此列的值长度超过 8000 字节，这些值是否仍会“内联”存储在索引叶页中，还是也将移动到 LOB 页？

我有一个表，用于捕获用户正在运行的主机平台。该表的定义很简单：

IF OBJECT_ID('[Auth].[ActivityPlatform]', 'U') IS NULL
BEGIN
    CREATE TABLE [Auth].[ActivityPlatform] (
        [ActivityPlatformId] [tinyint] IDENTITY(1,1) NOT NULL
        ,[ActivityPlatformName] [varchar](32) NOT NULL
        ,CONSTRAINT [PK_ActivityPlatform] PRIMARY KEY CLUSTERED ([ActivityPlatformId] ASC)
        ,CONSTRAINT [UQ_ActivityPlatform_ActivityPlatformName] UNIQUE NONCLUSTERED ([ActivityPlatformName] ASC)
    ) ON [Auth];
END;
GO

它存储的数据是基于 JavaScript 方法枚举的，该方法使用来自浏览器的信息（我不知道更多，但可以在需要时找到）：

但是，当我在SELECT没有显式的情况下执行基本操作ORDER BY时，执行计划显示它正在使用UNIQUE NONCLUSTERED索引而不是CLUSTERED索引进行排序。

SELECT * FROM [Auth].[ActivityPlatform] 

当显式指定 时ORDER BY，它正确地按 排序ActivityPlatformId。

SELECT * FROM [Auth].[ActivityPlatform] ORDER BY [ActivityPlatformId]

DBCC SHOWCONTIG('[Auth].[ActivityPlatform]') WITH ALL_LEVELS, TABLERESULTS 显示没有表碎片。

我错过了什么可能导致这个？我一直认为该表是在聚集索引上创建的，它应该自动隐式地对其进行排序，而无需指定ORDER BY …

数据线

create table t
(
    id int,
    id1 int
)

create index Example_Index
  On t(id,id1)

create index Example1_Index
  On t(id1,id)

数据管理语言

insert into t(id, id1)values(1, 100)
insert into t(id, id1)values(1, 101)
insert into t(id, id1)values(2, 103)
insert into t(id, id1)values(1, 104)
insert into t(id, id1)values(3, 105)
insert into t(id, id1)values(1, 106)
insert into t(id, id1)values(2, 107)
insert into t(id, id1)values(3, 108)

SQL查询- select * from t Where id = 107 -用途Example_Index

SQL查询- select * from t Where …