Techniques to improve application performance can come from a lot of different places, but normally the first thing we look at — the most common bottleneck — is the database. Can it be improved? How can we measure and understand what needs and can be improved?

提高应用程序性能的技术可以来自许多不同的地方，但是通常我们要看的第一件事(最常见的瓶颈)是数据库。 可以改善吗？ 我们如何衡量和了解哪些需求可以改进？

One very simple yet very useful tool is query profiling. Enabling profiling is a simple way to get a more accurate time estimate of running a query. This is a two-step process. First, we have to enable profiling. Then, we call show profiles to actually get the query running time.

一种非常简单但非常有用的工具是查询概要分析。 启用概要分析是获得运行查询的更准确时间估计的一种简单方法。 这是一个两步过程。 首先，我们必须启用分析。 然后，我们调用show profiles来实际获取查询的运行时间。

Let’s imagine we have the following insert in our database (and let’s assume User 1 and Gallery 1 are already created):

假设我们在数据库中插入了以下内容(并假设已经创建了User 1和Gallery 1)：

INSERT INTO `homestead`.`images` (`id`, `gallery_id`, `original_filename`, `filename`, `description`) VALUES
(1, 1, 'me.jpg', 'me.jpg', 'A photo of me walking down the street'),
(2, 1, 'dog.jpg', 'dog.jpg', 'A photo of my dog on the street'),
(3, 1, 'cat.jpg', 'cat.jpg', 'A photo of my cat walking down the street'),
(4, 1, 'purr.jpg', 'purr.jpg', 'A photo of my cat purring');

Obviously, this amount of data will not cause any trouble, but let’s use it to do a simple profile. Let’s consider the following query:

显然，这种数据量不会造成任何麻烦，但是让我们使用它来做一个简单的配置文件。 让我们考虑以下查询：

SELECT * FROM `homestead`.`images` AS i
WHERE i.description LIKE '%street%';

This query is a good example of one that can become problematic in the future if we get a lot of photo entries.

这个查询是一个很好的例子，如果我们收到很多照片条目，将来可能会出现问题。

To get an accurate running time on this query, we would use the following SQL:

为了获得此查询的准确运行时间，我们将使用以下SQL：

set profiling = 1;
SELECT * FROM `homestead`.`images` AS i
WHERE i.description LIKE '%street%';
show profiles;

The result would look like the following:

结果如下所示：

As we can see, the show profiles; command gives us times not only for the original query but also for all the other queries that are made. This way we can accurately profile our queries.

正如我们所看到的， show profiles; 该命令不仅为我们提供了原始查询的时间，还为我们进行的所有其他查询提供了时间。 这样，我们可以准确地描述我们的查询。

But how can we actually improve them?

但是，我们如何才能真正改善它们呢？

We can either rely on our knowledge of SQL and improvise, or we can rely on the MySQL explain command and improve our query performance based on actual information.

我们可以依靠我们SQL知识和即兴创作，也可以依靠MySQL explain命令并根据实际信息提高查询性能。

Explain is used to obtain a query execution plan, or how MySQL will execute our query. It works with SELECT, DELETE, INSERT, REPLACE, and UPDATE statements, and it displays information from the optimizer about the statement execution plan. The official documentation does a pretty good job of describing how explain can help us:

Explain用于获取查询执行计划，或MySQL如何执行查询。 它与SELECT ， DELETE ， INSERT ， REPLACE和UPDATE语句一起使用，并显示来自优化器的有关语句执行计划的信息。 官方文档在描述explain如何帮助我们方面做得非常好：

With the help of EXPLAIN, you can see where you should add indexes to tables so that the statement executes faster by using indexes to find rows. You can also use EXPLAIN to check whether the optimizer joins the tables in an optimal order.

在EXPLAIN的帮助下，您可以看到应该在哪里向表添加索引，以便通过使用索引查找行来使语句更快地执行。 您还可以使用EXPLAIN来检查优化器是否以最佳顺序联接表。

To exemplify the usage of explain, we’ll use the query made by our UserManager.php to find a user by email:

为了举例说明的使用explain ，我们将使用我们提出的查询UserManager.php发现通过电子邮件用户：

SELECT * FROM `homestead`.`users` WHERE email = 'claudio.ribeiro@examplemail.com';

To use the explain command, we simply prepend it before select type queries:

要使用explain命令，我们只需在选择类型查询之前添加它：

EXPLAIN SELECT * FROM `homestead`.`users` WHERE email = 'claudio.ribeiro@examplemail.com';

This is the result (scroll right to see all):

这是结果(向右滚动以查看全部)：

These results are not easy to understand at first sight, so let’s take a closer look at each one of them:

这些结果乍一看并不容易理解，因此让我们仔细看一下其中每个：

• id: this is just the sequential identifier for each of the queries within the SELECT.

  id ：这只是SELECT中每个查询的顺序标识符。

• select_type: the type of SELECT query. This field can take a number of different values, so we will focus on the most important ones:

  select_type ：SELECT查询的类型。 该字段可以采用许多不同的值，因此我们将重点介绍最重要的值：

  • SIMPLE: a simple query without subqueries or unions

    SIMPLE ：没有子查询或联合的简单查询

  • PRIMARY: the select is in the outermost query in a join

    PRIMARY ：选择位于PRIMARY的最外层查询中

  • DERIVED: the select is a part of a subquery within a from

    DERIVED ：选择是from中子查询的一部分

  • SUBQUERY: the first select in a subquery

    SUBQUERY ：子查询中的第一个选择

  • UNION: the select is the second or later statement of a union.

    UNION ：select是UNION的第二个或更高版本的语句。

  The full list of values that can appear in a select_type field can be found here.

  可以在select_type字段中显示的值的完整列表可以在此处找到。

• table: the table referred to by the row.

  table ：该行引用的表。

• type: this field is how MySQL joins the tables used. This is probably the most important field in the explain output. It can indicate missing indexes and it can also show how the query should be rewritten. The possible values for this field are the following (ordered from the best type to the worst):

  type ：此字段是MySQL如何联接使用的表的方式。 这可能是解释输出中最重要的字段。 它可以指示丢失的索引，还可以显示应该如何重写查询。 该字段的可能值如下(从最佳类型到最差类型)：

  • system: the table has zero or one row.

    system ：表有零或一行。

  • const: the table has only one matching row which is indexed. The is the fastest type of join.

    const ：表只有一个匹配的行被索引。 是最快的联接类型。

  • eq_ref: all parts of the index are being used by the join and the index is either PRIMARY_KEY or UNIQUE NOT NULL.

    eq_ref ： eq_ref正在使用索引的所有部分，索引为PRIMARY_KEY或UNIQUE NOT NULL。

  • ref: all the matching rows of an index column are read for each combination of rows from the previous table. This type of join normally appears for indexed columns compared with = or <=> operators.

    ref ：从上一个表中为行的每种组合读取索引列的所有匹配行。 与=或<=>运算符相比，这种类型的联接通常出现在索引列中。

  • fulltext: the join uses the table FULLTEXT index.

    fulltext ：联接使用表FULLTEXT索引。

  • ref_or_null: this is the same as ref but also contains rows with a NULL value from the column.

    ref_or_null ：与ref相同，但也包含列中具有NULL值的行。

  • index_merge: the join uses a list of indexes to produce the result set. The KEY column of the explain will contain the keys used.

    index_merge ： index_merge使用索引列表来生成结果集。 的键列explain将包含使用的密钥。

  • unique_subquery: an IN subquery returns only one result from the table and makes use of the primary key.

    unique_subquery ：IN子查询仅从表中返回一个结果，并使用主键。

  • range: an index is used to find matching rows in a specific range.

    range ：索引用于查找特定范围内的匹配行。

  • index: the entire index tree is scanned to find matching rows.

    index ：扫描整个索引树以找到匹配的行。

  • all: the entire table is scanned to find matching rows for the join. This is the worst type of join and often indicates the lack of appropriate indexes on the table.

    all ：扫描整个表以查找匹配的行。 这是最糟糕的联接类型，通常表明表上缺少适当的索引。

• possible_keys: shows the keys that can be used by MySQL to find rows from the table. These keys may or may not be used in practice.

  possible_keys ：显示MySQL可以用来从表中查找行的键。 这些密钥在实践中可能会也可能不会使用。

• keys: indicates the actual index used by MySQL. MySQL always looks for an optimal key that can be used for the query. While joining many tables, it may figure out some other keys which are not listed in possible_keys but are more optimal.

  keys ：指示MySQL使用的实际索引。 MySQL始终在寻找可用于查询的最佳键。 虽然加入很多表，也可以找出未列出的一些其他键possible_keys但更优化。

• key_len: indicates the length of the index the query optimizer chose to use.

  key_len ：指示查询优化器选择使用的索引长度。

• ref: Shows the columns or constants that are compared to the index named in the key column.

  ref ：显示与键列中命名的索引进行比较的列或常量。

• rows: lists the number of records that were examined to produce the output. This is a very important indicator; the fewer records examined, the better.

  rows ：列出检查以产生输出的记录数。 这是一个非常重要的指标； 检查的记录越少越好。

• Extra: contains additional information. Values such as Using filesort or Using temporary in this column may indicate a troublesome query.

  Extra ：包含其他信息。 此列中的值(例如， Using filesort或Using temporary可能表示查询很麻烦。

The full documentation on the explain output format may be found on the official MySQL page.

有关explain输出格式的完整文档，请参见MySQL的官方页面 。

Going back to our simple query: it is a SIMPLE type of select with a const type of join. This is the best case of query we can possibly have. But what happens when we need bigger and more complex queries?

回到我们简单的查询：这是带有连接常量类型的select的SIMPLE类型。 这是我们可能拥有的查询的最佳情况。 但是，当我们需要更大，更复杂的查询时会发生什么呢？

Going back to our application schema, we might want to obtain all gallery images. We also might want to have only photos that contain the word “cat” in the description. This is definitely a case that we could find on the project requirements. Let’s take a look at the query:

回到我们的应用程序架构，我们可能想要获取所有画廊图像。 我们还可能只希望描述中包含“猫”一词的照片。 我们可以在项目需求中找到这种情况。 让我们看一下查询：

SELECT gal.name, gal.description, img.filename, img.description FROM `homestead`.`users` AS users
LEFT JOIN `homestead`.`galleries` AS gal ON users.id = gal.user_id
LEFT JOIN `homestead`.`images` AS img on img.gallery_id = gal.id
WHERE img.description LIKE '%dog%';

In this more complex case we should have some more information to analyze on our explain:

在这种更复杂的情况下，我们应该在explain有更多信息可供分析：

EXPLAIN SELECT gal.name, gal.description, img.filename, img.description FROM `homestead`.`users` AS users
LEFT JOIN `homestead`.`galleries` AS gal ON users.id = gal.user_id
LEFT JOIN `homestead`.`images` AS img on img.gallery_id = gal.id
WHERE img.description LIKE '%dog%';

This gives the following results (scroll right to see all cells):

这给出以下结果(向右滚动以查看所有单元格)：

Let’s take a closer look and see what we can improve in our query.

让我们仔细看看，看看我们可以在查询中改进什么。

As we saw earlier, the main columns we should look at first are the type column and the rows columns. The goal should get a better value in the type column and reduce as much as we can on the rows column.

如前所述，我们首先要看的主要列是type列和rows 。 目标应该在type列中获得更好的价值，并在rows尽可能减少。

Our result on the first query is index, which is not a good result at all. This means we can probably improve it.

我们在第一个查询中的结果是index ，这根本不是一个好结果。 这意味着我们可能可以改善它。

Looking at our query, there are two ways of approaching it. First, the Users table is not being used. We either expand the query to make sure we’re targeting users, or we should completely remove the users part of the query. It is only adding complexity and time to our overall performance.

查看我们的查询，有两种方法来处理它。 首先，不使用Users表。 我们要么扩展查询以确保我们定位到用户，要么完全删除查询中的users部分。 这只会增加我们的整体性能的复杂性和时间。

SELECT gal.name, gal.description, img.filename, img.description FROM `homestead`.`galleries` AS gal
LEFT JOIN `homestead`.`images` AS img on img.gallery_id = gal.id
WHERE img.description LIKE '%dog%';

So now we have the exact same result. Let’s take a look at explain:

所以现在我们得到了完全相同的结果。 让我们来看看explain ：

We are left with an ALL on type. While ALL might be the worst type of join possible, there are also times where it’s the only option. According to our requirements, we want all gallery images, so we need to scour through the whole galleries table. While indexes are really good when trying to find particular information on a table, they can’t help us when we need all the information in it. When we have a case like this, we have to resort to a different method, like caching.

我们只剩下ALL类型。 尽管ALL可能是最糟糕的连接类型，但有时它也是唯一的选择。 根据我们的要求，我们需要所有画廊的图像，因此我们需要浏览整个画廊表。 虽然索引在尝试在表上查找特定信息时确实非常好，但是当我们需要其中的所有信息时它们对我们没有帮助。 当遇到这样的情况时，我们必须求助于另一种方法，例如缓存。

One last improvement we can make, since we’re dealing with a LIKE, is to add a FULLTEXT index to our description field. This way, we could change the LIKE to a match() and improve performance. More on full-text indexes can be found here.

既然我们正在处理LIKE ，我们可以做的最后一个改进就是将FULLTEXT索引添加到我们的description字段中。 这样，我们可以将LIKE更改为match()并提高性能。 有关全文索引的更多信息，请参见此处 。

There are also two very interesting cases we must look at: the newest and related functionality in our application. These apply to galleries and touch on some corner cases that we should be aware of:

我们还必须考虑两种非常有趣的情况：应用程序中的newest功能和related功能。 这些适用于画廊，并涉及一些我们应该注意的极端情况：

EXPLAIN SELECT * FROM `homestead`.`galleries` AS gal
LEFT JOIN `homestead`.`users` AS u ON u.id = gal.user_id
WHERE u.id = 1
ORDER BY gal.created_at DESC
LIMIT 5;

The above is for the related galleries.

以上是针对相关画廊的。

EXPLAIN SELECT * FROM `homestead`.`galleries` AS gal
ORDER BY gal.created_at DESC
LIMIT 5;

The above is for the newest galleries.

以上是最新的画廊。

At first sight, these queries should be blazing fast because they’re using LIMIT. And that is the case on most queries using LIMIT. Unfortunately for us and our application, these queries are also using ORDER BY. Because we need to order all the results before limiting the query, we lose the advantages of using LIMIT.

乍一看，这些查询应该很快，因为它们使用的是LIMIT 。 大多数使用LIMIT查询就是这种情况。 不幸的是，对于我们和我们的应用程序，这些查询也使用ORDER BY 。 因为我们需要在限制查询之前对所有结果进行排序，所以我们失去了使用LIMIT的优势。

Since we know ORDER BY might be tricky, let’s apply our trusty explain.

由于我们知道ORDER BY可能很棘手，因此让我们应用值得信赖的explain 。

And,

和，

As we can see, we have the worst case of join type: ALL for both of our queries.

如我们所见，联接类型的情况最糟：两个查询都为ALL 。

Historically, MySQL’s ORDER BY implementation, especially together with LIMIT, is often the cause for MySQL performance problems. This combination is also used in most interactive applications with large datasets. Functionalities like newly registered users and top tags normally use this combination.

从历史上看，MySQL的ORDER BY实现(尤其是与LIMIT一起)通常是导致MySQL性能问题的原因。 在具有大型数据集的大多数交互式应用程序中也使用此组合。 新注册用户和顶部标签等功能通常使用此组合。

Because this is a common problem, there’s also a small list of common solutions we should apply to take care of performance issues.

因为这是一个常见问题，所以我们还应使用一小部分常见解决方案来解决性能问题。

• Make sure we’re using indexes. In our case, created_at is a great candidate, since it’s the field we’re ordering by. This way, we have both ORDER BY and LIMIT executed without scanning and sorting the full result set.

  确保我们使用索引 。 在我们的例子中， created_at是一个很好的选择，因为这是我们要排序的字段。 这样，我们就可以执行ORDER BY和LIMIT而无需扫描和排序整个结果集。

• Sort by a column in the leading table. Normally, if the ORDER BY is going by field from the table which is not the first in the join order, then the index can’t be used.

  按行距表中的一列排序 。 通常，如果ORDER BY是按表中的字段(而不是联接顺序中的第一个)按字段进行的，则无法使用索引。

• Don’t sort by expressions. Expressions and functions don’t allow index usage by ORDER BY.

  不要按表达式排序 。 表达式和函数不允许ORDER BY使用索引。

• Beware of a large LIMIT value. Large LIMIT values will force ORDER BY to sort a bigger number of rows. This affects performance.

  当心LIMIT值大 。 较大的LIMIT值将迫使ORDER BY对更多的行进行排序。 这会影响性能。

These are some of the measures we should take when we have both LIMIT and ORDER BY in order to minimize performance issues.

这些是我们同时具有LIMIT和ORDER BY时应采取的一些措施，以最大程度地减少性能问题。

结论 (Conclusion)

As we can see, explain can be very useful for spotting problems in our queries early on. There are a lot of problems that we only notice when our applications are in production and have big amounts of data or a lot of visitors hitting the database. If these things can be spotted early on using explain, there’s much less room for performance problems in the future.

正如我们所看到的， explain对于尽早发现查询中的问题非常有用。 当我们的应用程序在生产中并且有大量数据或访问数据库的访问者很多时，我们才注意到很多问题。 如果可以在使用explain早期发现这些问题，那么将来出现性能问题的空间就更少了。

Our application has all the indexes it needs, and it’s pretty fast, but we now know we can always resort to explain and indexes whenever we need to check for performance boosts.

我们的应用程序具有所需的所有索引，而且速度非常快，但是我们现在知道，只要需要检查性能提升，我们便可以随时使用explain和索引。

翻译自: https://www.sitepoint.com/mysql-performance-indexes-explain/