Mailinglisten-Archive |
> hmm, hab ich mir bisher keine Angaben drüber gemacht. Welche > Alternative zu Count(*) gibt es denn bei komplexen Abfragen (für > die es ja laut Handbuch nicht optimiert ist)? > ... > Was anderes fällt mir nicht ein. > nochmal hallo, zuerst muß ich mich selbst korrigieren. Meine Äußerung bzgl. count(*) galt (wie auch im Handbuch-Auszug genannt) nur für einfache Abfragen. Hilft Dir also nicht. Ich vermute, daß Deine Abfrage diverse Joins enthält. Für MySql und hat Peter Blancke mit "LIMIT 1" schon das einzige genannt, was mir auch dazu einfällt. Im Falle von Limit kann man sich getrost auf eine Spalte (anstatt *) einschränken. Weiterhin sollte man Distinct/Order By/Group By weglassen. Außerdem solltest Du das Select-statement natürlich weitestgehend optimieren. Wenn der optimizer von MySql einen im Stich läßt (festzustellen mit EXPLAIN), dann kann man bei komplexen Statements seit den neueren Versionen (3.23.12) auch nachhelfen. Mit USE INDEX kann man MySql einen Wink mit dem Zaunpfahl geben welchen Index es (verdammt noch mal) zu verwenden hat. Leider läßt MySql keine Subselects zu sonst hätte man auf andere Weise die Möglichkeit dem optimizer sein Ansinnen kenntlich zu machen. Das geht daher leider nicht: Z.B.: SELECT 1 from <tabelle mit einem satz> WHERE EXISTS(<Dein select statement>) > >Ist kein einziger Satz in der Tabelle erhältst Du allerdings (soweit ich > >weiß) NULL als Ergebnis und nicht 0. > > Ich möchte ja nicht widersprechen aber ich teste count(*) schon > immer auf 0 und es klappt gut :) > Natürlich hast Du recht. Ich hatte an min()/max()... gedacht und nicht an count() cu, Michael Donning --- *** Weitere Infos zur Mailingliste und MySQL unter http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive