先找到 SSD 上的表,任选其一,查看其索引对应的数据页(DBCC IND) 是否已经是 SSD 文件路径。 按照你的操作,索引不需要重建。因为你把索引一起迁移了。 可能的情况是, 重建索引之后, SQL 性能未必马上就能提升。
[quote=引用 13 楼 wujiandao 的回复:] 先找到 SSD 上的表,任选其一,查看其索引对应的数据页(DBCC IND) 是否已经是 SSD 文件路径。 按照你的操作,索引不需要重建。因为你把索引一起迁移了。 可能的情况是, 重建索引之后, SQL 性能未必马上就能提升。
是同一台云服务器上,将其中的一个数据文件移到ssd盘吧?另一个数据文件和日志文件还是在普通云盘? 先从大到小的范围进行排查, 内存、cpu、IO 都有什么变化。 数据库内的堵塞情况、找出几个语句执行看看是否正常。
[quote=引用 8 楼 samyp1234 的回复:] [quote=引用 7 楼 z10843087 的回复:] [quote=引用 6 楼 samyp1234 的回复:] [quote=引用 3 楼 samyp1234 的回复:] 是不是因为:数据的物理位置移动了,所以需要重建索引 ?
[quote=引用 7 楼 z10843087 的回复:] [quote=引用 6 楼 samyp1234 的回复:] [quote=引用 3 楼 samyp1234 的回复:] 是不是因为:数据的物理位置移动了,所以需要重建索引 ?
[quote=引用 6 楼 samyp1234 的回复:] [quote=引用 3 楼 samyp1234 的回复:] 是不是因为:数据的物理位置移动了,所以需要重建索引 ?
[quote=引用 3 楼 samyp1234 的回复:] 是不是因为:数据的物理位置移动了,所以需要重建索引 ?
是不是因为:数据的物理位置移动了,所以需要重建索引 ?
27,582
社区成员
68,544
社区内容
加载中
试试用AI创作助手写篇文章吧