After you have done a good normalization, do you still need to index the table? How is this going to affect the performance? Will it even affect the performance in some way after a good normalization?

Which columns are usually indexed if you already have the primary key and the foreign key?

It's seems like it's already effective to normalize a database. But, I might have skipped how indexing affects the database. Is this only effective when queries are used? How does this work/perform and make a database better?

  • 5
    Which columns are usually indexed if you already have the primary key and the foreign key? Dates. Names. Anything you might need to search or sort on. Jan 6, 2013 at 22:31
  • The index on the primary key doesn't count? Mar 14, 2013 at 20:03

6 Answers 6


Yes. In fact, you very well may need to pay more attention to your indexes. Normalization is about optimal storage. That's often at odds with retrieval speed, as more complex queries with complicated joins are used. Sometimes people maintaining databases that require fast retrieval speeds will de-normalize, or arrange their data in slightly less normalized structures to make retrieval easier.

  • 22
    The goal of normalization is not storage efficiency, but rather removal of insertion, update, and deletion dependencies. Further reading
    – user40980
    Jan 7, 2013 at 15:29
  • 4
    I agree with @MichealT that it's not about efficiency. Logical consistency was what I got out of the link.
    – JeffO
    Jan 7, 2013 at 16:07
  • I'll remove the controversial word 'efficiency' (though I do think that basically sums up the general purpose of normalization) and just use the word 'optimal' instead, leaving what that means up to the reader. The actual purpose of normalization isnt actually relevant to why indexes are still needed after a database is normalized. Jan 8, 2013 at 19:49

I think you misunderstood what indexing does for database performance.

An index helps the database find rows. Indexes are specialized data-structures that, in exchange for extra disk-space and some performance when inserting and updating, help the database engine home in on matching rows.

Because they take extra space and cost (a modicum of) performance to keep them up-to-date, you as a database designer must create indexes explicitly to suit your application and query patterns.

Indexes are orthogonal to database normalization.


Yes after normalization you still need indexing.

The tables you are working with benefit just as much as the tables you had before normalization. In actuality, on their own they're just the same: tables.

One thing you have to consider though, indexes help you find your way through your data faster. Normalizing a design of a database is always good, but sometimes for performance reason you have to denormalize the implementation. But that's only on a case by case basis.



Indices are a method to speed up searching for the data. Some queries are by primary keys, which are usually implicitly indexed by the database engine, but other queries are likely to use other columns. Often some queries search by columns that are not even unique and thus can't become primary keys after any normalization. You will probably have to index such columns.

There is only one way to know which indices to create. Take all queries in the application, find representative example parameters for them and have the database engine show their query plans (all database engines have EXPLAIN, EXPLAIN QUERY PLAN or similar command; it is called differently in different engines) and test how long they take. Than create indices that speed up the ones that were slow. And don't forget to drop again indices that you tried but didn't help to avoid wasting resources.


Indexes are generally needed in all but the smallest tables. Pretty much every foreign key should be indexed and just setting up an FK does not mean you have an index (at least not in some databases, check you db documentation). Fields you frequently join on or use in where clauses should be indexed if they are ones that would benefit (you need a certain amount of variablity in data so Booleans don't benefit for instance) and ones where it is possible to index.

However, every index slows down inserts\updates\deletes while speeding up selects, so choose your indexes carefully.

Indexes are critical to acceptable performance in a database.


For a third normal form you will definitely need indexes on all the primary keys.

Whether you need any other indexes depends on how your database is used. For example if you regularly search for customers in a particular ZIP code, then, it might be a good idea to index the zip_code column in the customer table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.