Wie sich mySQL selbst verhält weiß ich nicht genau. Aber ich schätze mal, es wird nur dann auf Datenträger geschrieben, wenn es nötig ist. Das könnte das Ablegen von Daten sein, aber möglicherweise auch ein Clean-Vorgang sein o.ä.
Jedenfalls hast du bei SD-Karten die Wahl: Premium-Hersteller, wie SanDisk werben mit Wear-Leveling auf ihren SDs, also einer deutlich höheren Lebenserwartung. Dazu hilft es einen möglichst großen Speicher zu verwenden, diesen aber nicht voll auszunutzen (z.B. 10%-20% unformatiert lassen).
Ich kenne die Faustregel, dass ein Gigabyte SD-Speicher ca. 5Terabyte Schreibvolumen standhält. Aber das ist natürlich auch wieder Hersteller bzw.Qualitätsabhängig. Jedenfalls kannst du dir an Hand dessen ja ungefähr ausrechnen, wie lange die Karte bei deinem Verwendungszweck leben würde.
Bei Verwendung einer übergroßen SD mit WearLeveling von einem namhaften Hersteller, bewegst du dich also, was die Lebenserwartung betrifft, in einem ähnlichen Bereich wie aktuelle SSDs.
Ausserdem kann man z.B. bei den ext-Filesystemen die commit time einstellen. Also einen zeitlichen Mindestabstand zwischen Schreibzugriffen. Alles was währenddessen an zu schreibenden Daten anfällt, wird (solange freier RAM verfügbar ist) im RAM zwischengespeichert und vermindert somit drastisch die Anzahl dre Schreibvorgänge. Somit bist du davon, wie oft mySQL selbst gerne auf den Datenträger schreiben würde unabhängig. Theoretisch kann man die Commit-Time auf extreme Werte einstellen, aber das stellt natürlich ein immenses Risiko für die Daten da. Denn alles was noch nicht geschrieben wurde, geht bei einem Absturz, Stromausfall o.ä. natürlich verloren. SQL wird zwar normalerweise robust implementiert, ist aber dennoch nicht vor Datenverlust durch ein beschädigtes Filesystem gefeit.
Alternativ kannst du F2FS verwenden. Für Flash-Speicher optimiert reduziert es in sich die Schreibzyklen, ob es auch dort einen einstellbaren Commit gibt ist mir nicht bekannt.
In der Praxis hat sich für mich, um im Heimserver die Festplatten häufiger und länger Schlafen zu legen, bewährt möglichst alle unnötigen Daemons zu deaktivieren und auch unnötige Logs auszuschalten usw. Das Herumspielen mit dem Commit hingegen erschien mir eher zu riskant, da wäre F2FS vorzuziehen.
Preload macht auf Systemen mit wenig RAM keinen Sinn. Es würde dir nur den knappen Arbeitsspeicher zuräumen und Geschwindigkeitsvorteile sind auch abseits vom RAM-Mangel nicht wirklich zu erwarten, wenn die (eher schwache) CPU eine zusätzliche Bremse darstellt.
