MySQL 5 und InnoDB

MySQL rechnet definitiv schneller als PHP, das hast du richtig gehört. Sämtliche Aufgaben die von der DB erledigt werden können sollte man auch ihr überlassen.
Deine Stored Procedures sind so lange aktiv wie du sie nicht wieder löschst (wie auch deine Tabellen). Die müssen nach einem Serverneustart nicht neu angelegt werden.

Für regelmäßige Skript-Aufrufe sind nunmal Cronjobs gedacht. Wieso willst du die nicht nutzen?
Ich wüßte spontan keine Alternative um SQL-Scripts regelmäßig laufen zu lassen, außer den Sachen die du ausschließen möchtest.

Zu den Engines:
In Punkto Transaktionen ist zur Zeit InnoDB am stabilsten und am besten integriert. Bietet auch Row-Level-Locking wenn ein Mix aus Operationen nebenläufig ausgeführt werden muss.
Für Tabellen auf die hauptsächlich SELECTs und INSERTs ausgeführt werden ist MyISAM eine gute Wahl.
Heap (Memory-Engine) sollte nur für Tabellen verwendet werden, deren Inhalte sich nicht ändern (z.B. PLZ-Lookups) oder bei denen es egal ist wenn die Inhalte bei einem Server-Neustart verloren gehen. Die Tabellenstruktur bleibt beim Neustart erhalten, aber die Daten sind weg und müssen danach eben neu eingespielt werden. Heap bietet keine Text-/Blob-Felder und unterstützt nur Zeilen fester Größe. Man muss also beispielsweise statt VARCHAR dann CHAR verwenden, was je nach Inhalten eine gewisse Speicherverschwendung darstellt.
Bevor du dich für eine Engine entscheidest solltest du dir auf jedenfall über die Tabellenstrukturen im Klaren sein und wie diese Tabellen verwendet werden.

Wichtig ist für die Performance auch das vernünftige setzen von Indices, große Tabellen zu partitionieren kann auch viel ausmachen.
Dann halt noch so Kleinigkeiten wie richtige Wahl der Feldtypen, z.B. die SQL-Feldtypen zur Speicherung von Zeit und Datum verwenden, für Strings die immer eine (nahezu) gleiche Länge haben Feldtyp CHAR statt VARCHAR verwenden, keine NULL-Werte erlauben (es sei denn sie werden wirklich explizit benötigt, sonst lieber leeren String oder 0 speichern).
Kann sich auch alles noch läppern.

Viele Leute erlauben bei Tabellenfeldern wenn nicht zwingend etwas darin stehen muss auch NULL-Werte.
Wenn man für Felder NULL-Werte erlaubt verlangsamt das aber Abfragen auf diese Tabelle. Deswegen soll lieber ein leerer String oder bei INT-Feldern eine 0 gespeichert werden und die Tabellenfelder als NOT NULL deklariert werden. NULL-Werte sollten nur erlaubt werden wenn sie wirklich nötig sind, wenn es also einen Unterschied zwischen einem leeren String (bzw. einer 0) und einem NULL-Wert gibt.

Edit:
Ich zitiere grad mal noch den entsprechenden Ausschnitt aus dem Buch "High Performance MySQL" (übrigens sehr empfehlenswert, http://www.amazon.de/Performance-Op…88691065&sr=8-2 )

Zitat

[...]
Es ist für MySQL schwieriger, Abfragen zu optimieren, die sich auf Nullable-Spalten beziehen, weil diese die Vergleiche von Indizes, Indexstatistiken und Werten deutlich komplizierter machen. Eine Nullable-Spalte belegt mehr Speicherplatz und erfordert in MySQL eine spezielle Verarbeitung. Wenn eine Nullable-Spalte indiziert wird, braucht sie pro Eintrag ein zusätzliches Byte und kann in MyISAM sogar dafür sorgen, dass ein Index fester Größe (wie etwa der Index einer Single-Integer-Spalte) in einen Index variabler Größe konvertiert wird.
Selbst wenn Sie die Tatsache eines "kein Wert" in einer Tabelle speichern müssen, müssen Sie nicht unbedingt NULL verwenden. Nehmen Sie stattdessen lieber Null, einen speziellen Wert oder einen leeren String.

Zitat von SinnlosS

MySQL rechnet definitiv schneller als PHP, das hast du richtig gehört. Sämtliche Aufgaben die von der DB erledigt werden können sollte man auch ihr überlassen.

Hast du da einen Beweis für? MySQL ist gut im Abfragen-in-Index-Struktur optimieren, aber um irgendwelche Sachen auszurechnen, etwa die Summe von Zahlen, insbesondere, wenn die Queries jedes Mal neu ausgewertet und optimiert werden müssen? Ich wäre mit so einer Aussage etwas vorsichtiger, die extensive Benutzung von stored procodures kann jedoch dafür die Konsistenz der Datenbank sichern, zudem spart man sich schonmal das hin-und-her zwischen PHP und MySQL…

Gegenfrage, hast du mal ein Beispiel wo PHP schneller als SQL ist in Dingen, die von SQL simpel zu erledigen sind?
COUNT() ist schneller als die Ergebnismenge komplett zu selektieren und dann in PHP mit num_rows zu zählen.
SUM() ist zugegebnermaßen nur gleich schnell wie die Zahlen alle auszulesen und in PHP aufzuaddieren. Langsamer als PHP ist es aber definitiv auch nicht.
Datumsberechnungen und -umformungen mit den SQL-eigenen Feldtypen sind wesentlich schneller über die DB, als wenn man diese in PHP vornimmt.
Über das Filtern der Ergebnismenge mit SQL gegenüber dem Auslesen größerer Datenbestände als benötigt und anschließender Filterung in PHP brauchen wir wohl gar nicht erst reden.

Mir fällt gerade wirklich kein Beispiel ein, dass sich in angemessener Form sowohl über DB als auch über PHP regeln ließe und in dem PHP schneller wäre als SQL.
Aber du darfst mir gerne welche nennen, ich bin selbstverständlich auch nicht allwissend.

Zitat von Pion

Datenbanken werden bei großen Aufkommen ziemliche Krücken, im direkten Vergleich sind elementare Berechnungen natürlich schneller.. (ein paar Ausnahmen wie zb "uuid" gibts sicherlich)

Hm, und PHP skaliert in Sachen Performance besser bei großen Aufkommen, so dass ab einem bestimmten Grad dann PHP schneller ist? Hast du da Quellen wo das genauer erläutert wird? Würde mich interessieren, habe ich noch nie gehört.

Will mich Sinnloss anschließen (gerade weil es nicht Sinnlos ist ). Habe schon Portale aufgesetzt bei denen es ohne MySQL zu deutlichen Performanceeinbußen gekommen wäre. Bei kleinen Webseiten mit Kontaktformularen die in der DB gespeichert werden merkt man das nicht mal wirklich. Da sind die Unterschiede marginal. Aber wenn es um komplexe Abfragen und Berechnungen geht nutze ich immer MySQL. Besonders wenn die Zugrunde liegenden Daten schon in der DB stehen. Bei manchen Webservern ist es auch von Vorteil MySQL für Preisberechnungen zu nutzen, da php in seiner Standard-Installation zu Rundungsfehlern neigt (float-Problem) was enorme Einbußen bei Shop-Preisberechnungen nach sich ziehen kann (um das zu umgehen gibt es das Modul für mathematische Funktionen in php, aber ist nicht immer auch installiert).