They most certainly do depend on the table design and especially on the
system which runs the test.
They are my own figures...
> Daniel Åkerud wrote:
> > In MySQL having a table that looks like this:
> >
> > idint primary key
> > namechar(200)
> >
> > and making an index on name, will ge
Daniel Åkerud wrote:
> In MySQL having a table that looks like this:
>
> idint primary key
> namechar(200)
>
> and making an index on name, will get you a 0.1 * original_retrieval_time
> when searching, but 1.5*original_insertion_time when inserting. It roughly
> means that (on my system
An index is not just putting the data in a separate file. It's about storing
information in more "high-tech" data structures like B-trees, R-trees and
hashes. MySQL only support B-Trees, which is the most commonly used. B-Trees
are about storing data in a tree-like structure for very fast retriev
Hello.
On Sat, Jun 23, 2001 at 01:01:41AM +0020, [EMAIL PROTECTED] wrote:
> I understand that indexes work so fast because they are usually smaller than the
> original table, since they contain on average just 1 column, or at least less
> information than the complete table. But how about a tab
Quoting Cal Evans <[EMAIL PROTECTED]>:
> Regular keys are just indexes, not necessarily unique, not necessarily on
> fields that don't accept nulls. Their primary function is to speed up data
> retrieval. Use them sparingly as they can have a negative impact on
> inserting and updating records.
Friday, June 22, 2001 6:27 PM
Subject: Re: KEY and index
> KEY is used to build other indexes. It's not short for Primary Key.
There
> are PRIMARY KEY indexes, candidate key indexes (these COULD be a primary
key
> but for one reason or another , are not) and just regular indexes.
&g
KEY is used to build other indexes. It's not short for Primary Key. There
are PRIMARY KEY indexes, candidate key indexes (these COULD be a primary key
but for one reason or another , are not) and just regular indexes.
All tables should have a primary key. (I'm partial to adding an
auto_incremen
