你 应该避免 这种全部表浏览的查询，因为他使用非索引字段 order_id 去连接 wp_woocommerce_software_licences 表和 wp_posts 表 。这对于查询慢是常见的问题，而且也是比较容易解决的问题。

　　索引

　　order_id在表中是一个相当重要的标志性数据，如果想像这种方式查询，我们需要在列上建立一个 索引 ，除此之外，MySQL将逐字扫描表的每一行，直到找到我们想要的行为止。让我们添加一个索引并看看它是怎么样工作的：

　　CREATE INDEX order_id ON wp_woocommerce_software_licences(order_id)

　　哇，干的漂亮!我们成功的添加了索引并将查询的时间缩短了5s.

　　了解你的查询语句

　　检查下查询语句——看看每一个join，每一个子查询。它们做了它们不该做的事了吗?这里能做什么优化吗?

　　这个例子中，我们把licenses 表和posts 表通过order_id 连接起来同时限制post type 为shop_order。这是为了通过保持数据的完整性来保证我们只使用正确的订单记录，但是事实上这在查询中是多余的。我们知道这是一个关于安全的赌注，在posts 表中software license 行是通过order_id 来跟 WooCommerce order 相关联的，这在PHP 插件代码中是强制的。让我们移除join 来看看有什么提升没有：

　　提升并不算很大但 现在 查询时间低于3 秒了。

　　缓存一切数据

　　如果你的服务器默认情况下没有使用MySQL查询缓存，那么你应该开启缓存。开启缓存意味着MySQL 会把所有的语句和语句执行的结果保存下来，如果随后有一条与缓存中完全相同的语句需要执行，那么MySQL 就会返回缓存的结果。缓存不会过时，因为MySQL 会在表数据更新后刷新缓存。

　　查询监视器发现在加载一个页面时我们的查询语句执行了四次，尽管有MySQL查询缓存很好，但是在一个请求中重复读取数据库的数据是应该完全避免的。你的PHP 代码中的静态缓存很简单并且可以很高效的解决这个问题。基本上，首次请求时从数据库中获取查询结果，并将其存储在类的静态属性中，然后后续的查询语句调用将从静态属性中返回结果：

　　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;

　　}

　　}

　　缓存有一个生命周期，具体地说是实例化对象有一个生命周期。如果你正在查看跨请求的查询结果，那么你需要实现一个持久对象缓存。然而不管怎样，你的代码应该 负责 设置缓存，并且当基础数据变更时让缓存失效。

　　跳出箱子外思考

　　不仅仅是调整查询或添加索引， 还有其他方法可以加快查询的执行速度。 我们查询的最慢的部分是从客户ID到产品ID再到 加入表格 所做的工作，我们必须为每个客户做到。我们是不是可以在需要的时候抓取客户的数据?如果是那样，那 我们就只需要加入一次。

　　您可以通过创建数据表来存储许可数据，以及所有许可用户标识和产品标识符来对数据进行非规范化(反规范化)处理，并针对特定客户进行查询。 您需要使用INSERT / UPDATE / DELETE上的 MySQL触发器 来重建表格(不过这要取决于数据来更改的表格)，这会显着提高查询数据的性能。

　　类似地，如果一些连接在MySQL中减慢了查询速度，那么将查询分解为两个或更多语句并在PHP中单独执行它们可能会更快，然后可以在代码中收集和过滤结果。 Laravel 通过 预加载 在 Eloquent 中就做了类似的事情。

　　如果您有大量数据和许多不同的自定义帖子类型，WordPress可能会在wp_posts表上减慢查询速度。 如果您发现查询的帖子类型较慢，那么可以考虑从自定义帖子类型的存储模型移动到 自定义表格 中 - 更多内容将在后面的文章中介绍。