上文（MySQL自我保護工具--pt-kill ） 提到用pt-kill工具來kill相關的會話，來達到保護資料庫的目的，本文再通過修改資料庫參數的方式達到阻斷長時間運作的SQL的目的。
1、參數介紹
mysql5.6及以後,資料庫端新增了新變量來限制語句最大執行時間，用于在服務端對select語句進行逾時時間限制,能有效控制在資料庫（建議在主庫）的慢查詢情況，以達到保護資料庫穩定性的目的。
不過mysql5.7.8版本前後參數名有變更，例如：
mysql5.6 - mysql5.7.8前的版本中，參數名為：max_statement_time （毫秒）
mysql5.7.8及以後，參數改成：max_execution_time （毫秒）
另外，該參數有global 及session 2種級别，即可在部分會話中動态調整本會話的逾時時間。
2. 操作示範
在測試環境建一張大表用來示範，該案例可檢視曆史文章或批量造資料實作。
因目前基本都使用5.7及以後版本，是以本次使用MySQL5.7版本資料庫進行示範。
2.1 參數預設值
mysql> show global variables like 'max_execution_time';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| max_execution_time | 0 |
+--------------------+-------+
1 row in set (0.01 sec) 
預設值為0，代表不限制最大執行時間。
例如執行如下SQL時，運作3s+
mysql> select count(*) from test1;
+----------+
| count(*) |
+----------+
| 21991575 |
+----------+
1 row in set (3.89 sec) 2.2 修改參數示範
修改
mysql> set session max_execution_time=1000;
Query OK, 0 rows affected (0.00 sec)
mysql> show global variables like 'max_execution_time';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| max_execution_time | 0 |
+--------------------+-------+
1 row in set (0.01 sec)
mysql> show variables like 'max_execution_time';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| max_execution_time | 1000 |
+--------------------+-------+
1 row in set (0.00 sec) 本會話的參數（session級别），示範本次會話的情況，這樣不會影響其他會話的運作,如需整個執行個體調整，則修改全局變量即可。
mysql> select count(*) from test1;
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded 此時執行查詢，則會因為超過1s而被中斷
PS：修改全局變量後，注意已經連接配接的會話是不生效的，另外，此參數，隻對select起作用，對DDL及UPDATE、delete操作不生效，例如：
mysql> set session max_execution_time=1000;
Query OK, 0 rows affected (0.00 sec)
mysql> alter table test1 add tt int ;
Query OK, 0 rows affected (25.65 sec)
Records: 0 Duplicates: 0 Warnings: 0 3. 小結
生産環境較常見的情況是業務代碼已經逾時退出了與資料庫的互動，但是資料庫裡依舊運作着發起的SQL，如果頻繁發起重試，則，慢SQL會越來越多，導緻資料庫負載高，影響穩定性及可用性。是以，建議部署pt-kill工具或者修改最大執行時間參數，避免長時間運作select語句運作。
相對于pt-kill工具，修改參數的方式較便捷，但局限性較大，是以需要根據業務需要進行部署。
往期精彩回顧
1. MySQL高可用之MHA叢集部署
2. mysql8.0新增使用者及加密規則修改的那些事
3. 比hive快10倍的大資料查詢利器-- presto
4. 監控利器出鞘：Prometheus+Grafana監控MySQL、Redis資料庫
5. PostgreSQL主從複制--實體複制
6. MySQL傳統點位複制線上轉為GTID模式複制
7. MySQL敏感資料加密及解密
8. MySQL資料備份及還原（一）
9. MySQL資料備份及還原（二）
掃碼關注