查询数量不为0的sql优化_如何为更快的站点优化SQL查询

朱雀 2022-12-03 08:59 213阅读 0赞

查询数量不为0的sql优化

*This article was originally published on the [Delicious Brains blog][], and is republished here with permission.*

*本文最初发布在[Delicious Brains博客上][Delicious Brains blog] ，并经许可在此处重新发布。*

**You know that a fast site == happier users, improved ranking from Google, and increased conversions. Maybe you even think your WordPress site is as fast as it can be: you’ve looked at site performance, from the [best practices of setting up a server][], to [troubleshooting slow code][], and [offloading your images to a CDN][], but is that everything?**

**您知道，快速的网站==令用户满意，改善了Google的排名并增加了转化次数。** **也许您甚至认为您的WordPress网站速度是最快的：您已经查看了网站的性能，从[设置服务器][best practices of setting up a server]的[最佳实践][best practices of setting up a server]到[对慢速代码][troubleshooting slow code]进行[故障排除][troubleshooting slow code]以及[将图像卸载到CDN][offloading your images to a CDN]的[最佳实践][best practices of setting up a server] ，但这就是一切？**

With dynamic, database-driven websites like WordPress, you might still have one problem on your hands: database queries slowing down your site.

使用诸如WordPress之类的动态数据库驱动网站，您可能仍然会遇到一个问题：数据库查询使您的网站变慢。

In this post, I’ll take you through how to identify the queries causing bottlenecks, how to understand the problems with them, along with quick fixes and other approaches to speed things up. I’ll be using an actual query we recently tackled that was slowing things down on the customer portal of [deliciousbrains.com][].

在本文中，我将带您了解如何识别导致瓶颈的查询，如何理解它们的问题以及快速修复和其他加快处理速度的方法。 我将使用我们最近解决了一个实际的查询放缓下来的东西上的客户门户[deliciousbrains.com][] 。

## 身份证明 **(**Identification**)** ##

The first step in fixing slow SQL queries is to find them. Ashley has [sung the praises][] of the debugging plugin [Query Monitor][] on the blog before, and it’s the database queries feature of the plugin that really makes it an invaluable tool for identifying slow SQL queries. The plugin reports on all the database queries executed during the page request. It allows you to filter them by the code or component (the plugin, theme or WordPress core) calling them, and highlights duplicate and slow queries:

修复慢速SQL查询的第一步是找到它们。 Ashley以前曾在博客上[赞扬][sung the praises]过调试插件[Query Monitor][] [的赞誉][sung the praises] ，而该插件的数据库查询功能确实使它成为识别慢速SQL查询的宝贵工具。 该插件报告页面请求期间执行的所有数据库查询。 它允许您通过调用它们的代码或组件(插件，主题或WordPress核心)来过滤它们，并突出显示重复和慢速查询：

![Query Monitor results][]

If you don’t want to install a debugging plugin on a production site (maybe you’re worried about adding some performance overhead) you can opt to turn on the [MySQL Slow Query Log][], which logs all queries that take a certain amount of time to execute. This is relatively simple to [configure][] and [set up][] where to log the queries to. As this is a server-level tweak, the performance hit will be less that a debugging plugin on the site, but should be turned off when not using it.

如果您不想在生产站点上安装调试插件(也许您担心会增加性能开销)，则可以选择打开[MySQL Slow Query Log][] ，该日志记录所有花费一定时间的查询执行。 这相对容易[配置][configure]和[设置][set up]将查询记录到的位置。 由于这是服务器级的调整，因此对性能的影响将小于站点上的调试插件，但在不使用它时应将其关闭。

## 理解 **(**Understanding**)** ##

Once you have found an expensive query that you want to improve, the next step is to try to understand what is making the query slow. Recently during development to our site, we found a query that was taking around 8 seconds to execute!

找到要改进的昂贵查询后，下一步就是尝试了解导致查询变慢的原因。 最近，在开发我们网站的过程中，我们发现一个查询大约需要8秒钟才能执行！

SELECT
        l.key_id,
        l.order_id,
        l.activation_email,
        l.licence_key,
        l.software_product_id,
        l.software_version,
        l.activations_limit,
        l.created,
        l.renewal_type,
        l.renewal_id,
        l.exempt_domain,
        s.next_payment_date,
        s.status,
        pm2.post_id AS 'product_id',
        pm.meta_value AS 'user_id'
    FROM
        oiz6q8a_woocommerce_software_licences l
            INNER JOIN
        oiz6q8a_woocommerce_software_subscriptions s ON s.key_id = l.key_id
            INNER JOIN
        oiz6q8a_posts p ON p.ID = l.order_id
            INNER JOIN
        oiz6q8a_postmeta pm ON pm.post_id = p.ID
            AND pm.meta_key = '_customer_user'
            INNER JOIN
        oiz6q8a_postmeta pm2 ON pm2.meta_key = '_software_product_id'
            AND pm2.meta_value = l.software_product_id
    WHERE
        p.post_type = 'shop_order'
            AND pm.meta_value = 279
    ORDER BY s.next_payment_date

We use WooCommerce and a customized version of the WooCommerce Software Subscriptions plugin to run our plugins store. The purpose of this query is to get all subscriptions for a customer where we know their customer number. WooCommerce has a somewhat complex data model, in that even though an order is stored as a custom post type, the id of the customer (for stores where each customer gets a WordPress user created for them) is not stored as the `post_author`, but instead as a piece of post meta data. There are also a couple of joins to custom tables created by the software subscriptions plugin. Let’s dive in to understand the query more.

我们使用WooCommerce和WooCommerce软件订阅插件的定制版本来运行我们的插件存储。 该查询的目的是获取我们知道其客户编号的客户的所有订阅。 WooCommerce具有一个稍微复杂的数据模型，即使将订单存储为自定义帖子类型，客户的ID(对于每个客户都有为其创建WordPress用户的商店)也不会存储为`post_author` ，而是作为一段后元数据。 软件订阅插件还创建了一些自定义表联接。 让我们深入了解该查询。

### MySQL是您的朋友 **(**MySQL is your Friend**)** ###

MySQL has a handy statement [`DESCRIBE`][DESCRIBE] which can be used to output information about a table’s structure such as its columns, data types, defaults. So if you execute `DESCRIBE wp_postmeta;` you will see the following results:

MySQL有一个方便的语句[`DESCRIBE`][DESCRIBE] ，可用于输出有关表结构的信息，例如表的列，数据类型，默认值。 因此，如果执行`DESCRIBE wp_postmeta;` 您将看到以下结果：

<table> 
 <thead> 
  <tr> 
   <th>Field</th> 
   <th>Type</th> 
   <th>Null</th> 
   <th>Key</th> 
   <th>Default</th> 
   <th>Extra</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>meta_id</td> 
   <td>bigint(20) unsigned</td> 
   <td>NO</td> 
   <td>PRI</td> 
   <td>NULL</td> 
   <td>auto_increment</td> 
  </tr> 
  <tr> 
   <td>post_id</td> 
   <td>bigint(20) unsigned</td> 
   <td>NO</td> 
   <td>MUL</td> 
   <td>0</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>meta_key</td> 
   <td>varchar(255)</td> 
   <td>YES</td> 
   <td>MUL</td> 
   <td>NULL</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>meta_value</td> 
   <td>longtext</td> 
   <td>YES</td> 
   <td></td> 
   <td>NULL</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th> 领域 </th> 
   <th> 类型 </th> 
   <th> 空值 </th> 
   <th> 键 </th> 
   <th> 默认 </th> 
   <th> 额外 </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td> meta_id </td> 
   <td> bigint(20)无符号 </td> 
   <td> 没有 </td> 
   <td> PRI </td> 
   <td> 空值 </td> 
   <td> 自动递增 </td> 
  </tr> 
  <tr> 
   <td> post_id </td> 
   <td> bigint(20)无符号 </td> 
   <td> 没有 </td> 
   <td> UL </td> 
   <td> 0 </td> 
   <td></td> 
  </tr> 
  <tr> 
   <td> meta_key </td> 
   <td> varchar(255) </td> 
   <td> 是 </td> 
   <td> UL </td> 
   <td> 空值 </td> 
   <td></td> 
  </tr> 
  <tr> 
   <td> meta_value </td> 
   <td> 长文本 </td> 
   <td> 是 </td> 
   <td></td> 
   <td> 空值 </td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

That’s cool, but you may already know about it. But did you know that the `DESCRIBE` statement prefix can actually be used on `SELECT`, `INSERT`, `UPDATE`, `REPLACE` and `DELETE` statements? This is more commonly known by its synonym [`EXPLAIN`][EXPLAIN] and will give us detailed information about how the statement will be executed.

很好，但是您可能已经知道。 但是您是否知道`DESCRIBE`语句前缀实际上可以在`SELECT` ， `INSERT` ， `UPDATE` ， `REPLACE`和`DELETE`语句上使用？ 这通常以其同义词[`EXPLAIN`][EXPLAIN]广为人知，它将为我们提供有关如何执行该语句的详细信息。

Here are the results for our slow query:

以下是我们缓慢查询的结果：

<table> 
 <thead> 
  <tr> 
   <th>id</th> 
   <th>select_type</th> 
   <th>table</th> 
   <th>type</th> 
   <th>possible_keys</th> 
   <th>key</th> 
   <th>key_len</th> 
   <th>ref</th> 
   <th>rows</th> 
   <th>Extra</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>SIMPLE</td> 
   <td>pm2</td> 
   <td>ref</td> 
   <td>meta_key</td> 
   <td>meta_key</td> 
   <td>576</td> 
   <td>const</td> 
   <td>28</td> 
   <td>Using where; Using temporary; Using filesort</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>SIMPLE</td> 
   <td>pm</td> 
   <td>ref</td> 
   <td>post_id,meta_key</td> 
   <td>meta_key</td> 
   <td>576</td> 
   <td>const</td> 
   <td>37456</td> 
   <td>Using where</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>SIMPLE</td> 
   <td>p</td> 
   <td>eq_ref</td> 
   <td>PRIMARY,type_status_date</td> 
   <td>PRIMARY</td> 
   <td>8</td> 
   <td>deliciousbrainsdev.pm.post_id</td> 
   <td>1</td> 
   <td>Using where</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>SIMPLE</td> 
   <td>l</td> 
   <td>ref</td> 
   <td>PRIMARY,order_id</td> 
   <td>order_id</td> 
   <td>8</td> 
   <td>deliciousbrainsdev.pm.post_id</td> 
   <td>1</td> 
   <td>Using index condition; Using where</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>SIMPLE</td> 
   <td>s</td> 
   <td>eq_ref</td> 
   <td>PRIMARY</td> 
   <td>PRIMARY</td> 
   <td>8</td> 
   <td>deliciousbrainsdev.l.key_id</td> 
   <td>1</td> 
   <td>NULL</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th> ID </th> 
   <th> select_type </th> 
   <th> 表 </th> 
   <th> 类型 </th> 
   <th> 可能的钥匙 </th> 
   <th> 键 </th> 
   <th> key_len </th> 
   <th> 参考 </th> 
   <th> 行数 </th> 
   <th> 额外 </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td> 1个 </td> 
   <td> 简单 </td> 
   <td> 下午2 </td> 
   <td> 参考 </td> 
   <td> meta_key </td> 
   <td> meta_key </td> 
   <td> 576 </td> 
   <td> const </td> 
   <td> 28 </td> 
   <td> 在哪里使用 使用临时的； 使用文件排序 </td> 
  </tr> 
  <tr> 
   <td> 1个 </td> 
   <td> 简单 </td> 
   <td> 下午 </td> 
   <td> 参考 </td> 
   <td> post_id，meta_key </td> 
   <td> meta_key </td> 
   <td> 576 </td> 
   <td> const </td> 
   <td> 37456 </td> 
   <td> 在哪里使用 </td> 
  </tr> 
  <tr> 
   <td> 1个 </td> 
   <td> 简单 </td> 
   <td> p </td> 
   <td> eq_ref </td> 
   <td> 主数据，type_status_date </td> 
   <td> 主 </td> 
   <td> 8 </td> 
   <td> Deliciousbrainsdev.pm.post_id </td> 
   <td> 1个 </td> 
   <td> 在哪里使用 </td> 
  </tr> 
  <tr> 
   <td> 1个 </td> 
   <td> 简单 </td> 
   <td> 升 </td> 
   <td> 参考 </td> 
   <td> 主要，order_id </td> 
   <td> order_id </td> 
   <td> 8 </td> 
   <td> Deliciousbrainsdev.pm.post_id </td> 
   <td> 1个 </td> 
   <td> 使用索引条件； 在哪里使用 </td> 
  </tr> 
  <tr> 
   <td> 1个 </td> 
   <td> 简单 </td> 
   <td> s </td> 
   <td> eq_ref </td> 
   <td> 主 </td> 
   <td> 主 </td> 
   <td> 8 </td> 
   <td> Deliciousbrainsdev.l.key_id </td> 
   <td> 1个 </td> 
   <td> 空值 </td> 
  </tr> 
 </tbody> 
</table>

At first glance, this isn’t very easy to interpret. Luckily the folks over at SitePoint have put together a [comprehensive guide to understanding the statement][].

乍一看，这不是很容易解释。 幸运的是，SitePoint上的人们已经汇总了一份[全面的指南，以理解该声明][comprehensive guide to understanding the statement] 。

The most important column is `type`, which describes how the tables are joined. If you see `ALL` then that means MySQL is reading the whole table from disk, increasing I/O rates and putting load on the CPU. This is know as a “full table scan” (more on that later).

最重要的一列是`type` ，它描述了如何联接表。 如果看到`ALL`则表示MySQL正在从磁盘读取整个表，从而提高了I / O速率并给CPU带来了负担。 这被称为“全表扫描”(稍后会详细介绍)。

The `rows` column is also a good indication of what MySQL is having to do, as this shows how many rows it has looked in to find a result.

`rows`列也很好地表明了MySQL要做的事情，因为它显示了它查找了多少行才能找到结果。

`Explain` also gives us more information we can use to optimize. For example, the pm2 table (wp\_postmeta), it is telling us we are `Using filesort`, because we are asking the results to be sorted using an `ORDER BY` clause on the statement. If we were also grouping the query we would be adding overhead to the execution.

`Explain`还为我们提供了可用于优化的更多信息。 例如，pm2表(wp\_postmeta)告诉我们我们正在`Using filesort` ，因为我们要求使用语句上的`ORDER BY`子句对结果进行排序。 如果我们还要对查询进行分组，则会增加执行开销。

### 视觉调查 **(**Visual Investigation**)** ###

[MySQL Workbench][] is another handy, free tool for this type of investigation. For databases running on MySQL 5.6 and above, the results of `EXPLAIN` can be outputted as JSON, and MySQL Workbench turns that JSON into a visual execution plan of the statement:

[MySQL Workbench][]是用于此类调查的另一个方便，免费的工具。 对于在MySQL 5.6及更高版本上运行的数据库， `EXPLAIN`的结果可以作为JSON输出，并且MySQL Workbench将该JSON转换为该语句的可视化执行计划：

![MySQl Workbench Visual Results][]

It automatically draws your attention to issues by coloring parts of the query by cost. We can see straight away that join to the `wp_woocommerce_software_licences` (alias l) table has a serious issue.

通过按成本为查询的各个部分上色，它会自动引起您对问题的注意。 我们可以立即看到加入`wp_woocommerce_software_licences` (别名l)表存在严重问题。

## 解决 **(**Solving**)** ##

That part of the query is performing a full table scan, which you [should try to avoid][], as it uses a non-indexed column `order_id` as the join between the `wp_woocommerce_software_licences` table to the `wp_posts` table. This is a common issue for slow queries and one that can be solved easily.

查询的该部分正在执行全表扫描，您[应尝试避免][should try to avoid]使用该表，因为它使用非索引列`order_id`作为`wp_woocommerce_software_licences`表与`wp_posts`表之间的`wp_woocommerce_software_licences` 。 对于缓慢的查询，这是一个常见问题，可以轻松解决。

### 指标 **(**Indexes**)** ###

`order_id` is a pretty important piece of identifying data in the table, and if we are querying like this we really should have an [index][] on the column, otherwise MySQL will literally scan each row of the table until it finds the rows needed. Let’s add an index and see what that does:

`order_id`是识别表中数据的非常重要的部分，如果我们这样查询，则实际上应该在该列上有一个[索引][index] ，否则MySQL会逐字扫描表的每一行，直到找到所需的行。 让我们添加一个索引，看看能做什么：

CREATE INDEX order_id ON wp_woocommerce_software_licences(order_id)

![SQL results with index][]

Wow, we’ve managed to shave over 5 seconds off the query by adding that index, good job!

哇，通过添加该索引，我们已经成功地将查询时间缩短了5秒钟以上！

### 了解您的查询 **(**Know your Query**)** ###

Examine the query — join by join, subquery by subquery. Does it do things it doesn’t need to? Can optimizations be made?

检查查询-按连接联接，按子查询联接子查询。 它会执行不需要的操作吗？ 可以进行优化吗？

In this case we join the licenses table to the posts table using the `order_id`, all the while restricting the statement to post types of `shop_order`. This is to enforce data integrity to make sure we are only using the correct order records. However, it is actually a redundant part of the query. We know that it’s a safe bet that a software license row in the table has an `order_id` relating to the WooCommerce order in the posts table, as this is enforced in PHP plugin code. Let’s remove the join and see if that improves things:

在这种情况下，我们使用`order_id`将licenses表连接到posts表，同时将语句限制为`shop_order`发布类型。 这是为了确保数据完整性，以确保我们仅使用正确的订单记录。 但是，它实际上是查询的冗余部分。 我们知道，可以肯定的是，表中的软件许可证行具有与posts表中的WooCommerce订单相关的`order_id` ，因为这是在PHP插件代码中强制执行的。 让我们删除联接，看看是否可以改善：

![Query results without redundant join][]

That’s not a huge saving, but the query is now under 3 seconds.

节省不了多少，但是查询现在不到3秒。

### 缓存所有东西！ **(**Cache All The Things!**)** ###

If your server doesn’t have [MySQL query caching][] on by default then it is worth turning on. This means MySQL will keep a record of all statements executed with the result, and if an identical statement is subsequently executed the cached results are returned. The cache doesn’t get stale, as MySQL flushes the cache when tables are changed.

如果您的服务器默认没有启用[MySQL查询缓存][MySQL query caching] ，那么值得启用。 这意味着MySQL将记录所有执行结果的语句，如果随后执行相同的语句，则返回缓存的结果。 缓存不会过时，因为在更改表时MySQL会刷新缓存。

Query Monitor found our query to be running 4 times on a single page load, and although it’s good to have MySQL query caching on, duplicate reads to the database in one request should really be avoided full stop. Static caching in your PHP code is a simple and very effective way to solve this issue. Basically you are fetching the results of a query from the database the first time it is requested and storing them in static property of a class, and then subsequent calls will return the results from the static property:

Query Monitor发现我们的查询在单页加载中运行4次，尽管最好使用MySQL查询进行缓存，但实际上应避免完全停止一次请求中对数据库的重复读取。 PHP代码中的静态缓存是解决此问题的简单有效的方法。 基本上，您是在第一次请求数据库时从数据库中获取查询结果，并将其存储在类的static属性中，然后后续调用将从static属性返回结果：

class WC_Software_Subscription {
    
        protected static $subscriptions = array();
    
        public static function get_user_subscriptions( $user_id ) {
            if ( isset( static::$subscriptions[ $user_id ] ) ) {
                return static::$subscriptions[ $user_id ];
            }
    
            global $wpdb;
    
            $sql = '...';
    
            $results = $wpdb->get_results( $sql, ARRAY_A );
    
            static::$subscriptions[ $user_id ] = $results;
    
            return $results;
        }
    }

The cache has a lifespan of the request, more specifically that of the instantiated object. If you are looking at persisting query results across requests, then you would need to implement a persistent [Object Cache][]. However, your code would need to be responsible for setting the cache, and invalidating the cache entry when the underlying data changes.

缓存具有请求的生命周期，更具体地说，具有实例化对象的生命周期。 如果您正在查看跨请求的持久查询结果，则需要实现持久[对象缓存][Object Cache] 。 但是，您的代码将需要负责设置缓存，并在基础数据发生更改时使缓存条目无效。

### 外箱思考 **(**Thinking Outside the Box**)** ###

There are other approaches we can take to try and speed up query execution that involve a bit more work than just tweaking the query or adding an index. One of the slowest parts of our query is the work done to join the tables to go from customer id to product id, and we have to do this for every customer. What if we did all that joining just once, so we could just grab the customer’s data when we need it?

除了调整查询或添加索引外，我们还有其他方法可以尝试加快查询的执行速度，这些工作涉及更多的工作。 查询中最慢的部分之一是将表连接起来以从客户ID到产品ID的工作，我们必须为每个客户执行此操作。 如果我们只进行了一次所有的连接，以便在需要时就可以获取客户的数据该怎么办？

You could denormalize the data by creating a table that stores the license data, along with the user id and product id for all licenses and just query against that for a specific customer. You would need to rebuild the table using [MySQL triggers][] on `INSERT/UPDATE/DELETE` to the licenses table (or others depending on how the data could change) but this would significantly improve the performance of querying that data.

您可以通过创建一个表来规范化数据，该表用于存储许可证数据以及所有许可证的用户ID和产品ID，并仅针对特定客户进行查询。 您将需要在`INSERT/UPDATE/DELETE`上使用[MySQL触发器][MySQL triggers]将新表重建到许可证表(或其他取决于数据更改方式的表)，但这将大大提高查询该数据的性能。

Similarly, if a number of joins slow down your query in MySQL, it might be quicker to break the query into two or more statements and execute them separately in PHP and then collect and filter the results in code. Laravel does something similar by [eager loading][] relationships in Eloquent.

同样，如果许多联接使MySQL中的查询变慢，则将查询分为两个或多个语句并在PHP中分别执行，然后收集并过滤代码中的结果可能更快。 Laravel [渴望][eager loading]通过在Eloquent中[加载][eager loading]关系来做类似的事情。

WordPress can be prone to slower queries on the `wp_posts` table, if you have a large amount of data, and many different custom post types. If you are finding querying for your post type slow, then consider moving away from the custom post type storage model and to a [custom table][].

如果您有大量数据以及许多不同的自定义帖子类型，则WordPress可能会倾向于对`wp_posts`表的查询变慢。 如果您发现查询帖子类型的速度很慢，请考虑从定制帖子类型存储模型转移到[定制表][custom table] 。

## 结果 **(**Results**)** ##

With these approaches to query optimization we managed to take our query down from 8 seconds down to just over 2 seconds, and reducing the amount of times it was called from 4 to 1. As a note, those query times were recorded when running on our development environment and would be quicker on production.

通过这些查询优化方法，我们设法将查询的时间从8秒减少到2秒多一点，并将调用时间从4秒减少到1秒。注意，这些查询时间是在我们的系统上运行时记录的开发环境，并且可以更快地投入生产。

I hope this has been a helpful guide to tracking down slow queries and fixing them up. Query optimization might seem like a scary task, but as soon as you try it out and have some quick wins you’ll start to get the bug and want to improve things even further.

我希望这对跟踪缓慢的查询并进行修复有帮助。 查询优化可能看起来像是一个可怕的任务，但是一旦您尝试了一下并获得了一些成功，您就会开始发现错误并希望进一步改进。

> 翻译自: [https://www.sitepoint.com/sql-query-optimization-for-faster-sites/][https_www.sitepoint.com_sql-query-optimization-for-faster-sites]

查询数量不为0的sql优化

[Delicious Brains blog]: https://deliciousbrains.com/sql-query-optimization/
[best practices of setting up a server]: https://deliciousbrains.com/hosting-wordpress-setup-secure-virtual-server/
[troubleshooting slow code]: https://deliciousbrains.com/finding-bottlenecks-wordpress-code/
[offloading your images to a CDN]: https://deliciousbrains.com/wp-offload-s3/doc/why-use-a-cdn/
[deliciousbrains.com]: https://deliciousbrains.com
[sung the praises]: https://deliciousbrains.com/finding-bottlenecks-wordpress-code/#query-monitor
[Query Monitor]: https://wordpress.org/plugins/query-monitor/
[Query Monitor results]: /images/20221123/9e23b789e86b40648a4e87397d1bf50f.png
[MySQL Slow Query Log]: https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html
[configure]: https://www.a2hosting.co.uk/kb/developer-corner/mysql/enabling-the-slow-query-log-in-mysql
[set up]: https://dev.mysql.com/doc/refman/5.7/en/log-destinations.html
[DESCRIBE]: https://dev.mysql.com/doc/refman/5.7/en/describe.html
[EXPLAIN]: https://dev.mysql.com/doc/refman/5.7/en/explain.html
[comprehensive guide to understanding the statement]: https://www.sitepoint.com/using-explain-to-write-better-mysql-queries/
[MySQL Workbench]: https://www.mysql.com/products/workbench/
[MySQl Workbench Visual Results]: /images/20221123/d5a7d68569374e4d8a78b2c7b9e87cdf.png
[should try to avoid]: https://dev.mysql.com/doc/refman/5.7/en/table-scan-avoidance.html
[index]: https://dev.mysql.com/doc/refman/5.7/en/mysql-indexes.html
[SQL results with index]: /images/20221123/a0094794368340d8ab23175b4e07242d.png
[Query results without redundant join]: /images/20221123/32bfd0f6608c4f4f985e4d43ac10bb0c.png
[MySQL query caching]: https://dev.mysql.com/doc/refman/5.7/en/query-cache.html
[Object Cache]: https://codex.wordpress.org/Class_Reference/WP_Object_Cache
[MySQL triggers]: https://dev.mysql.com/doc/refman/5.7/en/create-trigger.html
[eager loading]: https://laravel.com/docs/5.5/eloquent-relationships#eager-loading
[custom table]: https://deliciousbrains.com/creating-custom-table-php-wordpress/
[https_www.sitepoint.com_sql-query-optimization-for-faster-sites]: https://www.sitepoint.com/sql-query-optimization-for-faster-sites/