appreciated.

INTRODUCTION

The most common repetitive task for an operational DBA is the review and optimization of running SQL statements in a production environment. After the MySQL software is installed, configured, and operating correctly, monitoring the database for performance issues is a regular reoccurring task. Knowing how to capture problematic SQL statements correctly, review and tune appropriately are critical skills for a proficient resource. Although MySQL is an RDBMS, experienced Database Administrators from an Oracle or SQL Server background will need to learn how to apply the theory of SQL query analysis correctly in MySQL terms by reading and understanding the Query Execution Plan (QEP), knowing the limitations with the MySQL optimizer functionality, and understanding how different MySQL storage engines change how indexes are effectively used.

The optimization of SQL statements is not just the domain of the database administrator. This book will provide the education to help readers understand how MySQL indexes and storage engines operate, which is an important implementation consideration for an optimal database design by the data architect. Software developers will be able to capture and analyze all SQL statements written to ensure performance bottlenecks can be identified early in the development lifecycle and raised with applicable resources.

Optimizing SQL statements is a key component of improving performance and scalability.

1

The Five Minute DBA

Users are complaining that the application is slow. By reviewing your system and database performance, you have identified a slow running SQL query in the database. If you did not know how to tune an SQL statement in MySQL, what would you do? This book aims to address this need by discussing the ideal approach and best principles toward optimizing SQL statements. This chapter provides a few quick tips you can apply immediately.

In this chapter we will be using the following approach:

• Confirm your slow query

• Identify a missing index

• Apply a new index

• Verify your new index

Identifying Performance Problems

Users report that your application is too slow. After determining there is no physical system resource bottleneck, you turn your attention to the MySQL database.

Finding a Slow SQL Statement

Looking at the current running MySQL connections with the SHOW FULL PROCESSLIST command, you find the following details:

mysql> SHOW FULL PROCESSLIST\G

...

*************************** 6. row ***************************

    Id: 42

  User: appl

  Host: localhost

    db: NULL

Command: Query

  Time: 3

  State: Query

  Info: SELECT * FROM inventory WHERE item_id = 16102176

This information shows the SELECT statement in the Info column has been running for 3 seconds via the value in the Time column.

What do you do now?

Confirming the Slow Query

Your first step when identifying a potential slow query is to confirm that it is slow when repeated. Verify that it was not a unique instance that might have occurred because of other factors such as locking or a system bottleneck.

Run and Time Your SQL Statement

Re-running the SQL statement using the MySQL command line client or other client tool is an easy approach for verification:

mysql> SELECT * FROM inventory WHERE item_id = 16102176;

Empty set (3.19 sec)

This confirms the query took more than 3 seconds to execute. When the query takes more than 10 milliseconds, the output from the MySQL command line client is sufficient. Chapter 7 details alternative ways to determine the response time of a query.

CAUTION You should rerun only SELECT statements, because these do not modify any existing data. If your slow running query is an UPDATE or DELETE statement, you can simply rewrite this query as a SELECT statement for verification purposes. For example, if the SQL query was DELETE FROM inventory WHERE item_id = 16102176, you would have rewritten this query as the SELECT statement shown in this example to simulate the performance but not modify any information.

Generate a Query Execution Plan (QEP)

When MySQL executes an SQL query, it first parses the SQL query for valid syntax, and then it constructs a QEP that determines how MySQL will retrieve information from its underlying storage engines. To show the QEP the MySQL query optimizer is expected to construct for an SQL statement, simply prefix the SELECT statement with the EXPLAIN keyword like so:

mysql>

EXPLAIN

SELECT * FROM inventory WHERE item_id = 16102176\G

*************************** 1. row ***************************

          id: 1

  select_type: SIMPLE

        table: inventory

        type: ALL

possible_keys: NULL

          key: NULL

      key_len: NULL

          ref: NULL

        rows: 787338

        Extra: Using where

This vertical output is obtained using the \G statement terminator with the MySQL command line client. This is helpful for parsing output via automated operations and also for any printed form such as in this book. Using the semicolon (;) terminator provides a column orientated approach that is generally easier to read with multiple rows of output.

NOTE In most cases, an EXPLAIN does not run the actual SQL statement; however, there are some exceptions when part of a SELECT statement might be executed for the optimizer to determine how to construct the QEP. An example is the use of a derived table in the FROM clause, which you would identify with the word DERIVED in the select_type column. You can find more information about these limitations in the MySQL Reference Manual at http://dev.mysql.com/doc/refman/5.5/en/from-clause-subqueries.html.

If you knew nothing about how to read a QEP, the first two columns you should scan are the indexes used and the number of rows affected. Any query that does not use an index signified by the key column in the preceding output can be considered a poorly tuned SQL query. The number of rows affected in evaluating this SQL statement, as signified by the rows column, contributes to an estimation of how much data is read and can directly correlate to the amount of time required to execute the query. The type column with a value of ALL is also an indicator of a potential problem; we will discuss this in more detail in Chapters 4 and 9.

NOTE Depending on the underlying storage engine, the number of affected rows will be either an estimate or an exact number of rows to be examined. Even when the number of affected rows is an estimate (such as when the InnoDB storage engine manages the table storage), the estimate is typically adequate for the optimizer to make an informed decision.

In this EXPLAIN example no index value was found in the key column. Because this is a single table SELECT statement, this can be considered a full table scan to search for any rows that match the WHERE clause predicate. The rows value can then be considered an approximate value for the number of rows read in order to find the occurrences matching item_id=16102176.

Optimizing Your Query

Identifying a slow running SQL query is a necessary prerequisite for any type of optimization. Throughout this book, we will detail the tools and principles required to determine the various options for an ideal solution.

What You Should Not Do

If you lived in the wild west, where no rules applied, you might consider adding an index to this table based on the WHERE clause. Here is an example:

mysql> ALTER TABLE inventory ADD INDEX (item_id);

Query OK, 734787 rows affected (54.22 sec)

Records: 734787 Duplicates: 0 Warnings: 0

CAUTION Do not try this in a production environment without additional verification!

There are many factors to choosing to add a new index and deploying it accordingly. This statement highlights just one potential impact on a production environment. This Data Definition Language (DDL) statement took about 55 seconds to complete. During that time, any additional queries that add or modify data for this table are blocked, because the ALTER statement is a blocking operation. Depending on the order in which other Data Manipulation Language (DML) statements are executed, SELECT statements are also blocked from completing during this time. For larger tables, an ALTER statement can takes hours, or even days, to complete! A second impact to consider is the performance overhead of DML statements when a table has multiple indexes.

Confirm Your Optimization

By re-running the SQL query, you can see an immediate improvement with the query now taking less than 10 milliseconds.

mysql> SELECT * FROM inventory WHERE item_id = 16102176;

Empty set (0.00 sec)

You can also confirm the effectiveness of the new index by looking at the revised QEP:

mysql> EXPLAIN SELECT * FROM inventory WHERE item_id = 16102176\G

*************************** 1. row ***************************

          id: 1

  select_type: SIMPLE

        table: inventory

        type: ref

possible_keys: item_id

          key: item_id

      key_len: 4

          ref: const

        rows: 1

        Extra:

The MySQL optimizer has now selected an index as indicated by the value in the key column, and the number of rows estimated to be examined during the execution of the SQL statement was 1, compared with the original value of 787,338.

The Correct Approach

Adding an index to a table offers benefits including performance optimization; however, there are always other implications for adding an index. Chapters 4 and 5 will discuss the pros and cons of adding indexes on table columns. Before you choose to add an index, you should always perform at least two checks: the first to verify the existing structure of the table, and the second to confirm the size of the table. You can obtain this information using the following SQL commands:

mysql> SHOW CREATE TABLE inventory\G

*************************** 1. row ***************************

Create Table: CREATE TABLE `inventory` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  `supp_id` int(10) unsigned NOT NULL DEFAULT '0',

  `item_id` int(10) unsigned NOT NULL DEFAULT '0',

  `qty` int(11) NOT NULL,

  `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP

  PRIMARY KEY (`id`),

  UNIQUE KEY `supp_id` (`supp_id`,`item_id`),

  KEY `created` (`created`),

) ENGINE=InnoDB DEFAULT CHARSET=latin1

mysql> SHOW TABLE STATUS LIKE 'inventory'\G

*************************** 1. row ***************************

          Name: inventory

        Engine: InnoDB

        Version: 10

    Row_format: Compact

          Rows: 679890

Avg_row_length: 371

    Data_length: 252395520

Max_data_length: 0

  Index_length: 40861696

      Data_free: 0

Auto_increment: 1612406

    Create_time: 2010-08-17 20:16:13

    Update_time: NULL

    Check_time: NULL

      Collation: latin1_swedish_ci

      Checksum: NULL

Create_options:

        Comment: InnoDB free: 644096 Kb

From these commands, you can determine that the current table structure includes a number of indexes, including an index that uses the item_id column. This index was not used, however, because the leftmost column of the index was not satisfied by this query. You also get an approximate size of the table by the Data_length and Rows information from the SHOW TABLE STATUS command. Chapters 4 and 5 will further discuss the importance of this information in determining the time impact of adding an index and the impact of having multiple indexes on the same column.

An Alternative Solution

By choosing to look at this SQL statement in isolation, the DBA or architect can elect to create an index, as described. The correct approach for optimizing SQL includes understanding and verifying the purpose for the SQL statement and related SQL statements for this table. By performing this analysis, you would highlight that the application code executing this SQL statement already maintains additional information to improve the query. The value for supp_id was known at the time this SQL statement was executed. By altering the SQL statement to include this column in the WHERE clause, the existing index would be used. No schema changes would be necessary to improve the SQL statement.

In this example, adding an index was not the ideal approach to addressing the observed slow query; without further analysis, the table would have the overhead of an additional unnecessary index.

Conclusion

Optimizing SQL statements is not about just adding an index. This chapter described several analysis tools used to help optimize a statement, including EXPLAIN and SHOW CREATE TABLE. We looked at some of the attributes that identify performance problems and outlined initial important information. We detailed some of the considerations that affect operations