問答專欄Q & A COLUMN
視圖的方式可以“簡化”查詢邏輯，讓查詢看起來簡單，但是如果多表查詢性能差，對于視圖的方式來說，要排查性能瓶頸還是比較困難的。所以優化的本質不會變，是基于資源的平衡，簡化不能夠解決性能問題。
評論0
加載中...
加視圖，最后還是查的這幾張表，最好的就是將你需要的數據，通過代碼的方式轉的一張表里面，然后單表操作是最快的，對單表加索引，千萬數據也能查的很快，如果數據量還是很大，還可以做成分區，針對分區去查，檢索速度也會很快
評論0
加載中...
問題
我們有一個 SQL，用于找到沒有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎么辦?
實驗
我們搭建一個 MySQL 5.7 的環境，此處省略搭建步驟。
寫個簡單的腳本，制造一批帶主鍵和不帶主鍵的表：
執行一下腳本：
現在執行以下 SQL 看看效果：
...
執行了 16.80s，感覺是非常慢了。
現在用一下 DBA 三板斧，看看執行計劃：
感覺有點慘，由于 information_schema.columns 是元數據表，沒有必要的統計信息。
那我們來 show warnings 看看 MySQL 改寫后的 SQL：
我們格式化一下 SQL：
可以看到 MySQL 將
select from A where A.x not in (select x from B) //非關聯子查詢
轉換成了
select from A where not exists (select 1 from B where B.x = a.x) //關聯子查詢
如果我們自己是 MySQL，在執行非關聯子查詢時，可以使用很簡單的策略：
select from A where A.x not in (select x from B where ...) //非關聯子查詢:1. 掃描 B 表中的所有記錄，找到滿足條件的記錄，存放在臨時表 C 中，建好索引2. 掃描 A 表中的記錄，與臨時表 C 中的記錄進行比對，直接在索引里比對，
而關聯子查詢就需要循環迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //關聯子查詢掃描 A 表的每一條記錄 rA： 掃描 B 表，找到其中的第一條滿足 rA 條件的記錄。
顯然，關聯子查詢的掃描成本會高于非關聯子查詢。
我們希望 MySQL 能先"緩存"子查詢的結果（緩存這一步叫物化，MATERIALIZATION），但MySQL 認為不緩存更快，我們就需要給予 MySQL 一定指導。
...
可以看到執行時間變成了 0.67s。
整理
我們診斷的關鍵點如下：
1. 對于 information_schema 中的元數據表，執行計劃不能提供有效信息。
2. 通過查看 MySQL 改寫后的 SQL，我們猜測了優化器發生了誤判。
3. 我們增加了 hint，指導 MySQL 正確進行優化判斷。
但目前我們的實驗僅限于猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
