|
| 1 | +--- |
| 2 | +title: Troubleshooting best practices - Azure Database for MySQL |
| 3 | +description: This article describes some recommendations for troubleshooting your Azure Database for MySQL server. |
| 4 | +ms.service: mysql |
| 5 | +ms.subservice: single-server |
| 6 | +ms.topic: conceptual |
| 7 | +author: Bashar-MSFT |
| 8 | +ms.author: bahusse |
| 9 | +ms.date: 07/22/2022 |
| 10 | +--- |
| 11 | + |
| 12 | +# Best practices for troubleshooting your Azure Database for MySQL server |
| 13 | + |
| 14 | +[!INCLUDE[applies-to-mysql-single-flexible-server](../includes/applies-to-mysql-single-flexible-server.md)] |
| 15 | + |
| 16 | +Use the sections below to keep your MySQL databases running smoothly and use this information as guiding principles for ensuring that the schemas are designed optimally and provide the best performance for your applications. |
| 17 | + |
| 18 | +## Check the number of indexes |
| 19 | + |
| 20 | +In a busy database environment, you may observe high I/O usage, which can be an indicator of poor data access patterns. Unused indexes can negatively impact performance as they consume disk space and cache, and slow down write operations (INSERT / DELETE / UPDATE). Unused indexes unnecessarily consume additional storage space and increase the backup size. |
| 21 | + |
| 22 | +Before you remove any index, be sure to gather enough information to verify that it's no longer in use. This can help you avoid inadvertently removing an index that is perhaps critical for a query that runs only quarterly or annually. Also, be sure to consider whether an index is used to enforce uniqueness or ordering. |
| 23 | + |
| 24 | +> [!NOTE] |
| 25 | +> Remember to review indexes periodically and perform any necessary updates based on any modifications to the table data. |
| 26 | +
|
| 27 | +`SELECT object_schema, |
| 28 | + object_name, |
| 29 | + index_name |
| 30 | +FROM performance_schema.table_io_waits_summary_by_index_usage |
| 31 | +WHERE index_name IS NOT NULL |
| 32 | +AND count_star = 0 |
| 33 | +ORDER BY object_schema, object_name;` |
| 34 | + |
| 35 | +(or) |
| 36 | + |
| 37 | +`use information_schema; |
| 38 | +select |
| 39 | +tables.table_name, |
| 40 | +statistics.index_name, |
| 41 | +statistics.cardinality, |
| 42 | +tables.table_rows |
| 43 | +from tables |
| 44 | +join statistics |
| 45 | +on (statistics.table_name = tables.table_name |
| 46 | +and statistics.table_schema = '<YOUR DATABASE NAME HERE>' |
| 47 | +and ((tables.table_rows / statistics.cardinality) > 1000));` |
| 48 | + |
| 49 | +## Review the primary key design |
| 50 | + |
| 51 | +Azure Database for MySQL uses the InnoDB storage engine for all non-temporary tables. With InnoDB, data is stored within a clustered index using a B-Tree structure. The table is physically organized based on primary key values, which means that rows are stored in the primary key order. |
| 52 | +Each secondary key entry in an InnoDB table contains a pointer to the primary key value in which the data is stored. In other words, a secondary index entry contains a copy of the primary key value to which the entry is pointing. Therefore, primary key choices have a direct effect on the amount of storage overhead in your tables. |
| 53 | + |
| 54 | +If a key is derived from actual data (e.g., username, email, SSN, etc.), it’s called a *natural key*. If a key is artificial and not derived from data (e.g., an auto-incremented integer), it’s referred to as a *synthetic key* or *surrogate key*. |
| 55 | + |
| 56 | +It’s generally recommended to avoid using natural primary keys. These keys are often very wide and contain long values from one or multiple columns. This in turn can introduce severe storage overhead with the primary key value being copied into each secondary key entry. Moreover, natural keys don’t usually follow a pre-determined order, which dramatically reduces performance and provokes page fragmentation when rows are inserted or updated. To avoid these issues, use monotonically increasing surrogate keys instead of natural keys. An auto-increment (big)integer column is a good example of a monotonically increasing surrogate key. If you require a certain combination of columns, be unique, declare those columns as a unique secondary key. |
| 57 | + |
| 58 | +During the initial stages of building an application, you may not think ahead to imagine a time when your table begins to approach having two billion rows. As a result, you might opt to use a signed 4 byte integer for the data type of an ID (primary key) column. Be sure to check all table primary keys and switch to use 8 byte integer (BIGINT) columns to accommodate the potential for a high volume or growth. |
| 59 | + |
| 60 | +> [!NOTE] |
| 61 | +> For more information about data types and their maximum values, in the MySQL Reference Manual, see [Data Types](https://dev.mysql.com/doc/refman/5.7/en/data-types.html). |
| 62 | +
|
| 63 | +## Use covering indexes |
| 64 | + |
| 65 | +The previous section explains how indexes in MySQL are organized as B-Trees and in a clustered index, the leaf nodes contain the data pages of the underlying table. Secondary indexes have the same B-tree structure as clustered indexes, and you can define them on a table or view with a clustered index or a heap. Each index row in the secondary index contains the non-clustered key value and a row locator. This locator points to the data row in the clustered index or heap having the key value. As a result, any lookup involving a secondary index must navigate starting from the root node through the branch nodes to the correct leaf node to take the primary key value. The System then executes a random IO read on the primary key index (once again navigating from the root node through the branch nodes to the correct leaf node) to get the data row. |
| 66 | + |
| 67 | +To avoid this extra random IO read on the primary key index to get the data row, use a covering index, which includes all fields required by the query. Generally, using this approach is beneficial for I/O bound workloads and cached workloads. So as a best practice, use covering indexes because they fit in memory and are smaller and more efficient to read than scanning all the rows. |
| 68 | + |
| 69 | +Consider, for example, a table that you're using to try to find all employees who joined the company after January 1, 2000. |
| 70 | + |
| 71 | +``` |
| 72 | +mysql> show create table employee\G |
| 73 | +*************************** 1. row *************************** |
| 74 | + Table: employee |
| 75 | +Create Table: CREATE TABLE `employee` ( |
| 76 | + `empid` int(11) NOT NULL AUTO_INCREMENT, |
| 77 | + `fname` varchar(10) DEFAULT NULL, |
| 78 | + `lname` varchar(10) DEFAULT NULL, |
| 79 | + `joindate` datetime DEFAULT NULL, |
| 80 | + `department` varchar(10) DEFAULT NULL, |
| 81 | + PRIMARY KEY (`empid`) |
| 82 | + ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1 |
| 83 | +1 row in set (0.00 sec)` |
| 84 | +
|
| 85 | +`mysql> select empid, fname, lname from employee where joindate > '2000-01-01'; |
| 86 | +``` |
| 87 | + |
| 88 | +If you run an EXPLAIN plan on this query, you’d observe that currently no indexes are being used, and a where clause alone is being used to filter the employee records. |
| 89 | + |
| 90 | +``` |
| 91 | +mysql> EXPLAIN select empid, fname, lname from employee where joindate > '2000-01-01'\G |
| 92 | +*************************** 1. row *************************** |
| 93 | + id: 1 |
| 94 | + select_type: SIMPLE |
| 95 | + table: employee |
| 96 | + partitions: NULL |
| 97 | + type: ALL |
| 98 | +possible_keys: NULL |
| 99 | + key: NULL |
| 100 | + key_len: NULL |
| 101 | + ref: NULL |
| 102 | + rows: 3 |
| 103 | + filtered: 33.33 |
| 104 | + Extra: Using where |
| 105 | +1 row in set, 1 warning (0.01 sec) |
| 106 | +``` |
| 107 | + |
| 108 | +However, if you were to add an index that covers the column in the where clause, along with the projected columns you would see that the index is being used to locate the columns much more quickly and efficiently. |
| 109 | + |
| 110 | +`mysql> CREATE INDEX cvg_idx_ex ON employee (joindate, empid, fname, lname);` |
| 111 | + |
| 112 | +Now, if you run EXPLAIN plan on the same query, the "Using Index" value appears in the “Extra” field, which means that InnoDB executes the query using the index we created earlier, which confirms this as a covering index. |
| 113 | + |
| 114 | +``` |
| 115 | +mysql> EXPLAIN select empid, fname, lname from employee where joindate > '2000-01-01'\G |
| 116 | +*************************** 1. row *************************** |
| 117 | + id: 1 |
| 118 | + select_type: SIMPLE |
| 119 | + table: employee |
| 120 | + partitions: NULL |
| 121 | + type: range |
| 122 | +possible_keys: cvg_idx_ex |
| 123 | + key: cvg_idx_ex |
| 124 | + key_len: 6 |
| 125 | + ref: NULL |
| 126 | + rows: 1 |
| 127 | + filtered: 100.00 |
| 128 | + Extra: Using where; Using index |
| 129 | +1 row in set, 1 warning (0.01 sec) |
| 130 | +``` |
| 131 | + |
| 132 | +> [!NOTE] |
| 133 | +> It's important to choose the correct order of the columns in the covering index to serve query correctly. The general rule is to choose the columns for filtering first (WHERE clause), then sorting/grouping (ORDER BY and GROUP BY) and finally the data projection (SELECT). |
| 134 | +
|
| 135 | +From the prior example, we've seen that having a covering index for a query provides more efficient record retrieval paths and optimizes performance in a highly concurrent database environment. |
| 136 | + |
| 137 | +## Next steps |
| 138 | + |
| 139 | +To find peer answers to your most important questions, or to post or answer questions, visit [Stack Overflow](https://stackoverflow.com/questions/tagged/azure-database-mysql). |
0 commit comments