Es gibt Datenbanken, die stehen unter grosser Last, weil die Queries sehr komplex sind. Andere Datenbanken sind immens gross. Eine meiner Datenbanken hat sehr viele Zugriffe, sowohl lesend als auch schreibend. Heute wurde der Server an die Lastgrenze getrieben, was mich dazu zwang, Optimierungen vorzunehmen.<\/p>\n
1. Bisher habe ich mich immer davon fern gehalten, diese Funktionen zu nutzen, einfach weil ich keine Veranlassung dazu sah. Warum schreibende Zugriffe verz\u00f6gern, wenn sie doch auch unmittelbar vollzogen werden k\u00f6nnen? Die Tatsache, dass mehrere hunderte gleichzeitiger Zugriffe sich gegenseitig behinderten, brachte mich dazu, meine Denkweise zu \u00fcberdenken.<\/p>\n Ich habe zwei schreibende SQL-Statements kurzerhand von “ Nat\u00fcrlich gibt es Nachteile. Erstens sind die geschriebenen Daten nicht unmittelbar abrufbar, zweitens gehen diese unweigerlich verloren, sofern der MySQL-Server unsauber beendet wird, bevor die Queries auf Platte geschrieben werden konnten.<\/p>\n Die Vorteile \u00fcberwiegen jedoch, denn ich konnte damit die Serverlast unglaublich reduzieren. Es sollte allerdings wohl \u00fcberlegt werden, welche Statements man verz\u00f6gert schreiben l\u00e4sst.<\/p>\n 2. Die sinnvolle Verwendung von Indizes<\/strong><\/p>\n Eine weitere Optimierung, zu der ich mich gezwungen sah, war der Einsatz von Indizes in MySQL-Tabellen. Dauert die Verarbeitung eines SQL-Queries sehr lang, weil unheimlich viele Daten analysiert werden m\u00fcssen, so bietet sich der Einsatz eines Index’ durchaus an. Beispiel:<\/p>\n Im obigen Beispiel dauert die Abfrage exakt 5 Sekunden, was f\u00fcr eine Webanwendung unbrauchbar lang ist. Mit MySQL-Boardmitteln kann man sich anschauen, warum die Abfrage so lange dauert:<\/p>\n Man erkennt, dass zwei Tabellen durchsucht werden. F\u00fcr die erste Tabelle wird ein Key verwendet, f\u00fcr die zweite Tabelle jedoch nicht. Aus diesem Grund liefert die Abfrage der ersten Tabelle auch nur genau ein Ergebnis zur\u00fcck, w\u00e4hrend in der zweiten Tabelle noch\u00a0831752 Ergebnisse auf den Besser geht es mit dem Einsatz eines Indizes im entsprechenden Tabellen-Feld, welches vom Das gleiche Sofort ist erkennbar, dass in der zweiten Tabelle nur noch 55 Ergebnisse mittels der Auch bei Indizes ist Vorsicht geboten. Zu grosse oder falsche Indizes k\u00f6nnen die Datenbank unter Umst\u00e4nden nicht nur unn\u00f6tig gross, sondern auch langsamer machen.<\/p>\nINSERT DELAYED<\/code> und UPDATE LOW_PRIORITY<\/code><\/strong><\/p>\nINSERT INTO TABLE<\/em>...<\/code>” in “INSERT DELAYED INTO TABLE<\/em>...<\/code>” bzw. “UPDATE TABLE<\/em>...<\/code>” in “UPDATE LOW_PRIORITY TABLE<\/em>...<\/code>” umgeschrieben.<\/p>\nSELECT COUNT(wa_sessions.ID) AS Sessions\r\nFROM wa_sessions, wa_sites\r\nWHERE wa_sites.site_name = 'foo'\r\nAND wa_sites.ID = wa_sessions.site_id\r\nAND wa_sessions.begin\r\nBETWEEN NOW() - INTERVAL 5 MINUTE\r\nAND NOW() - INTERVAL 0 MINUTE;\r\n+----------+\r\n| Sessions |\r\n+----------+\r\n| \u00a0 \u00a0 \u00a0 20 |\r\n+----------+\r\n\r\n1 row in set (5.00 sec)<\/pre>\n
EXPLAIN SELECT COUNT(wa_sessions.ID) AS Sessions\r\nFROM wa_sessions, wa_sites\r\nWHERE wa_sites.site_name = 'foo'\r\nAND wa_sites.ID = wa_sessions.site_id\r\nAND wa_sessions.begin\r\nBETWEEN NOW() - INTERVAL 5 MINUTE\r\nAND NOW() - INTERVAL 0 MINUTE\\G\r\n*************************** 1. row ***************************\r\nid: 1\r\nselect_type: SIMPLE\r\ntable: wa_sites\r\ntype: ref\r\npossible_keys: PRIMARY,site_sites\r\nkey: site_sites\r\nkey_len: 35\r\nref: const\r\nrows: 1\r\nExtra: Using where\r\n*************************** 2. row ***************************\r\nid: 1\r\nselect_type: SIMPLE\r\ntable: wa_sessions\r\ntype: ALL\r\npossible_keys: NULL\r\nkey: NULL\r\nkey_len: NULL\r\nref: NULL\r\nrows: 831752\r\nExtra: Using where\r\n2 rows in set (0.00 sec)<\/pre>\n
WHERE<\/code>-Teil hin \u00fcberpr\u00fcft werden m\u00fcssen. Das dauert nat\u00fcrlich eine Weile.<\/p>\nWHERE<\/code>-Teil abgefragt wird:<\/p>\nCREATE INDEX session_begin ON wa_sessions (begin(18));\r\nQuery OK, 831761 rows affected (34.52 sec)<\/pre>\n
EXPLAIN SELECT<\/code> Statement von gerade eben zeigt, dass nun auch in der zweiten Tabelle ein Key verwendet wird:<\/p>\nEXPLAIN SELECT COUNT(wa_sessions.ID) AS Sessions\r\nFROM wa_sessions, wa_sites\r\nWHERE wa_sites.site_name = 'foo'\r\nAND wa_sites.ID = wa_sessions.site_id\r\nAND wa_sessions.begin\r\nBETWEEN NOW() - INTERVAL 5 MINUTE\r\nAND NOW() - INTERVAL 0 MINUTE \\G\r\n\r\n*************************** 1. row ***************************\r\nid: 1\r\nselect_type: SIMPLE\r\ntable: wa_sites\r\ntype: ref\r\npossible_keys: PRIMARY,site_sites\r\nkey: site_sites\r\nkey_len: 35\r\nref: const\r\nrows: 1\r\nExtra: Using where\r\n*************************** 2. row ***************************\r\nid: 1\r\nselect_type: SIMPLE\r\ntable: wa_sessions\r\ntype: range\r\npossible_keys: session_begin\r\nkey: session_begin\r\nkey_len: 21\r\nref: NULL\r\nrows: 55\r\nExtra: Using where\r\n2 rows in set (0.00 sec)<\/pre>\n
WHERE<\/code>-Abfrage analysiert werden m\u00fcssen. Die meisten der weit \u00fcber 800.000 Ergebnisse in der zweiten Tabelle wurden durch das reine Vorhandensein des Indizes bereits ausgeschlossen. Und das SQL-Statement ist damit volle 5 Sekunden schneller:<\/p>\nSELECT COUNT(wa_sessions.ID) AS Sessions\r\nFROM wa_sessions, wa_sites\r\nWHERE wa_sites.site_name = 'foo'\r\nAND wa_sites.ID = wa_sessions.site_id\r\nAND wa_sessions.begin\r\nBETWEEN NOW() - INTERVAL 5 MINUTE\r\nAND NOW() - INTERVAL 0 MINUTE;\r\n\r\n+----------+\r\n| Sessions |\r\n+----------+\r\n| \u00a0 \u00a0 \u00a0 12 |\r\n+----------+\r\n1 row in set (0.00 sec)<\/pre>\n