Besides the primary key and the foreign key, there is another common key called an index. The concept of database indexes is exactly the same as the index found at the back of a good book. For a book with hundreds of pages, it will be a nightmare trying to look for a particular word or phrase in the book. The reader will instead flip right to the back of the book and look for the particular word or phrase in the index section. The index section will tell the reader which page(s) in the book to zoom in to look for the word or phrase of interest.
In a database table, the database designer may specify some columns as index keys. The database engine will index all the values in these index keys so that when users perform a search on the table using the column as part of the search criteria, the database engine can quickly and efficiently find the required record(s).
A good rule of thumb is that any column on which a search is to be performed needs to be indexed. If a search is performed on a column that is not an index, the database engine will need to parse through all the records in the table in order to find all records matching the search criteria. This will be a major problem and a huge drain on computing resources if the table contains a huge number of records.
The downside to creating index keys is that the database engine typically needs to create an index file to store these indexes. The database engine needs to be aware of any changes to any index key values in the database table in order to update this index file. Index information is affected for every table INSERT, UPDATE or DELETE operation. This directly increases the database server's storage and computing resource requirements.