CODEWITHSUNDEEP
mysqlpostgresqlindexingdatabase-designdatabase-performance
user962206
user962206

Reputation: 16147

Using Primary Keys as Index

In my application I usually use my primary keys as a way to access data. However, I've been told in order to increase performance, I should index columns in my table. But I have no idea what columns to index.

Now the Questions:

  1. Is it a good idea to create an index on your primary key?

  2. How would I know what columns to index?

Upvotes: 0

Views: 195

Answers (5)

Jonathan Otero
Jonathan Otero

Reputation: 1

  1. Your primary key will always be an index.

  2. Always create indexes in columns that help to reduce the search, for example if in the column there are only 3 different values ​​among more than a thousand it is a good sign to make it index.

Upvotes: 0

Erwin Brandstetter
Erwin Brandstetter

Reputation: 659317

  1. Is it a good idea to create an index on your primary key?

Primary keys are implemented using a unique index automatically in Postgres. You are done here.
The same is true for MySQL. See:

  1. How would I know what columns to index?

For advice on additional indices, see:

Again, the basics are the same for MySQL and Postgres. But Postgres has more advanced features like partial or functional indices if you need them. Start with the basics, though.

Upvotes: 3

Branko Dimitrijevic
Branko Dimitrijevic

Reputation: 52157

1) Is it a good idea to make your primary key as an Index?(assuming the primary key is unique,an id

All DBMSes I know of will automatically create an index underneath the PK.

In case of MySQL/InnoDB, PK will not just be indexed, but that index will be clustered index.

(BTW, just saying "primary key" implies it is unique, so there is no need to explicitly state "assuming the primary key is unique".)

2) how would I know what columns to index ?

That depends on which queries need to be supported.

But beware that adding indexes is not free and is a matter of engineering tradeoff - while some queries might benefit from an index, some may actually suffer from it. For example:

  • An index on FOO would significantly speed-up the SELECT * FROM T WHERE FOO = ....
  • However, the same index would somewhat slow-down the INSERT INTO T VALUES (...).

In most situations you'd favor large speedup in SELECT over small slowdown in INSERT, but that may not always be the case.

Indexing and the database performance in general are a complex topic beyond the scope of a humble StackOverflow post, but if you are interested I warmly recommend reading Use The Index, Luke!.

Upvotes: 0

HLGEM
HLGEM

Reputation: 96648

Primary keys will have an idex only if you formally define them as primary keys. Where most people forget to make indexes are Foriegn keys which are not generally automatically indexed and almost always will be involved in joins and thus indexed. Other candidates for indexes are things you frequently filter data on that have a large number fo possible values, things like names, part numbers, start Dates, etc.

Upvotes: 0

Kirk Roybal
Kirk Roybal

Reputation: 17867

Your primary key will already have an index that is created for you automatically by PostgreSQL. You do not need to index the column again.

As far as the rest of the fields go, take a look at the article here on figuring out cardinality: http://kirk.webfinish.com/2013/08/some-help-to-find-uniqueness-in-a-large-table-with-many-fields/

Fields that are completely unique are candidates, fields that have no uniqueness at all are useless to index. The sweet spot is the cardinality in the middle (.5).

And of course you should take a look at which columns you are using in the WHERE clause. It is useless to index columns that are not a part of your quals.

Upvotes: 0

Related Questions