phpbar.de logo

Mailinglisten-Archive

[php] Verhalten von php bei langandauernden SQL-befehlen

[php] Verhalten von php bei langandauernden SQL-befehlen

Andreas Ahlenstorf lists at ahlenstorf.ch
Mon Jan 17 14:39:03 CET 2005


Christoph Kramesch - I.D. Solutions schrieb:
> Die Locks werden implizit gesetzt, wenn ich über mysqladmin
> mir die processlist ausgeben lasse erscheint etwas wie
> (gekürzte Version)
>
> Command | Time  |State                 | Info          |
> +-------+-------+----------------------+-------------
>  Query  | 53201 | Copying to tmp table | SELECT * FROM table1  LEFT JOIN
> ... |
>  Query  | 8485  | Locked               | UPDATE table1 SET name='....
> 
> Anhand dieser Information NEHME ICH AN (ich weiß, glauben heißt nichts
> wissen ;) ),
> daß das 2. Query anhand eines implizit gesetzten Readlocks des
> 1. Queries gesperrt ist, da im Script selbst explizit keine Locks
> gesetzt werden.

Gut, dein Problem sind die schreibenden Operationen. Für schreibende
Operationen braucht MyISAM einen Table Lock. Das ist bei sehr lang
dauernden/häufig ausgeführten Operationen mit vielen lesenden
Zugriffen und grossen Indices tödlich. Deine Möglichkeiten sind sehr
begrenzt:

- Prozesse optimieren, damit du *viel* weniger schreiben musst und
diese schreibenden Operationen viel schneller ablaufen.
- Daten auf mehrere Tabellen verteilen, so dass nur auf einen Teil
des Datenbestands ein Lock gesetzt wird.

Ziel für dich müssen > 90% lesende zu < 10% schreibende Operationen
sein. Dabei müssen die schreibenden Operationen möglichst schnell
ausgeführt werden, sonst musst du die Anzahl schreibender
Operationen noch weiter senken.

> Innodb kann ichnicht setzen weil bei der Config
> have_innodb auf NO gesetzt ist.

Wenn du die oben aufgezeigten Möglichkeiten nicht hast, musst du
dafür sorgen, dass du InnoDB mit ein paar möglichst grossen Buffers
kriegst.

Gruss,
Andreas

php::bar PHP Wiki   -   Listenarchive