MySQL的事宜調劑器應用引見。本站提示廣大學習愛好者：（MySQL的事宜調劑器應用引見）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL的事宜調劑器應用引見正文
自MySQL5.1.0起，增長了一個異常有特點的功效–事宜調劑器(Event Scheduler)，可以用做准時履行某些特定義務，可以看做基於時光的觸發器。
1、開啟
事宜調劑默許是封閉的，開啟可履行
SET GLOBAL event_scheduler=1;
SET GLOBAL event_scheduler=ON;
或許在my.ini文件中加上event_scheduler=1
或許在啟動敕令後加上"-event_scheduler=1"
可以經由過程以下敕令檢查能否已開啟事宜調劑器。
SHOW VARIABLES LIKE 'event_scheduler';
SELECT @@event_scheduler;
2、創立
CREATE EVENT [IF NOT EXISTS] event_name
ON SCHEDULE schedule
[ON COMPLETION [NOT] PRESERVE]
[ENABLE | DISABLE]
[COMMENT 'comment']
DO sql_statement;
schedule:
AT TIMESTAMP [+ INTERVAL INTERVAL]
| EVERY INTERVAL [STARTS TIMESTAMP] [ENDS TIMESTAMP]
INTERVAL:
quantity {YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE |
WEEK | SECOND | YEAR_MONTH
event_name：是你要創立的事宜稱號
schedule：是履行籌劃，有兩個選項，第一是在某一時辰履行，第二是從某時到某時每隔一段時光履行。
INTERVAL：時光距離，可以准確到秒。
ON COMPLETION [NOT] PRESERVE：停止後能否保留，默許不保留，一旦履行完，事宜就被刪除，是以激烈建議此參數設為 ON COMPLETION PRESERVE。
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 5 DAY
是從如今起5往後履行
ON SCHEDULE AT TIMESTAMP '2012-03-07 12:00:00'
在某一詳細時辰履行
ON SCHEDULE EVERY 1 DAY
STARTS CURRENT_TIMESTAMP + INTERVAL 5 DAY
ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
5天後開端天天履行，一個月後停止
CURRENT_TIMESTAMP可以器具體時光調換，好比'2012-03-06 18:00:00'
CREATE EVENT `NewEvent`
ON SCHEDULE EVERY 1 MONTH STARTS '2012-04-01 00:00:00' ENDS '2100-01-01 00:00:00'
ON COMPLETION PRESERVE
ENABLE
DO
update tb_test set amount=100 where id=2;;
這是一個完全的例子。
3、修正
ALTER EVENT event_name
[ON SCHEDULE schedule]
[RENAME TO new_event_name]
[ON COMPLETION [NOT] PRESERVE]
[COMMENT 'comment']
[ENABLE | DISABLE] [DO sql_statement]
ALTER EVENT e_test DISABLE;
封閉e_test事宜。
留意，一旦MySQL重啟，Disable的事宜將全體消逝。
4、刪除
DROP EVENT [IF EXISTS] event_name
不雅察成果:
但是，很顯著，假如用MySQL想要獲得最年夜的潛伏每秒查詢速度，事務應該防止。
讓我們來看一看這是2013年5月我們的每秒最年夜查詢速度。
在統一點八張表停止測試，然則沒有應用MySQL5.6的事物：
不雅察：
而在MySQL5.7上做異樣的測試卻看起來年夜有分歧，由於在5.7中lock_sys互斥鏈接的時光段曾經很低了，同時trx_sys互斥相干代碼也獲得第一次變更的情況：
不雅察成果：
從另外一方面來說，依然有改良的空間這點照樣很清楚的。有關trx_sys的爭用依然在連續。我們沒有充足的應用CPU的才能來做有效的任務（依然有很多CPU周期用在鎖的輪轉）...不外如今的成果比之前很多多少了，而且比5.6好許多，是以沒有來由持續發掘來進步這方面的機能，我們重要集中在我們已經消費了偉大的空間的讀寫負載的機能進步上。
到了5月底，也就是我們的機能會議時代，Sunny給try_sys互斥爭用增長了幾個新的更改，從那今後最年夜的每秒可停止的查詢（QPS）可到達375K！這是否是對5.7停止了足夠的機能進步，對嗎？;-)
同時，我們持續與建議用其他方法治理TRX列表的Percona團隊交流了看法，他們的計劃看起來異常風趣，不外在5.5上，如許的代碼卻不克不及展現出更高的每秒可停止的查詢數（QPS），並且在5.6上的如許代碼（已經測試過Percona Server 5.6）最年夜的每秒可停止的查詢數（QPS）也不會比在MySQL 5.6上年夜。但是，評論辯論觸及到一個風趣的不雅點：假如同時有一些讀寫負載在運轉的話，它對只讀機能有甚麼影響呢？...並且，即便在異樣的測試前提下MySQL 5.7代碼依然運轉的要好一些，後果長短常顯著的（你可以在這兒檢查我的剖析，但是，再次解釋一下，這段時光內我不克不及展現５.7上的成果，由於它的代碼還沒有對年夜眾頒布－或許會在今後的一篇文章中給出）..
因為這兒同時對任何純潔的讀寫負載也有影響，是以有足夠的念頭以Sunnys很長時光所等待的那樣從新寫全部TRX列表相干的代碼，但是，這類閱歷的確讓人癡迷！
;-)) 日復一日，我們很愉快的看到我們的每秒可停止的查詢圖逐步變高，直到在統一個32核的超線程辦事器上到達了每秒可停止的查詢440K!
5.7開辟裡程碑宣布2長進行的Select 8個表所獲得的成果數：
不須要解釋..;-))
但是，有一個小小的使人奇異的處所－我們試圖與Sunny經由過程分歧的對象剖析一切瓶頸和代碼更改所帶來的影響。並且在某些測試裡，令我受驚的是Sunny不雅察到比我更高的每秒可停止的查詢數..這個“奇怪的地方”與上面身分相干：
讓我們來比擬“之前”和“以後”的差別
不雅察成果：
還有甚麼呢？
我能夠只提到：kudos Sunny和全部MySQL的開辟團隊；
讓我們看一下如今選擇8張表任務負載的情形下的最年夜每秒查詢。
每一個引擎都在以下設置裝備擺設下停止測試：
最好的成果是來自隨意率性兩個特定的組合間的比擬。經由過程對數據庫引擎的比擬，我獲得了上面的一個圖表，這個圖表我在之前的文章中曾經提到過了。
面是一些評論：
具有甚麼樣的擴大性呢？
謎底是簡略的：MySQL5.7是獨一在此基本長進行擴大的。
假如應用ip端口和一個分量級的Sysbench-0.4.13，會獲得以下的成果：
QPS只是略微的略低一點，然則整體的趨向是完整一樣的。
可擴大性也長短常的類似：
留意：對一個單表綁定過量的任務負載是欠好的：
還有許多挑釁擺在我們眼前;-)
作為參考，我上述測試的硬件設置裝備擺設信息以下：
my.conf:
max_connections=4000
key_buffer_size=200M
low_priority_updates=1
table_open_cache = 8000
back_log=1500
query_cache_type=0
table_open_cache_instances=16
# files
innodb_file_per_table
innodb_log_file_size=1024M
innodb_log_files_in_group = 3
innodb_open_files=4000
# buffers
innodb_buffer_pool_size=32000M
innodb_buffer_pool_instances=32
innodb_additional_mem_pool_size=20M
innodb_log_buffer_size=64M
join_buffer_size=32K
sort_buffer_size=32K
# innodb
innodb_checksums=0
innodb_doublewrite=0
innodb_support_xa=0
innodb_thread_concurrency=0
innodb_flush_log_at_trx_commit=2
innodb_max_dirty_pages_pct=50
innodb_use_native_aio=1
innodb_stats_persistent = 1
innodb_spin_wait_delay= 6 / 96
# perf special
innodb_adaptive_flushing = 1
innodb_flush_neighbors = 0
innodb_read_io_threads = 4
innodb_write_io_threads = 4
innodb_io_capacity = 4000
innodb_purge_threads=1
innodb_adaptive_hash_index=0
# monitoring
innodb_monitor_enable = '%'
performance_schema=OFF
假如你須要的話，Linux Sysbench的二進制版本在這裡：
應用UNIX socket來運轉Point-Selects測試的Sysbench敕令以下（在parallel中啟動8個過程）：
LD_PRELOAD=/usr/lib64/libjemalloc.so /BMK/sysbench-0.4.8 --num-threads=$1 --test=oltp --oltp-table-size=10000000 \
--oltp-dist-type=uniform --oltp-table-name=sbtest_10M_$n \
--max-requests=0 --max-time=$2 --mysql-socket=/SSD_raid0/mysql.sock \
--mysql-user=dim --mysql-password=dim --mysql-db=sysbench \
--mysql-table-engine=INNODB --db-driver=mysql \
--oltp-point-selects=1 --oltp-simple-ranges=0 --oltp-sum-ranges=0 \
--oltp-order-ranges=0 --oltp-distinct-ranges=0 --oltp-skip-trx=on \
--oltp-read-only=on run > /tmp/test_$n.log &
應用IP端口來運轉Point-Selects測試的Sysbench敕令以下（在parallel中啟動8個過程）：
LD_PRELOAD=/usr/lib64/libjemalloc.so /BMK/sysbench-0.4.13 --num-threads=$1 --test=oltp --oltp-table-size=10000000 \
--oltp-dist-type=uniform --oltp-table-name=sbtest_10M_$n \
--max-requests=0 --max-time=$2 --mysql-host=127.0.0.1 --mysql-port=5700 \
--mysql-user=dim --mysql-password=dim --mysql-db=sysbench \
--mysql-table-engine=INNODB --db-driver=mysql \
--oltp-point-selects=1 --oltp-simple-ranges=0 --oltp-sum-ranges=0 \
--oltp-order-ranges=0 --oltp-distinct-ranges=0 --oltp-skip-trx=on \
--oltp-read-only=on run > /tmp/test_$n.log &
