我有駕駛我（和我的客戶）了牆的問題。他們在Windows上運行MySQL的 - 我繼承了這個平臺，我沒有設計它，更改爲MSSQL在Windows或MySQL實例遷移到* NIX VM是不是在這個階段的選項。的mysqldump在Windows性能隨時間降解
服務器是一個Windows VM，合理specced（4個vCores，16 GB RAM等）
開始 - 他們有一個操作系統的單盤，MySQL和MySQL的備份位置，他們得到不一致備份，定期與錯誤消息失敗：
的mysqldump：得到錯誤號22上寫
最後，我們通過簡單的備份目標移動到第二個虛擬磁盤（即使它是解決了，這是相同的底層存儲網絡，我們認爲上述錯誤是由底層操作系統引起的）
而生命是好的....
約2-3個月
現在我們有一個不同的（但我的直覺告訴我相關的）問題：
MySQL的轉儲過程正在變得越來越長（在過去的4天裏，轉儲所需的時間每次增加大約30分鐘）。
數據庫本身有點大 - 58 Gb，但是三角洲的大小隻有每天大約100 MB（除非我錯過了一些東西 - 它不應該花30分鐘額外的時間來轉儲100 MB的數據）。
最初我們認爲這是底層存儲網絡I/O--不過作爲備份腳本的一部分，一旦.SQL文件被創建，它就會被壓縮到8.5Gb左右 - 而且這個過程非常的簡單所需時間保持一致 - 這導致我不會懷疑磁盤I/O（因爲我的推測是，如果情況如此，Zip時間也會增加）。
，我用它來調用備份腳本是這樣的：
%mysqldumpexe% --user=%dbuser% --password=%dbpass% --single-transaction --databases %databases% --routines --force=true --max_allowed_packet=1G --triggers --log-error=%errorLogPath% > %backupfldr%FullBackup
的mysqldump的版本是C：\ Program Files文件\的MySQL \ MySQL服務器5.7 \ BIN \ mysqldump.exe
現在複雜的問題 - 我主要是一個Windows用戶（所以MySQL的經驗有限），辦公室裏的所有Linux專家都不會碰它，因爲它在Windows上。
我懷疑在增加時間的原因是有一些時髦的發生與行鎖（可能是由於使用了MySQL實例的應用程序） - 但我不知道。
現在對於我的問題：有沒有人經歷了時間的MySQL的逐步增加任何類似傾倒隨着時間的推移？ 是否有Windows上的方法來監視本地mysqldump的表現找到瓶頸在哪裏/鎖？ 在Windows平臺上進行常規MySQL備份有更好的方法嗎？ 我應該只是告訴客戶它不受支持並將其遷移到受支持的平臺嗎？ 如果我只是說出一個4字母的單詞，並去酒吧和消愁解悶？
FAT32或NTFS？一個大文件？或多個較小的文件？轉儲管道是否通過拉鍊傳輸？ （或者在Windows上真的有這種可能嗎？）InnoDB？還是MyISAM？ –
NTFS文件系統 這是一個轉儲到單個文件中的單個數據庫 轉儲沒有管道到Zipper，它在批處理文件中作爲單獨的一行運行 DB是InnoDB – TheDemonLord