Ergänzend zu den Flames der anderen kann ich dazu sagen, dass es für eine Datenbank nicht immer effizient ist, den Index zu nutzen. Beispiel 1: Wenn der Index, der die tableId enthält, kein Clustered Index (PRIMARY KEY in InnoDB) ist, dann ist die physikalische Reihenfolge der Sätze in der Table nicht zwingend identisch mit der ID-Reihenfolge, und wenn man dann in Indexreihenfolge liest, muss der Server in der Table-Datei hin- und herspringen. Falls Du MyISAM nutzt: Da gibt es keine Clustered Indexe. Beispiel 2: Wenn deine Where-Bedingung Felder außerhalb des Index abfragt, muss ohnehin die ganze Table durchgelesen werden. Dann nützt der Index nichts. Für genauere Antworten braucht es - wie schon von anderen gesagt, mehr Informationen. Table+Index Design, Database Engine, Query. Rolf

Ergänzend zu den Flames der anderen kann ich dazu sagen, dass es für eine Datenbank nicht immer effizient ist, den Index zu nutzen. Beispiel 1: Wenn der Index, der die tableId enthält, kein Clustered Index (PRIMARY KEY in InnoDB) ist, dann ist die physikalische Reihenfolge der Sätze in der Table nicht zwingend identisch mit der ID-Reihenfolge, und wenn man dann in Indexreihenfolge liest, muss der Server in der Table-Datei hin- und herspringen. Falls Du MyISAM nutzt: Da gibt es keine Clustered Indexe. Beispiel 2: Wenn deine Where-Bedingung Felder außerhalb des Index abfragt und die Query kein ORDER BY tableId enthält, muss ohnehin die ganze Table durchgelesen werden. Für genauere Antworten braucht es - wie schon von anderen gesagt, mehr Informationen. Table+Index Design, Database Engine, Query. Rolf