Mailinglisten-Archive |
Wir haben das Problem, dass mehrere verschiedene Abfragen mehrfach hintereinander abgeschickt werden mit minimalen Aenderungen von Konstanten. Dabei haben wir ueber zwei Spalten in zwei verschiedenen Tabellen keinen Index gelegt, da dies als nicht relevant erachtet worden ist. Jetzt haben wir das Problem, dass die Performance eingebrochen (teilweise bis zu 20min) ist. Bei der Suche sind wir auf diese Spalten gestossen und haben einfach mal einen zusaetzlichen Index ueber die relevante Spalte einer teuren Abfrage gelegt. Dabei ist die Performance weiter zusaetzlich eingebrochen. Danach wurde zusaetzlich ueber die andere Spalte einer Tabelle ein Index gelegt, der eigentlich bei den ganz teueren Abfragen nicht benutzt wird. Dabei haben wir dann Laufzeiten (noch mal es sind viele Abfragen in Summe) von akzeptablen 3.30min erreicht. Wenn man jetzt die beiden Indizes wieder wegnimmt oder nur den auf der relevanten Spalte belaesst, so erhaelt man die selben 3.30min, die man vorher nur mit zwei Indizes erreicht hat auch ohne Indizes. Mein Vermutung, dass die Ablaufplaene aufgrund der neuen Indizes optimiert worden sind, und danach auch ohne schneller liefen, da sie vielleicht im Cache waren, laesst sich so einfach nicht bestaetigen, da auch ein Server Neustart die selben 3.30 gebracht haben. Deshalb kurz ein paar Fragen, weil wir das Problem verstehen wollen: 1. Werden die Ablaufplaene gecached? 2. Wenn ja auch ueber einen Server Neustart hinaus? 3. Koennte es einen anderen relevanten Grund fuer dieses Verhalten geben? MySQL: mysql-nt als Service in der Version 3.23.58-nt unter XP tschau -- Jan Kuehl -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive