To nie jest problem.
Przede wszystkim dyski SSD znacznie się poprawiły w ciągu ostatnich lat. Nadmiarowe sprawdzanie i wyrównywanie zużycia (i w niewielkim stopniu polecenie TRIM, choć nie ma zastosowania w twoim przypadku) sprawiły, że są one całkiem odpowiednie jako wytrzymałe dyski ogólnego zastosowania. Nie używam niczego poza dyskiem SSD na moim komputerze programistycznym (który regularnie wykonuje dużo kompilacji), nawet nie zbliżając się do liczby cykli kasowania.
Ponadto to oświadczenie:
Dyski SSD nie lubią masowych ciągłych zapisów i mają tendencję do ich niszczenia
jest całkowicie błędny. Przeciwnie, częste małe zapisy , jeśli w ogóle, mogą spowodować uszkodzenie dysków SSD.
W przeciwieństwie do tradycyjnych dysków twardych dyski SSD (a raczej pamięć wewnętrzna oparta na NAND) są fizycznie zorganizowane w dużych blokach, które logicznie zawierają kilka sektorów. Typowy rozmiar bloku to 512 kB, podczas gdy sektory (które są jednostką używaną przez system plików) mają tradycyjnie 1 kB (możliwe są różne wartości, dwie dekady temu 512B było powszechne).
Z blokiem 512 kB można zrobić trzy rzeczy. Można go odczytać, część lub całość można zaprogramować (= zapisać do), a całość można usunąć. Kasowanie jest problematyczne, ponieważ istnieje ograniczona liczba cykli kasowania i można usunąć tylko cały blok.
Dlatego duże zapisy są bardzo przyjazne dla SSD, podczas gdy małe zapisy nie.
W przypadku małych zapisów kontroler musi wczytać blok, zmodyfikować kopię, usunąć inny blok i zaprogramować go. Bez buforowania, w najgorszym możliwym przypadku, trzeba by usunąć 512 000 bloków, aby zapisać 512 kilobajtów. W najlepszym możliwym przypadku (duży, ciągły zapis) musisz wykonać dokładnie 1 kasowanie.
Wykonanie importu do bazy danych MySQL różni się znacznie od wykonania wielu osobnych zapytań dotyczących wstawiania. Silnik jest w stanie zwinąć wiele zapisów (zarówno danych, jak i indeksów) razem i nie musi synchronizować między każdą parą wstawek. Jest to o wiele bardziej przyjazny dla SSD wzór zapisu.