知乎使用者2019-06-27 11:45:40

沒建索引，理論上全表掃描也沒這麼慢

青牛2019-06-28 09:50:54

你好。先join在select，不要用這種子查詢，效率低

xchliu2019-07-01 13:47:26

從提問的角度來說，資訊不全，表結構，資料量，執行場景，服務配置，mysql引數。

從解決問題的角度，profiling可以查，系統負載比如iostat可以查。

從思路上來說：希望達成什麼樣的效能，也就是目標是什麼，可以動用的資源有哪些，比如sql改寫，配置調整等。

stubborn2019-07-05 17:53:49

查詢慢的問題，可以一般可以透過建索引來解決，對你要的欄位建索引（主鍵不需要的，自帶索引），但你這個問題完全不是索引的問題。

你這個v表的結果集很可能就是導致很慢的原因，可以嘗試換個方式寫這個SQL，透過連線join的方式來實現多表查詢。

舉個例子比如說除了t表的資料你還要查這個v表的qc欄位（我是看不清你裡面具體寫的啥，姑且找個看得清的），關聯v表和t表（join起來，那張做主表你自己定，然後你再確定是左連線還是右連線）在where條件中再去決定你要什麼條件下的qc資料。

天闕2021-05-28 18:05:12

首先這個查詢是相關子查詢，在查詢內外部會產生笛卡爾積、巢狀迴圈查詢；如果你的表設計不是很合理的話在排序部分也會產生大量不必要的離散讀、生成大的臨時檔案等好資源的操作產生；雖然你建立了索引但是並不代表你的查詢最佳化器會選擇合理、高效的路徑來檢索資訊；

你子查詢你內部where面查詢條件、範圍查詢等操作；建議貼出你的表結構、索引欄位、索引基數值，這樣為最佳化這個sql能提供更好、更有效的最佳化方式、方法。這個低效的sql如果再生產環境上，對伺服器的資源消耗也是不容小視的；隨著表內部資料的積累，很有可能造成伺服器cpu飆升的風險存在！