MySQL事件-性能和局限性

Question

I have set-up a simple event that runs every hour and adds a record like this:

ON SCHEDULE EVERY 1 HOUR STARTS '2015-01-01 00:00:00'
DO
BEGIN
    DECLARE done INT DEFAULT FALSE;
    DECLARE a INT;
    DECLARE cursor_1 CURSOR FOR SELECT item_id FROM item WHERE NOW()>expiration_date AND has_expired = 0;
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

    OPEN cursor_1;

    read_loop: LOOP
      FETCH cursor_1 INTO a;
       IF done THEN
         LEAVE read_loop;
       END IF;
       UPDATE item SET has_expired=1 WHERE quote_id=a;
       INSERT INTO item_log (item_id, message) VALUES (a, 'Item is now expired');
    END LOOP;
  END

This thing runs 24 times a day and it works as expected, however, there is another idea to create events dynamically and attach them with a given record, eg

ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 3 WEEK
DO 
BEGIN
   UPDATE item SET has_expired=1 WHERE item_id=232;
   INSERT INTO item_log (item_id, message) VALUES (232, 'Item is now expired');
END

Of course the above would have different values of interval and ids, but that would mean that there are possibly 1000s or tens of thousands of events.

Now, would that be a problem? Limitations and performance wise? I can imagine that if there are no records, or just few created a month then first approach will be constantly running for nothing. However if there will be few items added an hour, then it will mean that DB could reach thousands of one-time events. Would that not cause problems of its own?

Answer 1

Would you like to run that 100% faster? Get rid of it. Instead, have SELECTs include the clause AND (expiration_date < NOW())

OK, so you asked about the code. Here are some comments:

The UPDATE and INSERT need to be in a transaction.

The SELECT needs FOR UPDATE and should be in the transaction, too. But this is less important because, unless you ever change expiration_date, it never matters.

Cursors suck, performance-wise. Select 100 rows to purge, then run one UPDATE and one INSERT.

Scanning the table for this flag will be a slow "table scan" unless you have an index starting with expiration_date.