我正在刻錄 NVME SSD、3x 60GB MySQL 數據庫（網路爬蟲）
我製作了一個在 3 台電腦上拆分的網路爬蟲，每台電腦都進行許多數據庫查詢，我認為每秒（每台伺服器）大約
2003000-4000 個查詢不間斷，短峰值為 12000-14000。
- 我正在使用 Centos 7.9 和 Mysql 5.7 社區伺服器。
- 每個伺服器上的數據庫大約 40-60 GB，所有表都是InnoDB
- 總記錄是在 3 個伺服器上拆分的 1 億個 url，1 億個“連結”，1 億個 url_meta。
- 1300萬個域名等
- 每個伺服器上的每個表大約 15 GB（連結、url、url 元等）。
- CPU 是 12 執行緒的 Ryzen 5 3600
- 每台伺服器 64 GB 記憶體
- nvme SSD：
- 1x GIGABYTE GP-ASM2NE6500GTTD 500GB（非“企業”型）
- 2x 金士頓 SEDC1000BM8480G 480GB“企業”nvme。
我現在最擔心的是技嘉 nvme 顯示為 30% 磨損，僅僅 3 個月後。金士頓企業的說他們是 2%
raid 命令smartctl說我讀了大約 10 TB，我在每個 nvme 上寫了大約 70 TB。
如果我沒記錯的話，我將我的 innodb_buffer_pool_size 設置為大約 1 GB，我現在增加了它並忘記了以前的值：confused:
爬蟲不斷地從每台伺服器上 30-4000 萬條記錄的表中讀取要爬取的 url，按上次爬取日期 ASC 對它們進行排序，讀取遠端 url 內容，更新數據庫中的 url_meta（標題、描述等）。更新在該 url、連結標題等中找到的連結。
這很快使表變得非常碎片化，除非我執行“優化表”，否則它們會非常緩慢地返回查詢。
我嘗試創建 2-3 個最重要的表的副本，並且每週只更新一次，並將其用於讀取，因此它仍然是碎片整理的。這是我注意到 SSD 磨損的時候，2 台帶有企業級金士頓 nvme 的伺服器在 3 小時內完成（複製 + 優化表），技嘉一台在 9 小時內完成。
使用“實時”碎片表在 10 秒內返回爬蟲中的搜尋查詢，而優化/整理表後大約需要 0.2 秒。
我應該怎麼做才能優化它並避免破壞 nvmes ？
我在想鴨絨：
- 嘗試使用 HDD 進行硬體設置，並且僅將 nvme SSD 用於只讀記憶體。我有機會從 HDD 執行所有這些查詢嗎？
- 優化所有記憶體選項以盡可能少地寫入磁碟。請問我可以得到這方面的提示嗎？
- 只使用具有更多 TBW 的 SSD 嗎？
對於我的第二個選項……我根本不熟悉調整選項，除了innodb_buffer_pool_size之外我應該研究哪些？64 GB 中的 32 GB 對於這種情況來說是一個好的開始嗎？而且我看到有一些選項可以控制記憶體數據“刷新”/寫入 SSD 的頻率？我可以得到一些關於這方面的資訊嗎？理想情況下，我希望它盡可能多地使用記憶體並且很少寫入 SSD。失去數據並不是什麼大不了的事，但我會在再次抓取它時浪費時間。
如果我因為所有寫入命令而切換到 HDD，64 GB 記憶體會有幫助嗎？或者查詢會變得無法使用緩慢嗎？我看到帶有快閃記憶體記憶體和 HDD 的 RAID 卡比單獨的 HDD 快，但是 RAID 卡快閃記憶體記憶體就像 SSD 一樣磨損，不是嗎？！
我有點迷路了：/
InnoDB + SSD ==> 沒有值得注意的碎片 ==> 不要使用
OPTIMIZE TABLE. 你聲稱在這方面的經歷是沒有意義的。
innodb_buffer_pool_size考慮到您的其他應用程序後，應該是大約 70% 的 RAM。（1G 太低了。）這可能是您看到的性能問題的一部分。
OPTIMIZE TABLE==> 大量額外寫入 ==> 磨損 SSD 而不會磨損。這可能會有所幫助：
innodb_doublewrite = OFF. 它會帶來輕微的數據損壞風險，具體取決於作業系統和 SSD 的詳細資訊。這可能會有所幫助：
sync_binlog = OFF你在用
autocommit = ON嗎？還是經常使用BEGIN...COMMIT？我建議在處理每個頁面的各種插入/更新周圍使用後者。（我假設這涉及對多個表的多次寫入。）如果您手邊有一些旋轉驅動器空間，請考慮將“日誌”移動到那裡。（古老的智慧是日誌的“順序”性質非常適合 HDD。我不知道現在是否仍然如此，但它可以節省一些 SSD 的“磨損”。）
關閉查詢記憶體。
進一步分析：http: //mysql.rjweb.org/doc.php/mysql_analysis
更高的 QPS
對於修訂後的 QPS：
- 使用“企業”SSD
- 在不交換的情況下將 buffer_pool 設置得盡可能大
- 做 BEGIN..COMMIT （如果可行）
- 在峰值期間尋找任何“慢”查詢。（在峰值期間，由於似乎永遠不會終止的連接數量的增加，系統有“卡住”的風險。加速長時間執行的查詢可能是一個快速解決方案。現在尋找這樣的預防措施。
首先，無論哪種類型，我都建議使用企業級儲存設備。它們明顯更可靠。您的高流量使用將使任何消費級設備磨損。
您還沒有描述任何執行緩慢的查詢。根據我的經驗，碎片表和優化表之間的性能差異不大。非優化表佔用更多儲存空間，但由於 InnoDB 在內部將記錄儲存為長鍊錶並且無論如何都會進行大量隨機訪問，因此如果按順序儲存行並沒有太大幫助。
RAM 的延遲甚至比 NVMe 儲存設備低幾個數量級，因此最好在 RAM 中保存更多數據，而不是擔心您使用哪種類型的儲存設備。
增加 RAM 分配：
innodb_buffer_pool_size至少增加到表空間大小的 10%。現在你有 1GB，這是表空間大小的 1/60。您的查詢可能是受磁碟限制的，經常在緩衝池中交換 InnoDB 頁面。由於伺服器上有大量 RAM，因此您最好分配超過 10% 的表空間。我建議你的表空間大小的 50%，或大約 30GB，看看性能是否有所提高。
您還應該確保使用索引很好地優化查詢。這是一個複雜的主題。您可能會喜歡我的展示文稿：如何設計索引，真的（影片）。這個想法是使用索引來縮小搜尋範圍，而不是一次掃描一大組數據。