| 37588 |
amit |
1 |
-- Covering index for the GRN-pending component of the partner investment sweep.
|
|
|
2 |
--
|
|
|
3 |
-- The sweep runs this every 2 minutes for every active partner:
|
|
|
4 |
--
|
|
|
5 |
-- SELECT o.customer_id, SUM(o.total_amount)
|
|
|
6 |
-- FROM transaction.`order` o
|
|
|
7 |
-- JOIN fofo.fofo_store fs ON fs.id = o.customer_id
|
|
|
8 |
-- WHERE o.partner_grn_timestamp IS NULL
|
|
|
9 |
-- AND o.refund_timestamp IS NULL
|
|
|
10 |
-- AND o.billing_timestamp >= '2017-04-01'
|
|
|
11 |
-- GROUP BY o.customer_id;
|
|
|
12 |
--
|
|
|
13 |
-- Before this index there was NO index on transaction.`order` containing
|
|
|
14 |
-- partner_grn_timestamp at all, so the optimiser drove off (customer_id, created_timestamp) and
|
|
|
15 |
-- fetched every candidate row to evaluate the filter, then sorted for the GROUP BY
|
|
|
16 |
-- ("Using temporary; Using filesort"). Forcing the billing index instead only moved it from
|
|
|
17 |
-- 1,461ms to 1,258ms, because none of the existing indexes cover the filter columns.
|
|
|
18 |
--
|
|
|
19 |
-- Column order: customer_id leads so the join and GROUP BY are satisfied in index order (no
|
|
|
20 |
-- filesort); the two IS NULL predicates are equality matches so they precede the billing_timestamp
|
|
|
21 |
-- range; total_amount is carried to make the index covering.
|
|
|
22 |
--
|
|
|
23 |
-- ALGORITHM=INPLACE, LOCK=NONE keeps the table readable and writable throughout (MySQL 5.7).
|
|
|
24 |
-- Reversible: DROP INDEX idx_order_grn_pending ON transaction.`order`;
|
|
|
25 |
|
|
|
26 |
ALTER TABLE transaction.`order`
|
|
|
27 |
ADD INDEX idx_order_grn_pending
|
|
|
28 |
(customer_id, partner_grn_timestamp, refund_timestamp, billing_timestamp, total_amount),
|
|
|
29 |
ALGORITHM=INPLACE, LOCK=NONE;
|