or ORDER BY clauses, you might benefit from indexing. The flip side is that
UPDATEs, INSERTs and DELETEs that affect indexed fields run slower, because
they don't have to just change the data, they also have to mess with the
index.
I usually start with indexes on the primary key and foreign keys (which you
can't avoid) and then ignore the rest of the fields until I start finding
bottlenecks. Occasionally I find them during development, but it's usually
during QA and load testing where they start to appear. It also helps to
have the queries written first, before you add indexes, because you can see
how the fields are actually used, rather than the guesses you have to make
before they're written.
Cheers,
barneyb
> -----Original Message-----
> From: brobborb [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 06, 2004 1:10 PM
> To: CF-Talk
> Subject: Re: SQL Query
>
> Yes, indexing helps a wholebunch! But how does one practice
> indexing correctly? Which fields should be indexed? Right
> now, all the identity fields are indexed. Was wondering if
> there is aything else that should be index
> ----- Original Message -----
> From: Tony Weeg
> To: CF-Talk
> Sent: Tuesday, April 06, 2004 3:03 PM
> Subject: RE: SQL Query
>
>
> if correctly indexed, none.
>
> I have a table that is 1.57 millions rows, we index on an
> integer field, and
> I can return to a cf page, a recordset with 100+ rows in
> milliseconds
>
> its all about the indexing.
>
> tw
>
> -----Original Message-----
> From: brobborb [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 06, 2004 3:38 PM
> To: CF-Talk
> Subject: SOT: SQL Query
>
> hey guys, what do u think the performance difference is in
> MS SQL Server
> 2000....
>
> Querying from a table of 500,000 rows or querying from a
> table of 1 million
> rows?
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
