MySQL-22：短暫提高效能的方法

22.1短連結風暴

正常的短連線模式就是連線到資料庫後，執行很少的 SQL 語句就斷開，下次需要的時候再重連。

MySQL建立連線的過程：①TCP連線建立，聯結器進行身份驗證；②身份驗證成功，到許可權表中載入資料；

兩個引數： max_connection 和wait_timeout。

1.處理sleep的連線

通過show processlist 可以獲取程式列表，以及狀態。

通過information_schema 庫的 innodb_trx 表 來檢視事務的狀態，這個能表現出kill這個連線是否會有損。

如下情景：

11號執行緒就在事務中，kill掉它，MySQL就只能回滾事務。

2.減少連線消耗

跳過許可權驗證的方法是：重啟資料庫，並使用–skip-grant-tables 引數啟動。這樣，整個 MySQL 會跳過所有的許可權驗證階段，包括連線過程和語句執行過程在內。

23.2 慢查詢效能問題

在 MySQL 中，會引發效能問題的慢查詢，大體有以下三種可能：

1. 索引沒有設計好；
2. SQL 語句沒寫好；
3. MySQL 選錯了索引。

1. 索引沒有設計好

MySQL 5.6 版本以後，建立索引都支援 Online DDL 了 ， 最高效的做法就是直接執行 alter table 語句。

古老的方法：

1. 在備庫 B 上執行 set sql_log_bin=off，也就是不寫 binlog，然後執行 alter table 語句加上索引；
2. 執行主備切換；
3. 這時候主庫是 B，備庫是 A。在 A 上執行 set sql_log_bin=off，然後執行 alter table 語句加上索引。

在需要緊急處理時，上面這個方案的效率是最高的 。你應該考慮類似 gh-ost 這樣的方案，更加穩妥。

2. 語句沒寫好

MySQL 5.7 提供了 query_rewrite 功能，可以把輸入的一種語句改寫成另外一種模式。

query_rewrite外掛安裝

以下場景：

insert into query_rewrite.rewrite_rules(pattern, replacement, pattern_database) values ("select * from t where id + 1 = ?", "select * from t where id = ? - 1", "db1");

call query_rewrite.flush_rewrite_rules();

3.選錯索引

應急方案最佳為加上force index。

前期演練：

1. 上線前，在測試環境，把慢查詢日誌（slow log）開啟，並且把 long_query_time 設定成 0，確保每個語句都會被記錄入慢查詢日誌；

2. 在測試表裡插入模擬線上的資料，做一遍迴歸測試；

3. 觀察慢查詢日誌裡每類語句的輸出，特別留意 Rows_examined 欄位是否與預期一致。

23.3 QPS 突增問題

最理想的情況是讓業務把這個功能下掉，服務自然就會恢復。