komisches Problem mit Schlüssel

Hallo,

ich habe hier ein etwas seltsames Problem: (MySQL 4.1.10a)

In der Tabelle

CREATE TABLE `sums` (
`id` bigint(20) unsigned NOT NULL default '0',
`typ` char(10) character set ascii NOT NULL default '',
`sum` char(40) character set ascii NOT NULL default '',
`t` timestamp NOT NULL default CURRENT_TIMESTAMP on update
CURRENT_TIMESTAMP,
PRIMARY KEY (`id`,`typ`),
KEY `sum5` (`sum`(5)),
KEY `typ` (`typ`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

die etwa 300000 Zeilen umfaßt, möchte ich mir alle verschiedenen Werte
von typ anzeigen lassen. (Das sind im Endeffekt 6 Werte, nämlich 'sha1',
'md5', 'md4', 'ed2k', 'crc32' und 'adler32'.)


Mein ursprünglicher Ansatz war

select distinct typ from sums order by typ desc;

zu einer Zeit, als der Schlüssel 'typ' noch nicht existierte. Dieser
Query brauchte etwa 6-7 Sekunden. Nun dachte ich, diese Zeit etwas
verkürzen zu können, indem ich diesen Schlüssel anlege, da der
Schlöüssel ja dann die wenigen Werte direkt kennen sollte - aber dadurch
wächst die Zeit auf unglaubliche 60 Sekunden an.

Mittels "ignore key (typ)" erhalte ich wieder das alte Zeitverhalten.

explain liefert mir folgendes:

mysql> explain select distinct typ from sums ignore key (typ) order by
typ desc\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sums
type: index
possible_keys: NULL
key: PRIMARY
key_len: 18
ref: NULL
rows: 317406
Extra: Using index; Using temporary; Using filesort
1 row in set (0,00 sec)

mysql> explain select distinct typ from sums order by typ desc\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sums
type: index
possible_keys: NULL
key: typ
key_len: 10
ref: NULL
rows: 317406
Extra: Using index

Diese Ausgaben scheinen meine erste Vermutung, daß der Index günstiger
ist, zu bestärken: "Using temporary" und "Using filesort" sind weg. Die
Realität sagt mir aber was anderes (60 vs. 6 Sekunden - und ich hoffte,
mit diesem Schlüssel die Queryzeit <1s drücken zu können :-/ )

Kennt jemand eine Lösung?

Thomas
--
Wo kaemen wir den da hin, wenn jeder jedes Fup auf einen eigenen Artikel
gleich persoenlich nehmen wuerden... Oh... nach dang... :)
(Christian Wederhake in de.alt.admin)

Re: komisches Problem mit Schlüssel

Thomas Rachel wrote:

[select distinct typ from sums order by typ desc; dauert 60 Sekunden
nicht nur trotz, sondern sogar wegen passendem Key]

Hab die Lösung gefunden: wenn ich das (ohnehin nicht nötige "order by typ
desc" weglasse, komme ich auf ca. 2 Sekunden. Auch nicht gerade
berauschend, aber ein Schritt in die richtige Richtung...

Interpretation: vermutlich wird hier distinct nach order by ... desc
ausgeführt. (ich verstehe
http://dev.mysql.com/doc/refman/4.1/en/distinct-optimization .html
eigentlich so, als wäre es genau umgekehrt, da normalerweise order by ja
nach group by ausgeführt wird - oder?)

Mit einem

select typ from sums group by typ

bekomme ich ähnlich gutes Zeitverhalten, aber

select typ from sums group by typ order by typ desc;

zerhauts mir wieder - auch hier: wird order by hier nicht nach group
angewandt, so daß eigentlich nur 6 und keine 300000 Zeilen sortiert
werden müßten?


Egal. Hab ja jetzt eine halbwegs befriedigende Lösung...


Thomas
--
> Gna. Ich sollte nicht mehr aus dem Kopf zitieren, das bringt nur
> Unheil. Für sowas gibt's ja Computer ...
Für Unheil? (Thomas Hochstein und Sven Hartge in dan-an)

Re: komisches Problem mit Schlüssel

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)

Re: komisches Problem mit Schlüssel

Andreas Kretschmer wrote:

>> ich habe hier ein etwas seltsames Problem: (MySQL 4.1.10a)
>
> Damit hast Du das Problem ja schon genannt...

ja, ja.


>> zu einer Zeit, als der Schlüssel 'typ' noch nicht existierte. Dieser
>> Query brauchte etwa 6-7 Sekunden. Nun dachte ich, diese Zeit etwas
>> verkürzen zu können, indem ich diesen Schlüssel anlege, da der
>
> Nicht zwingend: ein Index ist hier möglicherweise nicht selektiv genug,
> um Sinn zu machen. Ein intelligenter Planer dürfte dies erkennen und
> daher einen Seq-Scan wählen.

Richtig - aber ich dachte, die Information, daß es nur 6 verschiedene
Einträge gibt, sei ebenfalls im Schlüssel enthalten - und ebenso, welche
das sind.

Dadurch würde nur eine Schlüssel-Abfrage nötig werden, und das Scannen
der 300000 Einträge könnte komplett unterbleiben. Naja, wohl flhcas
gedacht...


Thomas

Re: komisches Problem mit Schlüssel

Hi Thomas

Thomas Rachel wrote:
> ich habe hier ein etwas seltsames Problem: (MySQL 4.1.10a)
> In der Tabelle
> CREATE TABLE `sums` (
> `id` bigint(20) unsigned NOT NULL default '0',
> `typ` char(10) character set ascii NOT NULL default '',
> `sum` char(40) character set ascii NOT NULL default '',
> `t` timestamp NOT NULL default CURRENT_TIMESTAMP on update
> CURRENT_TIMESTAMP,
> PRIMARY KEY (`id`,`typ`),
> KEY `sum5` (`sum`(5)),
> KEY `typ` (`typ`)
> ) ENGINE=MyISAM DEFAULT CHARSET=utf8
> die etwa 300000 Zeilen umfaßt, möchte ich mir alle verschiedenen Werte
> von typ anzeigen lassen. (Das sind im Endeffekt 6 Werte, nämlich 'sha1',
> 'md5', 'md4', 'ed2k', 'crc32' und 'adler32'.)

Wieso normalisierst du nicht und legst eine neue Tabelle mit den Typen
an, die du dann referenzierst? Deine weitere Frage wird dann überflüssig.

HTH, Johannes

Re: komisches Problem mit Schlüssel

Johannes Vogel wrote:

> Wieso normalisierst du nicht und legst eine neue Tabelle mit den Typen
> an, die du dann referenzierst? Deine weitere Frage wird dann überflüssig.

Das wäre an der Stelle natürlich die Lösung. Ich hatte es hier zwar
ursprünglich als überflüssigen Overhead angesehen (mit gutem Willen könnte
man ja den kurzen String für typ bereits als eine Art ID ansehen), aber im
Prinzip hast Du recht, es wäre hier die sauberste Lösung.

Ich lasse es mir mal durch den Kopf gehen...

Danke,

Thomas