Use cases should be

• For startup : clean temp table(not by create temporary table but normal one for temporary data purpose), create preset daily data insertion for query boost up
• For shutdown : rebuild table (by query 'OPTIMIZE NO_WRITE_TO_BINLOG TABLE tt_a') and batch job before end up.

A need to consider some points are:

• What if got an error or warning when do something while shutdown event, how to handle it? stop shutting down or?
• On windows environment, usually the db gets shutdown signal when OS shutting down. What if the shutdown 'OPTIMIZE' script take....an hour or more, can the MariaDB hold the shutting down until it finishes?

MariaDB can already have a very slow shutdown (e.g. flushing a big InnoDB buffer pool, if it's enabled) and it can have errors during shutdown. These new cases won't be any conceptually different.

Depends on how OS is configured, it can forcefully kill the slow process or it can wait

@Sergei Golubchik,

Let me correct the term to go further.
My term the 'Trigger' means literally 'triggering' action not the TRIGGER on behalf of table.
For 'Startup' or 'Shutdown' is that to execute any of procedure, function, or even normal queries that
the normal EVENT can do.
So the implementation should not be part of the TRIGGER. but part of EVENT.
Is that reasonable for all of us? That is why I used the word 'event scheduler' in the very first context.
------
Don't keep get confuse with the word 'trigger' what we are talking about is the EVENT which already exsist. but triggerring time setting enhancement for startup/shutdown.

I think the word "trigger" is just a general way of describing the commands.

The end result will be that you will be able to execute any procedure, function, query, etc. after the server startup and before the server shutdown automatically.

Does that meet your needs?

Correct.