{"id":21305,"date":"2022-10-21T10:00:00","date_gmt":"2022-10-21T17:00:00","guid":{"rendered":"https:\/\/coderpad.io\/?p=21305"},"modified":"2023-06-05T14:01:03","modified_gmt":"2023-06-05T21:01:03","slug":"how-to-use-indexes-to-increase-mysql-database-performance","status":"publish","type":"post","link":"https:\/\/coderpad.io\/blog\/development\/how-to-use-indexes-to-increase-mysql-database-performance\/","title":{"rendered":"How to Use Indexes to Increase MySQL Database Performance"},"content":{"rendered":"\n

What are Indexes?<\/h2>\n\n\n\n

Have you ever tried finding a chapter in a huge book, and you head over to the \u201cTable of Contents\u201d or Index page and seek the page number for the chapter? That\u2019s a similar way DBMS use indexes to speed up data retrieval. Indexes are made up of keys from one or more columns in a table and they contain pointers that tell MySQL where a particular row of data is stored in the database. This enables the MySQL server to skip searching long rows of a table to find that piece of data thus boosting query speed. Additionally, indexes enable data to be better organized on disk<\/a>. The MySQL Join Optimizer<\/a> also uses indexes to speed up queries that involve joins.<\/p>\n\n\n\n

Indexing is one of the most powerful features of a database. It\u2019s basically the most important thing database engineers consider when optimizing databases for speed. <\/p>\n\n\n\n

Indexing basics<\/h2>\n\n\n\n

Creating an index in MySQL is done using the CREATE INDEX<\/code> command, and has the following syntax:<\/p>\n\n\n

CREATE<\/span> INDEX<\/span> index_name ON<\/span> table_name ( column1, column2,...)<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
You can also set up indexes when creating a new table using the INDEX<\/code> statement:<\/p>\n\n\n
CREATE<\/span> TABLE<\/span> Customer (\n    last_name  varchar<\/span>(30<\/span>)   not<\/span> null<\/span>,\n    first_name varchar<\/span>(30<\/span>)   not<\/span> null<\/span>,\n    email      varchar<\/span>(50<\/span>)   not<\/span> null<\/span>,\n    INDEX<\/span>(email)\n);<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
You can also use a PRIMARY KEY<\/code> statement instead of an INDEX<\/code> statement. However, note that a table can only contain a single PRIMARY KEY<\/code>, and the key must contain UNIQUE<\/code> values and no NULL<\/code> values:<\/p>\n\n\n
CREATE<\/span> TABLE<\/span> Customer ( id<\/span> int<\/span> NOT<\/span> NULL<\/span>, last_name varchar<\/span>(30<\/span>) NOT<\/span> NULL<\/span>, first_name varchar<\/span>(30<\/span>) NOT<\/span> NULL<\/span>, email varchar<\/span>(50<\/span>)   NOT<\/span> NULL<\/span>,    CONSTRAINT<\/span> PK_Customer PRIMARY KEY<\/span> (id<\/span>,last_name));<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
For existing tables, you can also add indexes as follows:<\/p>\n\n\n
ALTER<\/span> TABLE<\/span> Customer ADD<\/span> INDEX<\/span> (email);\nALTER<\/span> TABLE<\/span> Customer ADD<\/span> PRIMARY KEY<\/span> (id<\/span>);<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
Deleting existing indexes is simple, just use the DROP INDEX<\/code> statement:<\/p>\n\n\n
ALTER<\/span> TABLE<\/span> Customer DROP<\/span> INDEX<\/span> (email);<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
Types of Indexes<\/h2>\n\n\n\n
MySQL offers many types of indexes, usually categorized according to their data structure. Most of the indexes created in MySQL are stored in B-trees. These include PRIMARY KEY<\/code>, INDEX<\/code>, FULLTEXT<\/code>, and UNIQUE<\/code> indexes. For Spatial Data types, MySQL uses R-trees to store their indexes. Memory tables use hash indexes by default, but B-tree indexes are also supported.<\/p>\n\n\n\n
In the following subheadings, we\u2019ll explore all the different types of indexes, their benefits, and their disadvantages.<\/p>\n\n\n\n
B-Tree indexes<\/h3>\n\n\n\n
Most storage engines in MySQL use B-tree indexes by default. B-tree indexes can be used for column comparisons in expressions that use the =<\/code>, ><\/code>, >=<\/code>, <<\/code>, <=<\/code>, or BETWEEN<\/code> operators. They can also be used in LIKE<\/code> comparisons if the argument is a constant string that does not start with a wildcard (<\/code>%,<\/code>_)<\/code> character.<\/p>\n\n\n\n
B-Tree Indexes Characteristics<\/h4>\n\n\n\n
B-Trees are search trees commonly used by large databases to access data stored on the disk. Because of its properties, searching for data in a data set can be achieved in significantly less time than otherwise. A B-tree stores all its values in leaves that are sorted in increasing order. All leaves are at the same level and have the same distance from the root node. <\/p>\n\n\n\n
When the storage engine performs a lookup on a table, it doesn\u2019t need to scan all the rows to find the desired data instead, it will traverse the B-tree starting from the root node. The root node holds pointers to child nodes. The storage engine uses these pointers to find a leaf page that contains pointers to the indexed data. This process is fast because the indexed values are arranged in order. For example, when looking up an index for a column that contains text values, the storage engine will traverse the tree in alphabetical order. We summarize the steps MySQL\u2019s storage engine will need to take to locate a piece of indexed data by utilizing a B-tree below:<\/p>\n\n\n\n
    \n
  1. Start at the root node and proceed to the next level in the tree.<\/li>\n\n\n\n
  2. Find a node that contains a range of values between a lower and upper limit (for example, every country whose name begins with S through T).<\/li>\n\n\n\n
  3. Traverse the tree until it finds the node with the closest range using pointers between nodes.<\/li>\n\n\n\n
  4. If the node is found, it traverses through the leaf pages using pointers until the leaf page with the indexed data is found.<\/li>\n<\/ol>\n\n\n\n
    Considerations When Using B-Tree Indexes<\/h4>\n\n\n\n
    Earlier, we stated that B-tree indexes can be used in LIKE<\/code> comparisons. In other to fully utilize indexes, we have to ensure that the argument is a constant string and must not include a wildcard character. For example, the following SELECT<\/code> statements are using indexes:<\/p>\n\n\n
    SELECT<\/span> * FROM<\/span> customer WHERE<\/span> country LIKE<\/span> 'Spain%'<\/span>;\nSELECT<\/span> * FROM<\/span> customer WHERE<\/span> country LIKE<\/span> 'Sp%_in%'<\/span>;<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
    In the first statement, only rows with 'Spain' <= country < 'Spaio'<\/code> are considered. While the second statement will consider only rows with 'Sp' <= country < 'Sq'<\/code>.<\/p>\n\n\n\n
    Note that MySQL is checking the last character of the string in alphabetical order; the letter \u201co<\/strong>\u201d comes after the letter \u201cn<\/strong>\u201d.<\/p>\n\n\n\n
    The following SELECT<\/code> statements will not use indexes:<\/p>\n\n\n
    SELECT<\/span> * FROM<\/span> customer WHERE<\/span> country LIKE<\/span> '%Spain%'<\/span>;\nSELECT<\/span> * FROM<\/span> customer WHERE<\/span> country LIKE<\/span> another_col;<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
    The first statement starts with a wildcard, so it will fail to use an index, and the second statement will not also because its LIKE<\/code> argument is not a constant string.<\/p>\n\n\n\n
    Any index that fails to span all AND<\/code> levels in a WHERE<\/code> clause is not used in optimizing the query. In other words, to be able to use an index, a prefix of the index must be used in every AND<\/code> group. For example, the following statements use indexes:<\/p>\n\n\n
    SELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index_part1=1<\/span> AND<\/span> index_part2=2<\/span> AND<\/span> other_column=3<\/span>\n\n\/* index = 1 OR index = 2 *\/<\/span>\nSELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index<\/span>=1<\/span> OR<\/span> A=10<\/span> AND<\/span> index<\/span>=2<\/span>;\n\n\/* optimized like \"index_part1='hello'\" *\/<\/span>\nSELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index_part1='hello'<\/span> AND<\/span> index_part3=5<\/span>;\n\n\/* Can use index on index1 but not on index2 or index3 *\/<\/span>\nSELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index1=1<\/span> AND<\/span> index2=2<\/span> OR<\/span> index1=3<\/span> AND<\/span> index3=3<\/span>;<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
    But these WHERE<\/code> clauses do not use indexes:<\/p>\n\n\n
    \/* index_part1 is not used *\/<\/span>\nSELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index_part2=1<\/span> AND<\/span> index_part3=2<\/span>\n\n\/*  Index is not used in both parts of the WHERE clause  *\/<\/span>\nSELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index<\/span>=1<\/span> OR<\/span> A=10<\/span>\n\n\/* No index spans all rows  *\/<\/span>\nSELECT<\/span> * FROM<\/span> table_name WHERE<\/span> index_part1=1<\/span> OR<\/span> index_part2=10<\/span><\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\n
    Sometimes the MySQL Query Optimizer does not use indexes in optimizing queries. This is because the optimizer may have estimated that the index would require MySQL to access a large number of rows than otherwise. To fully understand how the MySQL Optimizer treats queries that utilize indexes, I would recommend you check this article on query performance optimization<\/a>. <\/p>\n\n\n\n
    In summary, it\u2019s a good practice to check and confirm if your queries actually use the indexes you created in the tables. In case the optimizer is wrong, you can always resort to using Index hints<\/a> to overwrite the default behavior. We discussed all of that in the suggested article<\/a>.<\/p>\n\n\n\n
    Hash Indexes<\/h3>\n\n\n\n
    Hash indexes are also used by MySQL to improve data access speed, just like B-tree indexes. The differences, however, are:<\/p>\n\n\n\n