wobei manchmal über 6 Sekunden gemessen wird und manchmal nur 0,20 Sekunden.
Bevor ich messe würde ich nachdenken. Meine Glaskugel meint: Es kann „gut“ sein, dass bei den schnell laufenden SQL-Abfragen die Ergebnisse aus den Cache kommen (weil die der SQL-Server NOCH im Antwort-Cache hat), bei anderen ein Full-Table-Scan erforderlich wird. Und die sind „teuer“.
-
Wie viele Datensätze hast Du denn so in den Tabellen? Weniger als 1000? Dann wechsle den Anbieter.
-
Sind bei allen SQL-Anfragen die Spalten in WHERE, LIKE und ORDER-Klauseln indiziert?
Helfer im Terminal:
cd /var/www/htdocs;
grep -RnPi "WHERE |LIKE |ORDER ";
Wenn ja
- Gibt es Zugriffe, bei denen etwas wie LIKE "%foo" oder "%foo%" verwendet wird?
cd /var/www/htdocs;
grep -Rni "LIKE.*%";
Wenn ja:
Stelle sicher, dass die Tabellen im InnoDB- oder MyIsam-format gespeichert sind und Lese hier und erzeuge einen FULLTEXT-Index. - oder hier: https://dev.mysql.com/doc/refman/5.6/en/fulltext-search.html
NUR wenn das nicht geht:
Baue eine Spalte foo_DESC, mach ein
UPDATE tabelle set `foo_DESC` REVERSE(`foo`);
und dann statt
SELECT foo, bar, baz FROM tabelle WHERE foo LIKE "%str";
eben
SELECT `foo`, `bar`, `baz` FROM tabelle WHERE `foo_DESC` LIKE "str%";
Du musst dann künftig jeden Neueintrag auch passend behandeln, alsofoo_DESC
mit dem REVERSE($string) befüllen...
Bei etwas wie
SELECT foo, bar, baz FROM tabelle WHERE foo LIKE "%str%";
musst Du ohne Fulltext-Index leider mit dem Problem leben.