== Quote from Jason (jwcarlton@gmail.com)'s article
> I'm relatively new to databases, and have read a lot of tutorials
> lately, but the more I learn, the more I realize that I haven't
> learned anything yet! LOL
> I've converted a message board from using plain text files to using
> MySQL. Per some excellent suggestions on here, I have it set up as 2
> tables:
> subjects
> posts
> The "subjects" table acts as a cross-reference, holding the ID#,
> subject name, and last modified date, and currently has 17000 rows of
> data. The "posts" table holds all of the posts, which is about 600,000
> rows of data.
> My problem is SPEED. I would swear that the new MySQL format is slower
> than the old text format! LOL I'm sure that there's some code that
> can be optimized, but that's really more appropriate for a Perl ng.
> Here's my question for you guys. If I understand the concept of an
> index, it basically takes the first few characters of a table and adds
> it to a separate table that can be searched more quickly because of
> the lower amount of data, and then that table cross-references the
> "real" table. Is that pretty much the gist of it? That's what I
> gathered from the MySQL documentation, although it left me with my
> head spinning.
> If so, how can using an index would help me, when the search is by a
> unique ID#? Is there another way to make it find the ID more quickly
> than by sorting through 17000+ rows to find the one that matches?
> TIA,
> Jason
an index makes searches a lot faster. if a record is in the bottom of your table,
an indexed search will find the record by reading one row whereas an unindexed
search will have to scan the whole table to find the record.
--
POST BY: lark with PHP News Reader