mysql切換數據庫慢（數據庫很慢）

本文目錄一覽：

1、訪問外網的mysql數據庫比較慢是怎麼解決
2、求高手優化MySQL數據庫，數據庫反應太慢。
3、為什麼連接本地mysql數據庫很慢
4、MySQL數據庫服務器逐漸變慢該如何分析與解決
5、mysql數據庫突然變慢數據庫變慢是什麼原因

訪問外網的mysql數據庫比較慢是怎麼解決

服務器放在局域網內進行測試時，數據庫的訪問速度還是很快。但當服務器放到外網後，數據庫的訪問速度就變得非常慢。

後來在網上發現解決方法,my.ini裏面添加

[mysqld]

skip-name-resolve

這樣速度就快了!

skip-name-resolve

選項就能禁用DNS解析，連接速度會快很多。不過，這樣的話就不能在MySQL的授權表中使用主機名了而只能用ip格式。

就MySQL本身而言，問題出在在mysql dns反解析

mysqlshow processlist;

發現有非常多的 unauthenticated user 嘗試做登入使用 mysql 的情況，當這種情況無限制發生時就會造成系統十分緩慢。

查閱mysql官方網站得知，這屬於官方一個系統上的特殊設定，就把他當成mysql的一個bug算了，不管鏈接的的方式是經過 hosts 或是 IP 的模式，他都會對 DNS 做反查。mysqld 會嘗試去反查 IP – dns ，由於反查解析過慢，就會無法應付過量的查詢。

求高手優化MySQL數據庫，數據庫反應太慢。

在開始演示之前，我們先介紹下兩個概念。

概念一，數據的可選擇性基數，也就是常說的cardinality值。

查詢優化器在生成各種執行計劃之前，得先從統計信息中取得相關數據，這樣才能估算每步操作所涉及到的記錄數，而這個相關數據就是cardinality。簡單來說，就是每個值在每個字段中的唯一值分佈狀態。

比如表t1有100行記錄，其中一列為f1。f1中唯一值的個數可以是100個，也可以是1個，當然也可以是1到100之間的任何一個數字。這裡唯一值越的多少，就是這個列的可選擇基數。

那看到這裡我們就明白了，為什麼要在基數高的字段上建立索引，而基數低的的字段建立索引反而沒有全表掃描來的快。當然這個只是一方面，至於更深入的探討就不在我這篇探討的範圍了。

概念二，關於HINT的使用。

這裡我來說下HINT是什麼，在什麼時候用。

HINT簡單來說就是在某些特定的場景下人工協助MySQL優化器的工作，使她生成最優的執行計劃。一般來說，優化器的執行計劃都是最優化的，不過在某些特定場景下，執行計劃可能不是最優化。

比如：表t1經過大量的頻繁更新操作，（UPDATE,DELETE,INSERT），cardinality已經很不準確了，這時候剛好執行了一條SQL，那麼有可能這條SQL的執行計劃就不是最優的。為什麼說有可能呢？

來看下具體演示

譬如，以下兩條SQL，

A：

select * from t1 where f1 = 20;

B：

select * from t1 where f1 = 30;

如果f1的值剛好頻繁更新的值為30，並且沒有達到MySQL自動更新cardinality值的臨界值或者說用戶設置了手動更新又或者用戶減少了sample page等等，那麼對這兩條語句來說，可能不準確的就是B了。

這裡順帶說下，MySQL提供了自動更新和手動更新表cardinality值的方法，因篇幅有限，需要的可以查閱手冊。

那回到正題上，MySQL 8.0 帶來了幾個HINT，我今天就舉個index_merge的例子。

示例表結構：

mysql desc t1;+————+————–+——+—–+———+—————-+| Field | Type | Null | Key | Default | Extra |+————+————–+——+—–+———+—————-+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+————+————–+——+—–+———+—————-+7 rows in set (0.00 sec)

表記錄數：

mysql select count(*) from t1;+———-+| count(*) |+———-+| 32768 |+———-+1 row in set (0.01 sec)

這裡我們兩條經典的SQL：

SQL C：

select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;

表t1實際上在rank1,rank2,rank3三列上分別有一個二級索引。

那我們來看SQL C的查詢計劃。

顯然，沒有用到任何索引，掃描的行數為32034，cost為3243.65。

mysql explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “3243.65” }, “table”: { “table_name”: “t1”, “access_type”: “ALL”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “rows_examined_per_scan”: 32034, “rows_produced_per_join”: 115, “filtered”: “0.36”, “cost_info”: { “read_cost”: “3232.07”, “eval_cost”: “11.58”, “prefix_cost”: “3243.65”, “data_read_per_join”: “49K” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))” } }}1 row in set, 1 warning (0.00 sec)

我們加上hint給相同的查詢，再次看看查詢計劃。

這個時候用到了index_merge,union了三個列。掃描的行數為1103，cost為441.09，明顯比之前的快了好幾倍。

mysql explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “441.09” }, “table”: { “table_name”: “t1”, “access_type”: “index_merge”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “union(idx_rank1,idx_rank2,idx_rank3)”, “key_length”: “5,5,5”, “rows_examined_per_scan”: 1103, “rows_produced_per_join”: 1103, “filtered”: “100.00”, “cost_info”: { “read_cost”: “330.79”, “eval_cost”: “110.30”, “prefix_cost”: “441.09”, “data_read_per_join”: “473K” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))” } }}1 row in set, 1 warning (0.00 sec)

我們再看下SQL D的計劃：

不加HINT，

mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “534.34” }, “table”: { “table_name”: “t1”, “access_type”: “ref”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “idx_rank1”, “used_key_parts”: [ “rank1” ], “key_length”: “5”, “ref”: [ “const” ], “rows_examined_per_scan”: 555, “rows_produced_per_join”: 0, “filtered”: “0.07”, “cost_info”: { “read_cost”: “478.84”, “eval_cost”: “0.04”, “prefix_cost”: “534.34”, “data_read_per_join”: “176” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))” } }}1 row in set, 1 warning (0.00 sec)

加了HINT，

mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “5.23” }, “table”: { “table_name”: “t1”, “access_type”: “index_merge”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “intersect(idx_rank1,idx_rank2,idx_rank3)”, “key_length”: “5,5,5”, “rows_examined_per_scan”: 1, “rows_produced_per_join”: 1, “filtered”: “100.00”, “cost_info”: { “read_cost”: “5.13”, “eval_cost”: “0.10”, “prefix_cost”: “5.23”, “data_read_per_join”: “440” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))” } }}1 row in set, 1 warning (0.00 sec)

對比下以上兩個，加了HINT的比不加HINT的cost小了100倍。

總結下，就是說表的cardinality值影響這張的查詢計劃，如果這個值沒有正常更新的話，就需要手工加HINT了。相信MySQL未來的版本會帶來更多的HINT。

為什麼連接本地mysql數據庫很慢

有兩個myslq數據庫，分別裝在了兩個服務器上，即210249；

其他服務器上連接數據庫，發現249的數據庫連接很慢，而210正常；結果是：249數據庫出了問題。

嘗試的解決辦法：1.重啟apache （在/usr/local/apache/bin 下 apachectl -k restart) 不管用；2.重啟數據庫所在服務器（在Linux下輸入reboot）不管用；

3.在網上搜帖子「連接mysql數據庫速度很慢的原因，發現mysql就會試圖去解析來訪問的機器的domain name,在經歷一段時間後才取出數據．在網上找了很久才發現，一個參數：skip-name-resolve,在mysql的配置文件my.cnf中,在[mysqld]下面加上這個配置就可以了．前不久斷網時登錄內類系統後台奇慢的問題，也是由這個原因引起的。」

首先找到mysql的配置文件my.cnf，在/etc/下，按照帖子的方法，修改【mysqld】，加上了skip-name-resolve；然後重啟MySQL，先關閉：在/bin/下 mysqladmin -uroot -p密碼 shutdown， ps aux|grep mysql 觀察mysql是否被關閉，啟動：mysqld_safe ；重啟過後，管用

訪問速度很快~~

這裡推薦安全的重啟方法

$mysql_dir/bin/mysqladmin -u root -p shutdown

$mysql_dir/bin/safe_mysqld

mysqladmin和mysqld_safe位於Mysql安裝目錄的bin目錄下，很容易找到的。

MySQL數據庫服務器逐漸變慢該如何分析與解決

MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。

臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。

mysql數據庫突然變慢數據庫變慢是什麼原因

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：

原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/158995.html

mysql切換數據庫慢（數據庫很慢）

本文目錄一覽：

訪問外網的mysql數據庫比較慢是怎麼解決

求高手優化MySQL數據庫，數據庫反應太慢。

為什麼連接本地mysql數據庫很慢

MySQL數據庫服務器逐漸變慢 該如何分析與解決

mysql數據庫突然變慢 數據庫變慢是什麼原因

相關推薦

發表回復

MySQL數據庫服務器逐漸變慢該如何分析與解決

mysql數據庫突然變慢數據庫變慢是什麼原因