简体   繁体   中英

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, However I have no idea what columns should be indexed.

Now the Question:

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

2) how would I know what columns to index ?

1) Primary keys are implemented using a unique index automatically in Postgres.
The same is true for MySQL.

You are done here.

2) For advice on additional indices, consider this closely related answer:
Optimize PostgreSQL read-only tables

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

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.

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.

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! .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM