CODEWITHSUNDEEP
mysqlsqlindexing
enchance
enchance

Reputation: 30421

Right way to apply INDEX to foreign keys

I have a table with 2 foreign keys. I'm somewhat new to MySQL, can someone tell me which is the right way in applying an INDEX to tables?

# Sample 1
CREATE  TABLE IF NOT EXISTS `my_table` (
  `topic_id` INT UNSIGNED NOT NULL ,
  `course_id` INT UNSIGNED NOT NULL ,
  PRIMARY KEY (`topic_id`, `course_id`) ,
  INDEX `topic_id_idx` (`topic_id` ASC) ,
  INDEX `course_id_idx` (`course_id` ASC) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

# Sample 2
CREATE  TABLE IF NOT EXISTS `my_table` (
  `topic_id` INT UNSIGNED NOT NULL ,
  `course_id` INT UNSIGNED NOT NULL ,
  PRIMARY KEY (`topic_id`, `course_id`) ,
  INDEX `topic_id_idx` (`topic_id`, `course_id`) ,
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

I guess what I'm really asking is what's the difference between defining both as separate indexes and the other as combined?

Upvotes: 1

Views: 75

Answers (2)

Blake Taylor
Blake Taylor

Reputation: 9341

The reason why you might want one of these over the other has to do with how you plan on querying the data. Getting this determination right can be a bit of trick.

Think of the combined key in terms of, for example, looking up a student's folder in a filing cabinet, first by the student's last name, and then by their first name.

Now, in the case of the two single indexes in your example, you could imagine, in the student example, having two different sets of organized folders, one with every first name in order, and another with ever last name in order. In this case, you'll always have to work through the greatest amount of similar records, but that doesn't matter so much if you only have one name or the other anyway. In such a case, this arrangement gives you the greatest flexibility while still only maintaining indexes over two columns.

In contrast, if given both first and last name, it's a lot easier for us as humans to look up a student first by last name, then by first name (within a smaller set of potentials). However, when the last name is not known, it makes it very difficult to find the student by first name alone because the students with the same first-name are potential interleaved with every veration of last name (table scan). This is all true for the algorithms the computer uses to look up the information too.

So, as a rule of thumb, add the extra key to a single index if you are going to be filtering the data by both values at once. If at times you will have one and not the other, make sure which ever value that is, it's the leftmost key in the index. If the value could be either, you'll probably want both indexes (one of these could actually have both key for the best of both words, but even that comes at a cost in terms of writes). Getting this stuff right can be pretty important, as this often amounts to an all or nothing game. If all the data the dbms requires to preform the indexed lookup isn't present, it will probably resort to a table scan. Mysql's explain feature is one tool which can be helpful in checking your configuration and identifying optimizations.

Upvotes: 1

DevT
DevT

Reputation: 4933

if u create index by using one key, then when the data is searched it will find through only that key.

 INDEX `topic_id_idx` (`topic_id` ASC) ,

 INDEX `course_id_idx` (`course_id` ASC)

in this situation data is searched topic_id and course_id separately. but if you combine them data is searched combining them.

for a example if you have some data as follows :

topic_id       course_id

----------

abc               1
pqr               2
abc               3

if you want to search abc - 3 if you put separate indexes then it will search these two columns separately and find the result. but if you combine them then it will search abc+3 directly.

Upvotes: 0

Related Questions