CREATE EVENT Statement + INTERVAL 1 WEEK  means “every three months, beginning one week from now” . Similarly, you can express “every two weeks, beginning six hours and fifteen minutes from now”  as  EVERY 2 WEEK STARTS CURRENT_TIMESTAMP + INTERVAL ’6:15’ HOUR_MINUTE . Not specifying  STARTS  is the same as using  STARTS CURRENT_TIMESTAMP —that is, the action specified for the event begins repeating immediately upon creation of the event. An  EVERY  clause may contain an optional  ENDS  clause. The  ENDS  keyword is followed by a  timestamp value that tells MySQL when the event should stop repeating. You may also use  + INTERVAL interval  with  ENDS ; for instance,  EVERY 12 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 30 MINUTE ENDS CURRENT_TIMESTAMP + INTERVAL 4 WEEK  is equivalent to “every twelve hours, beginning thirty minutes from now, and ending four weeks from now” . Not using  ENDS  means that the event continues executing indefinitely. ENDS  supports the same syntax for complex time units as  STARTS  does. You may use  STARTS ,  ENDS , both, or neither in an  EVERY  clause. If a repeating event does not terminate within its scheduling interval, the result may be multiple instances of the event executing simultaneously. If this is undesirable, you should institute a mechanism to prevent simultaneous instances. For example, you could use the  GET_LOCK()  function, or row or table locking. The  ON SCHEDULE  clause may use expressions involving built-in MySQL functions and user variables to obtain any of the  timestamp  or  interval  values which it contains. You may not use stored functions or loadable functions in such expressions, nor may you use any table references; however, you may use SELECT FROM DUAL . This is true for both  CREATE EVENT  and  ALTER EVENT  statements. References to stored functions, loadable functions, and tables in such cases are specifically not permitted, and fail with an error (see Bug #22830). Times in the  ON SCHEDULE  clause are interpreted using the current session  time_zone  value. This becomes the event time zone; that is, the time zone that is used for event scheduling and is in effect within the event as it executes. These times are converted to UTC and stored along with the event time zone internally. This enables event execution to proceed as defined regardless of any subsequent changes to the server time zone or daylight saving time effects. For additional information about representation of event times, see Section 25.4.4, “Event Metadata” . See also Section 13.7.7.18, “SHOW EVENTS Statement” , and Section 26.3.14, “The INFORMATION_SCHEMA EVENTS Table” . Normally, once an event has expired, it is immediately dropped. You can override this behavior by specifying  ON COMPLETION PRESERVE . Using  ON COMPLETION NOT PRESERVE  merely makes the default nonpersistent behavior explicit. You can create an event but prevent it from being active using the  DISABLE  keyword. Alternatively, you can use  ENABLE  to make explicit the default status, which is active. This is most useful in conjunction with ALTER EVENT  (see Section 13.1.3, “ALTER EVENT Statement” ). A third value may also appear in place of  ENABLE  or  DISABLE ;  DISABLE ON SLAVE  is set for the status of an event on a replica to indicate that the event was created on the replication source server and replicated to the replica, but is not executed on the replica. See Section 17.5.1.16, “Replication of Invoked Features” . You may supply a comment for an event using a  COMMENT  clause.  comment  may be any string of up to 64 characters that you wish to use for describing the event. The comment text, being a string literal, must be surrounded by quotation marks. The  DO  clause specifies an action carried by the event, and consists of an SQL statement. Nearly any valid MySQL statement that can be used in a stored routine can also be used as the action statement for a scheduled event. (See Section 25.8, “Restrictions on Stored Programs” .) For example, the following 2511