如何设置聚集索引(Cluster Index)
答案:2 悬赏:80 手机版
解决时间 2021-11-13 08:43
- 提问者网友:焚苦与心
- 2021-11-12 21:54
如何设置聚集索引(Cluster Index)
最佳答案
- 五星知识达人网友:罪歌
- 2021-11-12 22:57
一、使用 SQL Server Management Studio
使用对象资源管理器创建聚集索引
在“对象资源管理器”中,展开要创建聚集索引的表。
右键单击“索引”文件夹,指向“新建索引”,然后选择“聚集索引…”。
在“新建索引”对话框的“常规”页中,在“索引名称”框中输入新索引的名称。
在“索引键列”下,单击“添加…”。
在“从 table_name 中选择列”对话框中,选中要添加到聚集索引的表列的复选框。
单击“确定”。
在“新建列”对话框中,单击“确定”。
使用表设计器创建聚集索引
在“对象资源管理器”中,展开要使用聚集索引创建表的数据库。
右键单击“表”文件夹,然后单击“新建表…”。
右键单击上面创建的新表,然后单击“设计”。
在“表设计器”菜单上,单击“索引/键”。
在“索引/键”对话框中,单击“添加”。
从“选定的主/唯一键或索引”文本框中选择新索引。
在网格中,选择“创建为聚集的”,然后从该属性右侧的下拉列表中选择“是”。
单击“关闭”。
在“文件”菜单上,单击“保存 table_name”。
二、使用 Transact-SQL
创建聚集索引
在“对象资源管理器”中,连接到 数据库引擎的实例。
在标准菜单栏上,单击“新建查询”。
将以下示例复制并粘贴到查询窗口中,然后单击“执行”。
USE yourdatabase;
GO
CREATE TABLE dbo.TestTable
(TestCol1 int NOT NULL,
TestCol2 nchar(10) NULL,
TestCol3 nvarchar(50) NULL);
GO
-- Create a clustered index called IX_TestTable_TestCol1
-- on the dbo.TestTable table using the TestCol1 column.
CREATE CLUSTERED INDEX IX_TestTable_TestCol1
ON dbo.TestTable (TestCol1);
GO
使用对象资源管理器创建聚集索引
在“对象资源管理器”中,展开要创建聚集索引的表。
右键单击“索引”文件夹,指向“新建索引”,然后选择“聚集索引…”。
在“新建索引”对话框的“常规”页中,在“索引名称”框中输入新索引的名称。
在“索引键列”下,单击“添加…”。
在“从 table_name 中选择列”对话框中,选中要添加到聚集索引的表列的复选框。
单击“确定”。
在“新建列”对话框中,单击“确定”。
使用表设计器创建聚集索引
在“对象资源管理器”中,展开要使用聚集索引创建表的数据库。
右键单击“表”文件夹,然后单击“新建表…”。
右键单击上面创建的新表,然后单击“设计”。
在“表设计器”菜单上,单击“索引/键”。
在“索引/键”对话框中,单击“添加”。
从“选定的主/唯一键或索引”文本框中选择新索引。
在网格中,选择“创建为聚集的”,然后从该属性右侧的下拉列表中选择“是”。
单击“关闭”。
在“文件”菜单上,单击“保存 table_name”。
二、使用 Transact-SQL
创建聚集索引
在“对象资源管理器”中,连接到 数据库引擎的实例。
在标准菜单栏上,单击“新建查询”。
将以下示例复制并粘贴到查询窗口中,然后单击“执行”。
USE yourdatabase;
GO
CREATE TABLE dbo.TestTable
(TestCol1 int NOT NULL,
TestCol2 nchar(10) NULL,
TestCol3 nvarchar(50) NULL);
GO
-- Create a clustered index called IX_TestTable_TestCol1
-- on the dbo.TestTable table using the TestCol1 column.
CREATE CLUSTERED INDEX IX_TestTable_TestCol1
ON dbo.TestTable (TestCol1);
GO
全部回答
- 1楼网友:神也偏爱
- 2021-11-13 00:01
聚集索引的好处就是可以让数据按照此索引的顺序进行物理位置存放,用blog_Comment表来说明,此表有comm_idcomm_logidcomm_authorcomm_posttime等字段比如说posttime between DATE1 and DATE2,OK这样的话聚集索引利用到了,因为这个区间段的数据是非常亲密地靠在一起的,可以用最少的I/O开销取得所需的结果集。可是我们知道,更多的时候我们是在显示一个article时然后读取它的所有comments,这时,过滤条件就成了comm_logid = ID了,如果聚集索引被comm_id心安理得地占用的话,那么很可能我们这批comments需要多个数据页才能得到,这样的话,就大大地增加了时间,因为I/O的开销比CPU在内存上的数据查找排序都是要高一个数据级的。但是聚集索引的改变同样会给其它的查询带来负面影响,比如说comm_id = ID的查询,在原来只需要在PK_blog_Comment_comm_id的聚集索引上查找记录,然后得到的指针指向就是实际数据块的存放位置了,但是现在,在此非聚集的唯一索引上查找得到的指针是指向IX_blog_Comment_comm_logid的的位置,所以需要多一次的Bookmark Lookup才能取得所需数据。其实使用的方法很简单,当你需要频繁地取得批量数据时,把聚集索引放在最有可能定位区间的字段上。另外blog_Article的聚集索引我放在posttime上了,因为经常要对此字段进行order by的查询,虽然logid和posttime的排序方向是一样的,但是我这样可能通过cluster index的lookup 节省一个order by的时间,不过到底孰优孰劣我还不敢下结论。其它的blog_Archive,blog_Category的聚集索引都在authorid上,因为这个都是对于authorid = ID的查询。也许随着数据量的增长,情况会有不同,这个以后再看情况调整了。
我要举报
如以上问答信息为低俗、色情、不良、暴力、侵权、涉及违法等信息,可以点下面链接进行举报!
大家都在看
推荐资讯