toby: Mysql

hi.
hab ne tabelle, die eigentlich nur die beziehung zwischen den inhalten von 2 andren tabellen festlegt.
so hat sie auch nur 2 felder, das eine bezieht sich auf die id des ausgangsobjekts aus tab1 und das 2. feld hat die id des bezugobjekts aus tab2. es werden voraussichtlich eine 0,5 bis 1,5 mio solcher einträge erstellt. beide felder sind vom typ int(20). nun darf kein datensatz identisch sein. daher habe ich einen unique index über beide felder (gleichzeitig, nicht: jeweils) gesetzt.
ist das richtig so oder empfiehlt sich ein anderer index.
bei select/abfragen wird immer nur das erste der beiden felder im WHERE klausel stehen. das andere kommt nur selten vor.
wenn beide zugriffe schnell gehen, wärs gut; wenn mans auf das eine feld beschränken kann, wärs auch gut...
Eure tipps, bitte.
danke schonmal

  1. Hallo

    hab ne tabelle, die eigentlich nur die beziehung zwischen den inhalten von 2 andren tabellen festlegt.
    nun darf kein datensatz identisch sein. daher habe ich einen unique index über beide felder (gleichzeitig, nicht: jeweils) gesetzt.
    bei select/abfragen wird immer nur das erste der beiden felder im WHERE klausel stehen. das andere kommt nur selten vor.

    Da es vorkommen kann, könnte es dennoch empfehlenswert sein, einen weiteren Index auf die zweite Spalte zu setzen. Dieser kostet halt etwas Platz und Einfüge- und Löschoperationen werden etwas langsamer. Bei der Anzahl Deiner Datensätze ist es somit eine Frage wieviele Einfüge- und Löschoperationen es im Vergleich zu den Leseoperationen, die enorm beschleunigt werden können, gibt.

    Freundliche Grüße

    Vinzenz

    1. gelesen/abgefragt wird in mehr als 95% der zugriffe. das hinzufügen/löschen ist eher selten. aber wozu dient der 3. index, wenn ohnehin jeder DS einmalig und sich in seinen werten von den andren unterscheidet? ich hätte keine verwendung dafür, z.b. anhand dieser zusätzlichen ID den DS zu löschen. geupdatet wird er auch nicht, sondern bei veränderung gelöscht und evt. geändert neu erstellt, wenn nötig.
      aber aus dem grund frag ich ja. was ist der verwendungszweck/vorteil einer 3. spalte?

      1. Hallo toby,

        gelesen/abgefragt wird in mehr als 95% der zugriffe. das hinzufügen/löschen ist eher selten. aber wozu dient der 3. index,

        ich rede von einem zweiten Index, nicht von einem dritten :-)

        Du hast einen kombinierten Index über Spalte 1 und Spalte 2. Die MySQL-Doku erzählt Dir, warum Du deswegen für Spalte 1 keinen gesonderten Index benötigst. Kann jedoch ein Index auf Spalte 2 eine Abfrage beschleunigen, so kann der kombinierte Index _nicht_ genutzt werden. Insofern deckst Du mit dem kombinierten Index und einem Index auf Spalte 2 den maximalen Bedarf ab.

        Freundliche Grüße

        Vinzenz

  2. yo,

    ganz offensichtlich handelt es sich dabei um eine n:m beziehungstabelle. mein vorschlag, lass mal den kombinierten unique index über die beiden spalten weg und mach daraus einen primärschlüssel. den NULL werte sollen ja schließlich auch ausgeschlossen werden. dann noch ein index über die andere spalte, die im primärschlüssel als zweites angeführt wird, so wie Vinzenz sagte und dann passt das schon.

    Ilja