優化、分析Mysql表讀寫、索引等操做的sql語句效率優化問題

爲何要優化:mysql

隨着實際項目的啓動,數據庫通過一段時間的運行,最初的數據庫設置,會與實際數據庫運行性能會有一些差別,這時咱們 就須要作一個優化調整。sql

數據庫優化這個課題較大,可分爲四大類:數據庫

》主機性能
》內存使用性能
》網絡傳輸性能
》SQL語句執行性能【軟件工程師】
下面列出一些數據庫SQL優化方案:網絡

(01)選擇最有效率的表名順序(筆試常考)函數

數據庫的解析器按照從右到左的順序處理FROM子句中的表名,FROM子句中寫在最後的表將被最早處理,在FROM子句中包含多個表的狀況下,你必須選擇記錄條數最少的表放在最後,若是有3個以上的錶鏈接查詢,那就須要選擇那個被其餘表所引用的表放在最後。性能

例如:查詢員工的編號,姓名,工資,工資等級,部門名學習

select emp.empno,emp.ename,emp.sal,salgrade.grade,dept.dname
from salgrade,dept,emp
where (emp.deptno = dept.deptno) and (emp.sal between salgrade.losal and salgrade.hisal)

 

1)若是三個表是徹底無關係的話,將記錄和列名最少的表,寫在最後,而後依次類推
2)若是三個表是有關係的話,將引用最多的表,放在最後,而後依次類推測試

(02)WHERE子句中的鏈接順序(筆試常考)fetch

數據庫採用自右而左的順序解析WHERE子句,根據這個原理,表之間的鏈接必須寫在其餘WHERE條件之左,那些能夠過濾掉最大數量記錄的條件必須寫在WHERE子句的之右。優化

例如:查詢員工的編號,姓名,工資,部門名

select emp.empno,emp.ename,emp.sal,dept.dname
from emp,dept
where (emp.deptno = dept.deptno) and (emp.sal > 1500)

(03)SELECT子句中避免使用*號

數據庫在解析的過程當中,會將*依次轉換成全部的列名,這個工做是經過查詢數據字典完成的,這意味着將耗費更多的時間

select empno,ename from emp;
(04)用TRUNCATE替代DELETE

(05)儘可能多使用COMMIT

由於COMMIT會釋放回滾點

(06)用WHERE子句替換HAVING子句

WHERE先執行,HAVING後執行

(07)多使用內部函數提升SQL效率

(08)使用表的別名

salgrade s

(09)使用列的別名

ename e

總之,數據庫優化不是一天的課題,你得在長期工做實踐中,進行反覆測試與總結,但願學員們往後好好領會

今天咱們分享一些 分析mysql表讀寫、索引等等操做的sql語句。

閒話很少說,直接上代碼:

反映表的讀寫壓力

SELECT file_name AS file,
count_read,
sum_number_of_bytes_read AS total_read,
count_write,
sum_number_of_bytes_write AS total_written,
(sum_number_of_bytes_read + sum_number_of_bytes_write) AS total
FROM performance_schema.file_summary_by_instance
ORDER BY sum_number_of_bytes_read+ sum_number_of_bytes_write DESC;

反映文件的延遲

SELECT (file_name) AS file,
count_star AS total,
CONCAT(ROUND(sum_timer_wait / 3600000000000000, 2), 'h') AS total_latency,
count_read,
CONCAT(ROUND(sum_timer_read / 1000000000000, 2), 's') AS read_latency,
count_write,
CONCAT(ROUND(sum_timer_write / 3600000000000000, 2), 'h')AS write_latency
FROM performance_schema.file_summary_by_instance
ORDER BY sum_timer_wait DESC;

table 的讀寫延遲

SELECT object_schema AS table_schema,
object_name AS table_name,
count_star AS total,
CONCAT(ROUND(sum_timer_wait / 3600000000000000, 2), 'h') as total_latency,
CONCAT(ROUND((sum_timer_wait / count_star) / 1000000, 2), 'us') AS avg_latency,
CONCAT(ROUND(max_timer_wait / 1000000000, 2), 'ms') AS max_latency
FROM performance_schema.objects_summary_global_by_type
ORDER BY sum_timer_wait DESC;

查看錶操做頻度

SELECT object_schema AS table_schema,
object_name AS table_name,
count_star AS rows_io_total,
count_read AS rows_read,
count_write AS rows_write,
count_fetch AS rows_fetchs,
count_insert AS rows_inserts,
count_update AS rows_updates,
count_delete AS rows_deletes,
CONCAT(ROUND(sum_timer_fetch / 3600000000000000, 2), 'h') AS fetch_latency,
CONCAT(ROUND(sum_timer_insert / 3600000000000000, 2), 'h') AS insert_latency,
CONCAT(ROUND(sum_timer_update / 3600000000000000, 2), 'h') AS update_latency,
CONCAT(ROUND(sum_timer_delete / 3600000000000000, 2), 'h') AS delete_latency
FROM performance_schema.table_io_waits_summary_by_table
ORDER BY sum_timer_wait DESC ;

索引情況

SELECT OBJECT_SCHEMA AS table_schema,
OBJECT_NAME AS table_name,
INDEX_NAME as index_name,
COUNT_FETCH AS rows_fetched,
CONCAT(ROUND(SUM_TIMER_FETCH / 3600000000000000, 2), 'h') AS select_latency,
COUNT_INSERT AS rows_inserted,
CONCAT(ROUND(SUM_TIMER_INSERT / 3600000000000000, 2), 'h') AS insert_latency,
COUNT_UPDATE AS rows_updated,
CONCAT(ROUND(SUM_TIMER_UPDATE / 3600000000000000, 2), 'h') AS update_latency,
COUNT_DELETE AS rows_deleted,
CONCAT(ROUND(SUM_TIMER_DELETE / 3600000000000000, 2), 'h')AS delete_latency
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL
ORDER BY sum_timer_wait DESC;

全表掃描狀況

SELECT object_schema,
object_name,
count_read AS rows_full_scanned
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NULL
AND count_read > 0
ORDER BY count_read DESC;
沒有使用的index

SELECT object_schema,
object_name,
index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL
AND count_star = 0
AND object_schema not in ('mysql','v_monitor')
AND index_name <> 'PRIMARY'
ORDER BY object_schema, object_name;

糟糕的sql問題摘要

SELECT (DIGEST_TEXT) AS query,
SCHEMA_NAME AS db,
IF(SUM_NO_GOOD_INDEX_USED > 0 OR SUM_NO_INDEX_USED > 0, '*', '') AS full_scan,
COUNT_STAR AS exec_count,
SUM_ERRORS AS err_count,
SUM_WARNINGS AS warn_count,
(SUM_TIMER_WAIT) AS total_latency,
(MAX_TIMER_WAIT) AS max_latency,
(AVG_TIMER_WAIT) AS avg_latency,
(SUM_LOCK_TIME) AS lock_latency,
format(SUM_ROWS_SENT,0) AS rows_sent,
ROUND(IFNULL(SUM_ROWS_SENT / NULLIF(COUNT_STAR, 0), 0)) AS rows_sent_avg,
SUM_ROWS_EXAMINED AS rows_examined,
ROUND(IFNULL(SUM_ROWS_EXAMINED / NULLIF(COUNT_STAR, 0), 0)) AS rows_examined_avg,
SUM_CREATED_TMP_TABLES AS tmp_tables,
SUM_CREATED_TMP_DISK_TABLES AS tmp_disk_tables,
SUM_SORT_ROWS AS rows_sorted,
SUM_SORT_MERGE_PASSES AS sort_merge_passes,
DIGEST AS digest,
FIRST_SEEN AS first_seen,
LAST_SEEN as last_seen
FROM performance_schema.events_statements_summary_by_digest d
where d
ORDER BY SUM_TIMER_WAIT DESC
limit 20;

 

掌握這些sql,你能輕鬆知道你的庫那些表存在問題,而後考慮怎麼去優化。

總結

以上就是這篇文章的所有內容了,但願本文的內容對你們的學習或者工做具備必定的參考學習價值,謝謝你們對腳本之家的支持。若是你想了解更多相關內容請查看下面相關連接

相關文章
相關標籤/搜索