1.比如，現在有個面試官說，現在線上有個SQL執行很慢，你怎么優化?

這種時候最好分幾步回答，不要一上來就說，該怎么怎么寫SQL，面試時要學會，跳出來，看全貌，裝進去，看本質。

2.慢 SQL 語句的幾種常見誘因?

在這個時候，就可以說，面試官，您好，我覺得SQL慢出現的原因可以分為以下幾種，切記，不要回答自己模糊不清的，沒法自圓其說的即使知道你也別回答，不然就是給自己挖坑。。。

• 無索引、索引失效導致慢查詢

如果表很大，而對where或者order by 后面字段沒有建立索引，那這種情況查起來肯定很費力。但是有時候建立了索引，但在一些特定的場景下，索引還有可能會失效，所以索引失效也是導致慢查詢的主要原因之一。失效場景很多，比如模糊查詢白分號在前、查詢的字段使用了函數或者做了計算操作都有可能導致索引失效。

• 鎖等待

InnoDB 存儲引擎支持行鎖和表鎖，我們要注意行鎖升級為表鎖的可能。在批量更新操作時，行鎖就很可能會升級為表鎖。MySQL 認為如果對一張表使用大量行鎖，會導致事務執行效率下降，從而可能造成其它事務長時間鎖等待和更多的鎖沖突問題發生，致使性能嚴重下降，所以 MySQL 會將行鎖升級為表鎖。還有，行鎖是基于索引加的鎖，如果我們在更新操作時，條件索引失效，那么行鎖也會升級為表鎖。除了鎖升級之外，行鎖相對表鎖來說，雖然粒度更細，并發能力提升了，但也帶來了新的問題，那就是死鎖。

• 不恰當的 SQL 語句

使用不恰當的 SQL 語句也是慢 SQL 最常見的誘因之一。例如，習慣使用 SQL 語句，在大數據表中使用 分頁查詢，以及對非索引字段進行排序等等。對于一些慢的SQL，我該怎么分析?

上面我說了一些關于SQL執行慢的原因，下面就該看看怎么分析這些SQL了

• 找出慢SQL

開啟慢查詢，慢查詢是分析SQL執行慢的常見手段，主要有這幾個參數，slow_query_log：慢查詢開啟狀態，slow_query_log_file：慢查詢日志存放的位置(這個目錄需要MySQL的運行帳號的可寫權限，一般設置為MySQL的數據存放目錄)，long_query_time：查詢超過多少秒才記錄。

• 通過 EXPLAIN 分析 SQL 執行計劃
• 通過 Show Profile 分析 SQL 執行性能

3.平時寫SQL時該注意什么?有什么經驗可談?

到這里，如果面試官還在聽你回答，這時候，你可以適當提高一點語氣，說對于一些慢SQL，有很大一部分是由于我們開發者寫SQL時不注意SQL優化導致的，那么我就說一下我知道的一些注意事項。。。(提高聲音分貝，以防面試官睡著，并敲重點，告訴面試官，我準備裝逼了，哈哈哈。。。)

統計時盡量使用count(*)，count(*)≈count(1)，大于count(主鍵)。

如果明確查找一條語句，請使用limit 1;，因為找到一條符合條件的記錄后就不會繼續查找了。

優化分頁查詢

避免 Select *

用到什么字段就具體寫什么字段，原因除了 select * 查詢所有字段會多出網絡傳輸開銷之外，還有更重要的一點是，select * 無法使用覆蓋索引。

盡量使用 MySQL 5.6以后的版本

對于使用索引方面對索引字段做函數操作或者做運算操作，都不能使用上索引。

所以針對這一點，除了我們索引的字段不要加函數之外。還要注意一些隱式轉換，比如，交易日志表(tradelog)，tradeid 的字段類型是 varchar(32)，字段有索引，但是當你執行 select * from tradelog where tradeid=110717;語句，你發現走的還是全索引掃描。這是因為它其實做了類型轉換，相當于這么執行mysql> select * from tradelog where CAST(tradid AS signed int) = 110717;。隱式字符編碼轉換

如果兩張表使用的編碼集不一致，比如一個是utf8mb4，一個是utf8，那么這兩個字段連接后，相當于做了一次CONVERT(traideid USING utf8mb4),這樣也用不了索引。其實字符集不同只是條件之一，連接過程中要求在被驅動表的索引字段上加函數操作，是直接導致對被驅動表做全表掃描的原因。

4.什么是SQL查詢優化?

答: 查詢優化是一種以某種方式編寫查詢以便可以快速執行的過程。對于任何標準應用而言，這都是重要的一步。

5.有哪些技巧可以提高SQL查詢的性能?

答: 優化SQL查詢可以對性?能帶來實質性的積極影響。它還取決于您所擁有的RDBMS知識水平。現在讓我們看一下調整SQL查詢的一些技巧。

1.盡量不要編寫冗長的查詢，使用視圖和存儲過程，它有助于最大程度地減少網絡負載。

2.最好引入約束而不是觸發器。它們比觸發器更有效，并且可以提高性能。

3.使用表級變量而不是臨時表。

4. UNION ALL子句的響應速度比UNION快。它不會查找重復的行，而UNION語句會查找重復的行，無論它們是否存在。

5.防止使用DISTINCT和HAVING子句。

6.避免過多使用SQL游標。

7.構建存儲過程時，請使用SET NOCOUNT ON子句。它表示受T-SQL語句影響的行。這將導致網絡流量減少。

8.優良作法是返回所需的列而不是表的所有列。

9.最好不要使用復雜的Join，并避免不當地使用觸發器。

10.創建表索引并遵守標準

6.有哪些影響數據庫性能的瓶頸?

答: 在Web應用程序中，數據庫層可能被證明是實現最后一英里可擴展性的關鍵瓶頸。如果數據庫存在性能泄漏，則可能成為瓶頸，并可能導致問題。一些常見的性能問題如下。

1. CPU使用率異常是最明顯的性能瓶頸。但是，您可以通過擴容CPU或替換為高級CPU來修復它。它可能看起來像是一個簡單的問題，但異常的CPU使用率可能導致其他問題。

2.內存不足是下一個最常見的瓶頸。如果服務器無法管理峰值負載，那么它將對性能造成很大的問號。對于任何應用程序來說，執行內存都是至關重要的，因為它比持久性內存要快。同樣，當RAM下降到特定閾值時，操作系統將轉向使用交換內存。但這會使應用程序運行非常緩慢。

您可以通過擴容RAM來解決它，但是如果有內存泄漏，它將無法解決。在這種情況下，您需要分析應用程序，以識別其代碼中的潛在泄漏。

3.對外部存儲設備(如SATA磁盤)的過度依賴也可能成為瓶頸。在將大量數據寫入磁盤時，其影響顯而易見。如果輸出操作非常慢，則很明顯表明問題已成為瓶頸。

在這種情況下，您需要進行擴容，用更快的驅動器替換現有驅動器。嘗試升級到SSD硬盤驅動器或類似產品

以上就是“sql性能優化的相關面試專題”，你能回答上來嗎?如果想要了解更多的Java面試題相關內容，可以關注動力節點Java官網。