Hi!
While this is not a MySQL mailing list, I try to give you some hints and
keep it short.
There is maybe one important thing which should considered: clustered
index. If use InnoDB you can think about to not using a surrogate key
but a natural one which best support the query which you will
>> Point above about spread still applies, but if you
>> can join index to index, the join goes a lot faster. (A primary key in
>> MySQL
>> is always indexed.)
>>
> How much is the *a lot*? Thanks. :)
If it's a unique (including primary) key then orders of magnitude for
millions of rows.
If it'
On Thu, May 1, 2008 at 9:54 AM, Larry Garfield <[EMAIL PROTECTED]>
wrote:
> On Wednesday 30 April 2008, Chris wrote:
> > >> Index on most integer fields only. Text fields can be indexed, but is
> > >> not important when you design your DB well.
> > >>
> > >> Don't index just all integer fields. Ke
On Wed, Apr 30, 2008 at 7:03 PM, Aschwin Wesselius <[EMAIL PROTECTED]>
wrote:
> Shelley wrote:
>
> Don't index just all integer fields. Keep track of the cardinality of a
> column. If you expect a field to have 100.000 records, but with only 500
> distinct values it has no use to put an index on
On Wednesday 30 April 2008, Chris wrote:
> >> Index on most integer fields only. Text fields can be indexed, but is
> >> not important when you design your DB well.
> >>
> >> Don't index just all integer fields. Keep track of the cardinality of a
> >> column. If you expect a field to have 100.000 r
>> Index on most integer fields only. Text fields can be indexed, but is not
>> important when you design your DB well.
>>
>> Don't index just all integer fields. Keep track of the cardinality of a
>> column. If you expect a field to have 100.000 records, but with only 500
>> distinct values it ha
On Wed, 2008-04-30 at 11:14 +0200, Aschwin Wesselius wrote:
> Shelley wrote:
> > Hi all,
> >
> > I am currently responsible for a subscription module and need to design the
> > DB tables and write code.
> >
> > I have described my table design and queries in the post:
> > http://phparch.cn/index.p
Shelley wrote:
Don't index just all integer fields. Keep track of the cardinality of a
column. If you expect a field to have 100.000 records, but with only 500
distinct values it has no use to put an index on that column. A full record
search is quicker.
Hmmm... That's new. :)
Well,
On Wed, Apr 30, 2008 at 5:14 PM, Aschwin Wesselius <[EMAIL PROTECTED]>
wrote:
> Shelley wrote:
>
> > Hi all,
> >
> > I am currently responsible for a subscription module and need to design
> > the
> > DB tables and write code.
> >
> > I have described my table design and queries in the post:
> >
>
Shelley wrote:
Hi all,
I am currently responsible for a subscription module and need to design the
DB tables and write code.
I have described my table design and queries in the post:
http://phparch.cn/index.php/mysql/38-MySQL-configuration/152-best-practices-for-using-mysql-index
The problem i
Hi all,
I am currently responsible for a subscription module and need to design the
DB tables and write code.
I have described my table design and queries in the post:
http://phparch.cn/index.php/mysql/38-MySQL-configuration/152-best-practices-for-using-mysql-index
The problem is, in a short tim
11 matches
Mail list logo
