Hallo, der phpMyAdmin warnt immer:
"Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die
Spalte gesetzt sein."
Aber wiso?
da ich eine Tabelle habe wo:
firma, kw, type
PK auf firma, kw (um keine doppelten kw pro firma zu haben)
index firma
index kw
die einzelnen indexe senken die Suchgeschwindigkeit von 3sec auf 0,0003sec.
MFG Heiko
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
"Heiko (GreenRover) Henning"
> "Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die=20
> Spalte gesetzt sein."
> Aber wiso?
Weil es keinen Zugewinn bringt (da eh nur einer der Indizes genutzt werden
kann), aber Updates teurer werden (es muessen ja zwei Indizes statt einem
geupdated werden).
> da ich eine Tabelle habe wo:
> firma, kw, type
> PK auf firma, kw (um keine doppelten kw pro firma zu haben)
> index firma
> index kw
> die einzelnen indexe senken die Suchgeschwindigkeit von 3sec auf 0,0003s=
ec.
Wenn Du aber den Index auf firma loescht, ist noch alles genauso schnell.
Heiko (GreenRover) Henning wrote:
> Hallo, der phpMyAdmin warnt immer:
> "Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die
> Spalte gesetzt sein."
>
> Aber wiso?
>
> da ich eine Tabelle habe wo:
> firma, kw, type
>
> PK auf firma, kw (um keine doppelten kw pro firma zu haben)
> index firma
> index kw
Ein Index über `firma` ist im Index über (`firma`, `kw`) bereits
enthalten - Stichwort Präfix. Dass du ihn ein weiteres mal anlegst,
kostet bloß Arbeitsspeicher, Festplattenspeicher und Aufwand beim
Erstellen und Ändern von Datensätzen. In diesem Fall hat phpMyAdmin Recht.
> die einzelnen indexe senken die Suchgeschwindigkeit von 3sec auf 0,0003sec.
Mach' den über `firma` weg und das bleibt so.
Grüße
Kai
--
This signature is left as an exercise for the reader.
Andreas Kretschmer
>> "Die Index-Typen INDEX und PRIMARY sollten nicht gleichzeitig für die=
=20
>> Spalte gesetzt sein."
>> Aber wiso?
> Genau. MySQL kann eh nur einen Index pro table und select nutzen.
Stimmt nur fuer MySQL < 5.0.
Beispiel:
mysql> show create table miau \G
*************************** 1. row ***************************
Table: miau
Create Table: CREATE TABLE `miau` (
`a` int(11) default NULL,
`b` int(11) default NULL,
KEY `a` (`a`),
KEY `b` (`b`)
) ENGINE=3DMyISAM DEFAULT CHARSET=3Dlatin1
1 row in set (0.00 sec)
mysql> explain select count(*) from miau where a =3D 1 or b =3D 1 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: miau
type: index_merge
possible_keys: a,b
key: a,b
key_len: 5,5
ref: NULL
rows: 2
Extra: Using union(a,b); Using where
1 row in set (0.01 sec)
mysql> show variables like 'version';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| version | 5.0.32-Debian_7etch1-log |=20
+---------------+--------------------------+
1 row in set (0.00 sec)
Kai Ruhnau schrieb:
> Mach' den über `firma` weg und das bleibt so.
Ja, das ist so.
Ich habe jetzt den PK gegen einen uiniqu ersetzt.
Die einzelnden indexe bringen es bei dieser suche, jedoch der über
beide, soll halt dafür sorgen, das das ganze auch UNIQUE bleibt.
Sven Paulus schrieb:
> Wenn Du aber den Index auf firma loescht, ist noch alles genauso schnell.
das heisst, wenn ich
einen index auf kw habe und einen unique über firma, kw
dann kann ich mir den index für firma spaaren?
MFG Heiko?
"Heiko (GreenRover) Henning"
> > Wenn Du aber den Index auf firma loescht, ist noch alles genauso schn=
ell.
> das heisst, wenn ich
> einen index auf kw habe und einen unique über firma, kw
> dann kann ich mir den index für firma spaaren?
Ja, weil der Index ueber "firma, kw" bereits einen Index ueber "firma"
beinhaltet.