> I'm using mysql in enviroment where database size is important as well =
> as data access speed.
> The first problem I found with storing BIT MAPPED data. Classic indexes =
> are build comparing values so they can't help much when sear=F1hing =
> vaules with some bits up ore down. For this special bit indexes would =
> really help. Well second thing is about strings. Huge strings (TEXT) can =
> not be indexed yet and so I had to use hash with index on it - this =
> perfomes really good and the index size is really small comparetively =
> string indexes. This type of indexes will also be good then indexing =
> varchar and char colomns as prefix indexes sometimes cannot help as =
> there are a lot of strings with same long prefix. Of couse hash indexes =
> can't be used for sorting and comparement but often indexes are used =
> only to find a match.
> The question is - is some sort of this fings are planned in mysqls =
> future ?
We don't yet have decided how to implement BIT_MAPPED data.
The new MyISAM handles big UNIQUE internally using HASH keys.
(This was done to get DISTINCT better and much faster)
We plan to make the UNIQUE handling available at the SQL level; After
this there will not be any restrictions on the length of UNIQUE
|• Features indeed||Peter Zaitsev||27 Jul|
| • Features indeed||Michael Widenius||2 Aug|