『壹』 mysql查看sql執行效率
Explain命令在解決資料庫性能上是第一推薦使用命令，大部分的性能問題可以通過此命令來簡單的解決，Explain可以用來查看 SQL 語句的執行效 果，可以幫助選擇更好的索引和優化查詢語句，寫出更好的優化語句。
Explain語法：explain select … from … [where ...]
例如：explain select * from 表名;
『貳』 一般mysql超過多長時間，會被認為是慢查詢
肯定影響的。
常見查詢慢的原因常見的話會有如下幾種：
1、沒有索引或沒有用到索引。
PS：索引用來快速地尋找那些具有特定值的記錄，所有MySQL索引都以B-樹的形式保存。如果沒有索引，執行查詢時MySQL必須從第一個記錄開始掃描整個表 的所有記錄，直至找到符合要求的記錄。表裡面的記錄數量越多，這個操作的代價就越高。如果作為搜索條件的列上已經創建了索引，MySQL無需掃描任何記錄 即可迅速得到目標記錄所在的位置。如果表有1000個記錄，通過索引查找記錄至少要比順序掃描記錄快100倍。
索引類型：
普通索引：這是最基本的索引類型，沒唯一性之類的限制。
唯一性索引：和普通索引基本相同，但所有的索引列只能出現一次，保持唯一性。
主鍵：主鍵是一種唯一索引，但必須指定為"PRIMARY KEY"。
全文索引：MYSQL從3.23.23開始支持全文索引和全文檢索。在MYSQL中，全文索引的索引類型為FULLTEXT。全文索引可以在VARCHAR或者TEXT類型的列上創建。
2、IO吞吐量小形成了瓶頸。
PS：這是從系統層來分析MYSQL是比較耗IO的。一般資料庫監控也是比較關注IO。
監控命令：$iostat -d -k 1 10
參數 -d 表示，顯示設備（磁碟）使用狀態；-k某些使用block為單位的列強制使用Kilobytes為單位；1 10表示，數據顯示每隔1秒刷新一次，共顯示10次。
『叄』 MySQL怎麼查詢比較耗時的sql語句
開啟慢查詢日誌即可
文件方式配置
MySQL
慢查詢的方法：
在
mysql
配置文件
my.cnf
中增加：
log-slow-queries=/opt/data/slowquery.log
long_query_time=2
log-queries-not-using-indexes
命令方式配置
MySQL
慢查詢的方法：
set
global
slow_query_log=on;
set
global
long_query_time=1;
set
global
slow_query_log_file=『/opt/data/slow_query.log』;
查詢
MySQL
慢查詢狀態的方法：
SHOW
VARIABLES
LIKE
'%query%';
解析
MySQL
慢查詢日誌的方法：
按照
sql
執行時間最長的前
20
條
sql：
mysqlmpslow
-s
t
-t
20
-g
'select'
/opt/data/slowquery.log
『肆』 在MySQL 中，哪些原因導致一條簡單的 SQL 插入耗時很長
Count: 6 Time=25.33s (152s) Lock=0.00s (0s) Rows=0.0 (0), xxx[xxx]@xxx
INSERT INTO tablename(f_uid,uid,create_time) VALUES (N,N,N)
分析原因如下：
1.不可能是鎖等待，因為記錄的Lock時間為0；
2.若是InnoDB引擎，則跟主鍵為啥存在一定關系，但是應該不是特別大，從你的SQL語句看；
3.資料庫主機的負載過高，導致處理不過，是最可能的原因；
『伍』 mysql如何優化以下語句，查詢耗時太久了
一般進行性能分析，分如下三步：
首先需要使用慢查詢日誌功能，去獲取所有查詢時間比較長的SQL語句
其次查看執行計劃查看有問題的SQL的執行計劃 explain
最後可以使用show profile查看有問題的SQL的性能使用情況
慢查詢日誌分析
首先我們要使用慢查詢日誌，因為它收集了查詢時間比較長的SQL語句，但使用之前必須開啟慢查詢日誌，在配置文件my.cnf（一般為/etc/my.cnf）中的[mysqld] 增加如下參數：
slow_query_log=ONlong_query_time=3slow_query_log_file=/var/lib/mysql/slow-log.log復制代碼
增加這些參數之後，重啟MySQL，可以進行查詢慢查詢日誌是否開啟。
1. 任何地方都不要使用 select * from t，用具體的欄位列表代替「*「，不要返回用不到的任何欄位。
2. 索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
3. 並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
4. 盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
5. 盡可能的使用 varchar 代替 char ，因為首先變長欄位存儲空間小，可以節省存儲空間， 其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
6. 如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
7. 對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where和order by相關的列上建立索引。
8. 應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描。
例如： select * from t where num is null
我們可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：select * from t where num=0。
『陸』 mysql中sql語句執行時間怎麼看
右下角的時間是從點擊查詢到輸出查詢結果的總時間，而profile中的是收集在執行語句的時候所使用的資源，包括執行sql時完整的數據查詢邏輯明細及耗時時間，其中包含查詢語句執行時間、索引排序時間、查詢結果展示時間等
『柒』 mysql資料庫性能下降,想找到哪些sql耗時較長,應該如何操作
1、show processlist;
2、select * from information_schema.processlist ;
3、可以在[mysqld]中添加如下：
log =/var/log/mysql.log
如果需要監控慢查詢可以添加如下內容：
log-slow-queries = /var/log/slowquery.log
long_query_time = 1
『捌』 請教：mysql 運行一段時間後速度變慢問題
我們先來看第一個階段，MySQL慢的診斷思路，一般我們會從三個方向來做：
第一個方向是MySQL內部的觀測
第二個方向是外部資源的觀測
第三個方向是外部需求的改造
1.1 MySQL 內部觀測
我們來看MySQL內部的觀測，常用的觀測手段是這樣的，從上往下看，第一部分是Processlist，看一下哪個SQL壓力不太正常，第二步是explain，解釋一下它的執行計劃，第三步我們要做Profilling，如果這個SQL能再執行一次的話, 就做一個Profilling，然後高級的DBA會直接動用performance_schema ，MySQL 5.7 以後直接動用sys_schema，sys_schema是一個視圖，裡面有便捷的各類信息，幫助大家來診斷性能。再高級一點，我們會動用innodb_metrics進行一個對引擎的診斷。
除了這些手段以外，大家還提出了一些亂七八糟的手段，我就不列在這了，這些是常規的一個MySQL的內部的狀態觀測的思路。除了這些以外，MySQL還陸陸續續提供了一些暴露自己狀態的方案，但是這些方案並沒有在實踐中形成套路，原因是學習成本比較高。
1.2 外部資源觀測
外部資源觀測這部分，我引用了一篇文章，這篇文章的二維碼我貼在上面了。這篇文章是國外的一個神寫的，標題是：60秒的快速巡檢，我們來看一下它在60秒之內對伺服器到底做了一個什麼樣的巡檢。一共十條命令，這是前五條，我們一條一條來看。
1.uptime，uptime告訴我們這個機器活了多久，以及它的平均的負載是多少。
2.dmesg -T | tail，告訴我們系統日誌里邊有沒有什麼報錯。
3.vmstat 1，告訴我們虛擬內存的狀態，頁的換進換出有沒有問題，swap有沒有使用。
4. mpstat -P ALL，告訴我們CPU壓力在各個核上是不是均勻的。
5.pidstat 1，告訴我們各個進程的對資源的佔用大概是什麼樣子。
我們來看一下後五條：
首先是iostat-xz 1，查看IO的問題，然後是free-m內存使用率，之後兩個sar，按設備網卡設備的維度，看一下網路的消耗狀態，以及總體看TCP的使用率和錯誤率是多少。最後一條命令top，看一下大概的進程和線程的問題。
這個就是對於外部資源的診斷，這十條命令揭示了應該去診斷哪些外部資源。
1.3 外部需求改造
第三個診斷思路是外部的需求改造，我在這里引用了一篇文檔，這篇文檔是MySQL的官方文檔中的一章，這一章叫Examples of Common Queries，文檔中介紹了常規的SQL怎麼寫, 給出了一些例子。文章的鏈接二維碼在slide上。
我們來看一下它其中提到的一個例子。
它做的事情是從一個表裡邊去選取，這張表有三列，article、dealer、price，選取每個作者的最貴的商品列在結果集中，這是它的最原始的SQL，非常符合業務的寫法，但是它是個關聯子查詢。
關聯子查詢成本是很貴的，所以上面的文檔會教你快速地把它轉成一個非關聯子查詢，大家可以看到中間的子查詢和外邊的查詢之間是沒有關聯性的。
第三步，會教大家直接把子查詢拿掉，然後轉成這樣一個SQL，這個就叫業務改造，前後三個SQL的成本都不一樣，把關聯子查詢拆掉的成本，拆掉以後SQL會跑得非常好，但這個SQL已經不能良好表義了，只有在診斷到SQL成本比較高的情況下才建議大家使用這種方式。
為什麼它能夠把一個關聯子查詢拆掉呢？
這背後的原理是關系代數，所有的SQL都可以被表達成等價的關系代數式，關系代數式之間有等價關系，這個等價關系通過變換可以把關聯子查詢拆掉。
上面的這篇文檔是一個大學的教材，它從頭教了關於代數和SQL之間的關系。然後一步步推導怎麼去簡化這句SQL。
第一，MySQL本身提供了很多命令來觀察MySQL自身的各類狀態，大家從上往下檢一般能檢到SQL的問題或者伺服器的問題。
第二，從伺服器的角度，我們從巡檢的腳本角度入手，伺服器的資源就這幾種，觀測手法也就那麼幾種，我們把伺服器的資源全部都觀察一圈就可以了。
第三，如果實在搞不定，需求方一定要按照資料庫容易接受的方式去寫SQL，這個成本會下降的非常快，這個是常規的MySQL慢的診斷思路。
『玖』 MySQL等資料庫讀取插入的耗時比較，哪種操作耗時較久
對於正常情況的表（主要是建立了合適的索引），寫入要比讀取快許多倍。如果索引建立得不合適，例如缺少必要的索引，那麼查詢速度會變慢，例如過度建立了多餘的索引，插入數據會變慢。