基于复合索引和持久列的MySQL查询优化

下面的查询正在MariaDB 10.0.28上运行，耗时约17秒，我希望能大大加快运行速度

select series_id,delivery_date,delivery_he,forecast_date,forecast_he,value 
from forecast where forecast_he=8 
AND series_id in (12142594,20735627,632287496,1146453088,1206342447,1154376340,2095084238,2445233529,2495523920,2541234725,2904312523,3564421486) 
AND delivery_date >= '2016-07-13' 
AND delivery_date < '2018-06-27' 
and DATEDIFF(delivery_date,forecast_date)=1

这似乎缩短了运行时间约2秒，但我想知道是否有更好的方法来大幅加快运行速度。我考虑过调整缓冲区大小，但它似乎没有被严重错误配置

>show variables like '%innodb_buffer_pool_size%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+


Total table size:
+----------+------------+
| Table    | Size in MB |
+----------+------------+
| forecast |    1547.00 |
+----------+------------+

EXPLAIN:
+------+-------------+----------+-------+------------------------------+----------------------+---------+------+--------+-----------------------+
| id   | select_type | table    | type  | possible_keys                | key                  | key_len | ref  | rows   | Extra                 |
+------+-------------+----------+-------+------------------------------+----------------------+---------+------+--------+-----------------------+
|    1 | SIMPLE      | forecast | range | PRIMARY,he_series_delta_date | he_series_delta_date | 11      | NULL | 832016 | Using index condition |
+------+-------------+----------+-------+------------------------------+----------------------+---------+------+--------+-----------------------+

---

如果你要说

AND forecast_delivery_delta=1

然后，最佳索引是从两列开始的索引：

(forecast_he, forecast_delivery_delta,    -- in either order
 series_id,           -- an IN might work ok next
 delivery_date)       -- finally a range

通常，将列（

delivery\u date

）通过范围（而不是最后一个）进行测试是无用的

---

但是请注意，如果你说forecast_delivery_delta，那么这个索引将不会很好地工作。你也可以发布解释“你的查询”的结果吗？我在文章的底部包含了解释的结果。缓冲池大小是128MB，根本没有配置。这是默认值，可以在笔记本电脑或最小尺寸的服务器上使用。这对于任何生产服务器来说可能都是不够的。这使得查询时间从15秒增加到了0.5秒，而缓冲区大小没有任何变化。真的很有帮助，谢谢你，瑞克@dsclough-从我的网站了解更多信息。

(forecast_he, forecast_delivery_delta,    -- in either order
 series_id,           -- an IN might work ok next
 delivery_date)       -- finally a range