Unindexed query on userpoints_txn

This query shows up in the slow query logs on a site I'm working on:

Count         : 1.96k  (2.40%)
Time          : 3984 s total, 2.029547 s avg, 2 s to 3 s max  (1.57%)
  95% of Time : 3728 s total, 2 s avg, 2 s to 2 s max
Lock Time (s) : 0 total, 0 avg, 0 to 0 max  (0.00%)
  95% of Lock : 0 total, 0 avg, 0 to 0 max
Rows sent     : 0 avg, 0 to 0 max  (0.00%)
Rows examined : 543.05k avg, 537.20k to 548.72k max  (2.19%)
Database      : 
Users         : 
  connect@prod1 172.16.100.162 : 100.00% (1963) of query, 99.85% (81732) of all users

Query abstract:
SELECT txn_id, uid, points, time_stamp, operation, description FROM userpoints_txn WHERE status = N AND expired = N AND (expirydate < N AND expirydate != N);

Query sample:
SELECT txn_id, uid, points, time_stamp, operation, description 
          FROM userpoints_txn 
          WHERE status = 0 AND expired = 0 
          AND (expirydate < 1289600109 AND expirydate != 0);

MariaDB [connect]> EXPLAIN SELECT txn_id, uid, points, time_stamp, operation, description FROM userpoints_txn WHERE status = 0 AND expired = 0 AND (expirydate < 1289600109 AND expirydate != 0);
+----+-------------+----------------+------+---------------+--------+---------+-------+--------+-------------+
| id | select_type | table          | type | possible_keys | key    | key_len | ref   | rows   | Extra       |
+----+-------------+----------------+------+---------------+--------+---------+-------+--------+-------------+
|  1 | SIMPLE      | userpoints_txn | ref  | status        | status | 4       | const | 249584 | Using where |
+----+-------------+----------------+------+---------------+--------+---------+-------+--------+-------------+
1 row in set (0.00 sec)

I added an index like such:

ALTER TABLE userpoints_txn ADD INDEX (status, expired, expirydate);

With that index I get:

MariaDB [connect]> EXPLAIN SELECT txn_id, uid, points, time_stamp, operation, description FROM userpoints_txn WHERE status = 0 AND expired = 0 AND (expirydate < 1289600109 AND expirydate != 0);
+----+-------------+----------------+-------+-----------------+----------+---------+------+------+-------------+
| id | select_type | table          | type  | possible_keys   | key      | key_len | ref  | rows | Extra       |
+----+-------------+----------------+-------+-----------------+----------+---------+------+------+-------------+
|  1 | SIMPLE      | userpoints_txn | range | status,status_2 | status_2 | 10      | NULL |   20 | Using where |
+----+-------------+----------------+-------+-----------------+----------+---------+------+------+-------------+
1 row in set (0.00 sec)

So 20 rows vs. 249k.

Here's a patch.