这是一个很有意思的问题。SQL 耗时增大是什么样的SQL （查询还是DML）。这个SQL 是慢在哪里 资源不足还是阻塞。
逐步分析吧。可以吧语句贴上来看下

是不是因为：数据的物理位置移动了，所以需要重建索引 ？

是不是因为：数据的物理位置移动了，所以需要重建索引 ？

Quote: 引用 3 楼 samyp1234 的回复:

是不是因为：数据的物理位置移动了，所以需要重建索引 ？

聚集索引包含了 该行数据的具体位置信息，非聚集索引有指向聚集索引的指针；
所以我的理解：如果数据的物理位置移动了， 聚集索引、和 非聚集索引就必须重建了，  我的理解对吗 ？ 

Quote: 引用 6 楼 samyp1234 的回复:

Quote: 引用 3 楼 samyp1234 的回复:

是不是因为：数据的物理位置移动了，所以需要重建索引 ？

聚集索引包含了 该行数据的具体位置信息，非聚集索引有指向聚集索引的指针；
所以我的理解：如果数据的物理位置移动了， 聚集索引、和 非聚集索引就必须重建了，  我的理解对吗 ？ 

b不对，参考我上一条回复。

Quote: 引用 7 楼 z10843087 的回复:

Quote: 引用 6 楼 samyp1234 的回复:

Quote: 引用 3 楼 samyp1234 的回复:

是不是因为：数据的物理位置移动了，所以需要重建索引 ？

聚集索引包含了 该行数据的具体位置信息，非聚集索引有指向聚集索引的指针；
所以我的理解：如果数据的物理位置移动了， 聚集索引、和 非聚集索引就必须重建了，  我的理解对吗 ？ 

b不对，参考我上一条回复。

我想问一下，我的理解， （对于 聚集索引、非聚集索引） 为什么不对呢 ？ 

Quote: 引用 8 楼 samyp1234 的回复:

Quote: 引用 7 楼 z10843087 的回复:

Quote: 引用 6 楼 samyp1234 的回复:

Quote: 引用 3 楼 samyp1234 的回复:

是不是因为：数据的物理位置移动了，所以需要重建索引 ？

聚集索引包含了 该行数据的具体位置信息，非聚集索引有指向聚集索引的指针；
所以我的理解：如果数据的物理位置移动了， 聚集索引、和 非聚集索引就必须重建了，  我的理解对吗 ？ 

b不对，参考我上一条回复。

我想问一下，我的理解， （对于 聚集索引、非聚集索引） 为什么不对呢 ？ 

题主： 你说的非常对！

数据库文件，分配的是系统IO资源。 资源的物理地址变了，那么索引叶节点的地址肯定需要重编。
除了索引问题，查询变慢的原因是多方面的，比如数据迁移之后， 缓存统统失效，因此解析和取数本就是慢的。

先解决第一个问题，即索引是不是需要重建？

如果不重新建立索引，原先的索引是不是就无效了呢？
这取决于你是如何操作，将原本的数据文件，放到 SSD 新盘上去的。
1） 如果是在停掉 SQL Server 服务的情况下，将数据文件硬剪贴过去，然后重启服务，添加SSD数据文件，那么索引无效；
2） 如果是在SQL Server 运行的情况下，添加了 SSD 新盘的数据文件，然后往里头导入数据的，那么索引已经重建

我不知道你在移动数据文件的过程中，是如何操作的，根据你目前的状况，我们要做的事情，就是辨认，新的SSD 盘上的数据文件，到底存储了哪些表：

我这里有段脚本专门是用来辨认物理数据文件上，存储的数据库对象的（如果是生产环境，请不要在高峰期间使用）
修改红色字体部分为你的库

效果用下图來示意：


declare @tablename varchar(200)

declare @index_Id int

declare @sqlstatement nvarchar(max)

declare @databasename varchar(200) ='home'

declare cur_tables cursor

for (select schema_name(schema_id) +'.'+name as tableName

from sys.tables )

open cur_tables

fetch next from cur_tables into @tablename

if exists( select 1 from tempdb.sys.tables where upper(name) like upper('%tempTabIndall%') )

drop table #tempTabIndall ;

create table #tempTabIndall(PageFID bigint, PagePID bigint, IAMFID bigint, IAMPID bigint, ObjectID bigint, IndexId bigint, PartitionNumber bigint, PartitionID bigint,

iam_chain_type varchar(500) , PageType bigint, IndexLevel bigint, NextPageFID bigint, NextPagePID bigint,PrevPageFID bigint, PrevPagePID bigint)

create index idx_pagefid on #tempTabIndall(PageFID) ;

while @@FETCH_STATUS = 0

begin

declare cur_indexes cursor for

(select index_id from sys.indexes where object_id = object_id(@tablename))

open cur_indexes

fetch next from cur_indexes into @index_Id

while @@FETCH_STATUS = 0

begin

set @sqlstatement = N'insert into #tempTabIndall

exec sp_executesql N''DBCC IND(' + @databasename + ','''''+@tablename+''''',' + convert(varchar(max),@index_Id)+')''' ;

print @sqlstatement

exec sp_executesql @sqlstatement

fetch next from cur_indexes into @index_Id

end

close cur_indexes

deallocate cur_indexes

fetch next from cur_tables into @tablename

end

close cur_tables

deallocate cur_tables

select distinct

object_name(t.ObjectID) as tablename

, t.IndexId

, ti.name as IndexName

, f.FileGroupName

, f.Filegroup_type_description

, f.DefaultFileGroup

, f.datafile_type_description

, f.fileName

, f.file_physical_name

from #tempTabIndall t

inner join (select distinct object_id,index_id,name from sys.indexes) ti on t.ObjectID = ti.object_id and t.IndexId = ti.index_id

left join (

select

isnull(data_file_id,0 ) as data_file_id

, isnull(g.FileGroupName,'LOG File Group') as FileGroupName

, isnull(g.type_desc,'LOG FILE GROUP') as Filegroup_type_description

, isnull(g.is_default,0) as DefaultFileGroup

, f.type_desc as datafile_type_description

, f.name as fileName

, f.physical_name as file_physical_name

, f.state_desc as datafilestatus

, f.size_mb as datafile_size_mb

, f.max_size_mb as datafile_max_size_mb

from (

select name as FileGroupName

,data_space_id

,type_desc

,is_default

from sys.filegroups

) g

right outer join (

select

file_id as data_file_id

,type_desc

,data_space_id

,name

,physical_name

,state_desc

,size * 8 /1024 as size_mb

,max_size * 8 /1024 as max_size_mb

from sys.database_files

) f on g.data_space_id = f.data_space_id

)f on f.data_file_id = t.PageFID

order by f.file_physical_name asc ,object_name(t.ObjectID) asc, t.IndexId asc



如果你怀疑是 SSD 上的数据文件中存储的表，因为缺乏索引而变慢，那么只要筛选 file_physical_name 是你所用 SSD 盘路径，取其中一表，查看其或者依赖它的存储过程 的执行计划就可以。

我曾经写过一篇比较啰嗦的文章 ， 用来分析 SQL Server 的内部存储结构，你有兴趣可以参考 ：
https://blog.csdn.net/wujiandao/article/details/51501522

第二个问题，是你的查询变慢了

这就需要你来配合 ：
1 慢的 SQL ，其 SQL 语句及执行计划是不是可以贴一下 ？
2 在并发没有明显加大的情况 下 ，SQL  变慢可以通过  set profile time/IO 等方式 查询具体指标 ，比如解析慢了，还是 IO 慢了 
3 如果是查询多次之后 ，查询区域稳定，那么就是执行计划以及数据缓存重新抽取造成的，不必惊慌

我同样也写过 性能分析的文章 ，不怕啰嗦的话也可以读一读 
https://blog.csdn.net/wujiandao/article/details/51307741

其实，前面几位答主说的很对了，最快的方式就是直接重建索引，看看是否有效 ！

先找到 SSD 上的表，任选其一，查看其索引对应的数据页(DBCC IND) 是否已经是 SSD 文件路径。
按照你的操作，索引不需要重建。因为你把索引一起迁移了。
可能的情况是， 重建索引之后， SQL 性能未必马上就能提升。

是同一台云服务器上，将其中的一个数据文件移到ssd盘吧？另一个数据文件和日志文件还是在普通云盘？
先从大到小的范围进行排查， 内存、cpu、IO 都有什么变化。 数据库内的堵塞情况、找出几个语句执行看看是否正常。

Quote: 引用 13 楼 wujiandao 的回复:

先找到 SSD 上的表，任选其一，查看其索引对应的数据页(DBCC IND) 是否已经是 SSD 文件路径。
按照你的操作，索引不需要重建。因为你把索引一起迁移了。
可能的情况是， 重建索引之后， SQL 性能未必马上就能提升。

‘’

我没有把索引一起迁移啊，因为我本来有2个数据文件，我只通过分离、附加的方式移动了其中的1个数据文件到SSD上；
这样的操作后，索引不需要重建吗 ？