ssd 上的 SQL Server 似乎很慢

我們最近將 SQL Server 遷移到 SSD，但性能提升並不大。

SQLIO 顯示出巨大的收益（快 15-100 倍），順序讀/寫速度高達 6GB/s。

但是當我們做一個簡單的查詢時：

select * 
into table2  
from table1

它大約是 60MB/s。2GB 表需要 30 秒才能完成。

這是正常的嗎？對於這樣一個簡單的查詢，SSD 的平均速度是多少？不相信這是 RAM 問題，50GB 的 RAM ..？

問題已解決，該虛擬機存在 IO 限制。

至於 SQLIO，它位於 hyper-v 上：

https://social.technet.microsoft.com/Forums/azure/en-US/b8e1674d-f1c7-4e46-b1f1-09fb0d75d82e/strange-blazingfast-io-performance-inside-hyperv-vm?forum=winserverhyperv

https://serverfault.com/questions/287311/does-sqlio-lie-when-run-from-a-hyper-v-guest-on-a-vhd

根據您的 SQL Server 版本，有多種因素會影響查詢的性能。

1. SQL Server 版本：如果您使用 TABLOCK 提示（僅限 SELECT INTO），SQL Server 2014 允許並行插入堆表。SQL Server 2016 對此進行了擴展，允許使用 INSERT SELECT 並行插入到堆或聚集列儲存索引中
2. SQL Server 版：企業版將發布比標準版更多出色的預讀 IO。
3. 碎片化：儘管 SSD 沒有尋軌延遲，但它們在大量順序讀取時仍然表現最佳。高水平的碎片將阻礙預讀的有效性。
4. 填充因子：重建一個填充因子為 5% 的索引，它將在磁碟上大 20 倍，因此讀取它的 IO 增加 20 倍。從碎片和預讀的角度來看，新重建的索引將是最佳的。

等待統計分析可以告訴您目前的瓶頸是什麼。如果您看到 PAGEIOLATCH_S，那麼閱讀就是問題所在。在源表上重建聚集索引。如果您沒有看到 IO 瓶頸，那麼我會假設您受 CPU 限制。尋找 1 個 CPU 為 100%（如果您的查詢正在執行單執行緒）。解決方案是添加 TABLOCK 提示以嘗試獲得一些並行性。

SELECT INTO 是批量記錄操作，不會使用 TEMPDB，因此無需查看日誌文件或 tempdb 的文件位置。

引用自：https://dba.stackexchange.com/questions/199535