索引但在查詢期間仍然很慢

我有一個儲存 REST 請求和響應的表：

CREATE TABLE ws_call_logs
(
  id                 BIGINT         NOT NULL,
  ws_method_id       BIGINT         NOT NULL,
  device_id          BIGINT,
  session_id         BIGINT,
  corr_id            BIGINT,
  request            MEDIUMBLOB,
  response           MEDIUMBLOB,
  http_status_code   INT UNSIGNED   NOT NULL,
  processing_status  CHAR(1)        NOT NULL,
  created_timestamp  DATETIME       NOT NULL
)

我創建了 4 個索引，代表我通常執行的 4 個查詢：

CREATE INDEX ix_corr_id_timstamp ON ws_call_logs (corr_id, created_timestamp);
CREATE INDEX ix_corr_method_timstamp ON ws_call_logs(corr_id, ws_method_id, created_timestamp);
CREATE INDEX ix_corr_id_status_timstamp ON ws_call_logs (corr_id, http_status_code, created_timestamp);
CREATE INDEX ix_corr_method_status_timstamp ON ws_call_logs (corr_id, ws_method_id, http_status_code, created_timestamp);

這是查詢：

SELECT *
FROM
  ws_call_logs
WHERE
  (corr_id is not null
     AND http_status_code > 200
     AND created_timestamp >= '2015-11-01 23:00:00'  
     AND created_timestamp <= '2015-11-30 23:00:00'
  ) 
ORDER BY
  created_timestamp
DESC LIMIT 25;

我期望它應該很快，因為它應該使用我創建的第三個索引。但它似乎不是，它需要大約 1 分鐘才能返回。

任何人都可以發現問題所在嗎？或任何提示如何調試？

任何其他優化查詢的技巧將不勝感激。

首先你需要什麼，檢查查詢的解釋計劃：

EXPLAIN SELECT *
FROM
  ws_call_logs
WHERE
  (corr_id is not null
     AND http_status_code > 200
     AND created_timestamp >= '2015-11-01 23:00:00'  
     AND created_timestamp <= '2015-11-30 23:00:00'
  ) 
ORDER BY
  created_timestamp
DESC LIMIT 25;

它返回有關目前 MySQL 將在執行查詢時使用哪些索引的資訊

比你檢查索引的基數

SHOW INDEX FROM ws_call_logs

它讓您知道 - 在這種情況下使用哪個索引更好

沒有關於數據的資訊，一般的想法： - created_timestamp 的索引 - 好的候選人

您可以或僅為 created_timestamp 單獨創建索引，或為 3 列創建索引：core_id、hit_status_code、created_timestamp - 索引中的列必須與查詢中使用的順序相同

最後 SELECT * 沒有給出關於數據大小的想法，即使你請求 25 條記錄，但在伺服器必須按 DESC 對記錄進行排序之前

引用自：https://dba.stackexchange.com/questions/123862