⑴ 如果mysql裡面的數據過多，查詢太慢怎麼辦
問題
我們有一個 SQL，用於找到沒有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎麼辦？
實驗
我們搭建一個 MySQL 5.7 的環境，此處省略搭建步驟。
寫個簡單的腳本，製造一批帶主鍵和不帶主鍵的表：
可以看到執行時間變成了 0.67s。
整理
我們診斷的關鍵點如下：
1. 對於 information_schema 中的元數據表，執行計劃不能提供有效信息。
2. 通過查看 MySQL 改寫後的 SQL，我們猜測了優化器發生了誤判。
3. 我們增加了 hint，指導 MySQL 正確進行優化判斷。
但目前我們的實驗僅限於猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
⑵ MYSQL讀取數據超慢
mysql數據引擎更改為innodb
⑶ 為什麼第一次連接mysql資料庫很慢
兩種可能
第一是 機器本身有太多的進程或者服務導致cpu佔有兩次太高 或者硬碟老化 冗餘數據較多 查詢結果緩慢
第二還有可能是 mysql的設置或者sql語句本身的問題了 看是哪方面的。
⑷ 訪問外網的mysql資料庫比較慢是怎麼解決
後來在網上發現解決方法,my.ini裡面添加
[mysqld]
skip-name-resolve
這樣速度就快了!
skip-name-resolve
選項就能禁用DNS解析，連接速度會快很多。不過，這樣的話就不能在MySQL的授權表中使用主機名了而只能用ip格式。
就MySQL本身而言，問題出在在mysql dns反解析
mysql>show processlist;
| 20681949 | unauthenticated user | 10.10.4.193:52497 | NULL | Connect | | Reading from net | NULL |
| 20681948 | unauthenticated user | 10.10.4.193:52495 | NULL | Connect | | Reading from net | NULL
發現有非常多的 unauthenticated user 嘗試做登入使用 mysql 的情況 ，當這種情況無限制發生時就會造成系統十分緩慢。
查閱mysql官方網站得知，這屬於官方一個系統上的特殊設定，就把他當成mysql的一個bug算了，不管鏈接的的方式是經過 hosts 或是 IP 的模式，他都會對 DNS 做反查。mysqld 會嘗試去反查 IP -> dns ，由於反查解析過慢，就會無法應付過量的查詢。
⑸ mysql資料庫操作耗時很久是什麼原因
Mysql查詢語句慢，執行時間長和等待時間長的原因
沒有索引或沒用好索引(單值索引和復合索引)
關聯查詢太多join，
伺服器調優及各個參數設置（緩沖，線程數等）
⑹ mysql資料庫有100萬+數據，查詢起來很慢了，如何優化
你好，你可以根據條件去添加索引，例如：
一、
所有mysql索引列類型都可以被索引，對來相關類使用索引可以提高select查詢性能，根據mysql索引數，可以是最大索引與最小索引，每種存儲引擎對每個表的至少支持16的索引。總索引長度為256位元組。
mysim和innodb存儲引擎的表默認創建索引都是btree索引，目前mysql還不支持函數索引，但支持前緣索引，對欄位前N個字元創建索引
二、mysql創建索引語法
Create[unioun|fulltext|spatial]indexindexname[usingindextype]ontablename(tablenamecol)
index_col_name:
col_name[(length)][asc|desc]
如果你創建索引時搞錯了，需要修改mysql索引我們可以用alert來修改索引，語法與createindex創建索引差不多，我們就不說了，可以查看相關手冊。
下面我們來看一個關於mysql創建索引實例教程。
mysql>createindexcitynameoncity(city(2));
QueryOk,600rowsaffected(0.26sec)
Records:600Duplicates:0Warings0:
我們現在來以city為條件進行查詢，如下面。
->explainselect*fromcitywherecity='www.111cn.net'G
id:1
......
possible_keys:cityname
key:cityname
好了，現在我們來看看mysql刪除索引等實例
Dropindexnameontablename
實例，我現在要刪除剛才創建city索引
>dropindexcitynameoncity;
Queryok,.....
不過通常對百萬級數據的查詢或者其他操作，都改換其他的大型的資料庫了，希望能幫到你，望採納。
⑺ 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 變數，想法破滅。
⑻ 伺服器上有個2萬條記錄的MySQL數據表，讀取並寫入本地資料庫，怎麼這么慢啊
一次多讀些記錄是對的,還有就是你每次讀記錄時創建的對象要注意清理,關閉或是重用. 要不然這個程序就越來越佔用資源
⑼ 為什麼連接本地mysql資料庫很慢
有兩個myslq資料庫，分別裝在了兩個伺服器上，即210&249；
其他伺服器上連接資料庫，發現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目錄下，很容易找到的。