mysql高水位線問題

標籤：代碼   估計   where   search   images   需要   查詢   百度   問題分析   

資料庫 水位線的概念大家應該都有所瞭解，以前我個人覺得這個基本上是純理論的，跟我們實際開發寫sql好像沒什麼關係。但是在解決一次慢sql的過程中遇到了水位線的問題。  問題現象：功能出現慢查。慢查sql為    DELETE    FROM tb_cust_search_task_detail    WHERE task_id = 2024;  問題分析：大家看了這個sql估計第一反應都是資料量太大了所以導致了慢查，而且會員檢索確實存在資料量很大的問題。所以第一個冒出來的解決方案就是 分批刪除。然後我就看了下大概多少資料量能導致這樣的慢查 一個任務下才3萬多個明細就能導致刪除超過5分鐘？？當時有點懷疑，不過我還是沒有細究，還是按照分批刪除敲代碼了。 敲完代碼當然就是要測試下速度， 在sqladmin裡查發現SELECT * FROM tb_cust_search_task_detail    WHERE task_id = 2024    LIMIT 10000 居然查不出來，超過30秒了。。。。。 EXPLAIN看下 掃描行數居然近億了，總量不是才3萬多麼，也用到索引了，為什麼rows值還是這麼大？？？ 然後看了比這個數量多的其他task_id的執行計畫都是正常的。。 然後我就各種百度了下，越看越覺得可能高水位線的問題。看了下面的背景大家應該都知道為什麼了（這裡說下這個task_id的背景，這個task_id是個週期性任務，每個半小時就會重新檢索一遍，然後把之前的全部delete掉，再insert。這樣就是做很頻繁的delete，insert） 那後面就是要解決怎麼降低這個水位線的問題，如果解決不了，就是改成分批刪除一樣還是慢查。找了DBA一起討論這個問題，dba給的建議就是讓我加個單獨的task_id索引，理由單獨的索引更好查詢更快（可惜後面mysql沒有選用這個索引），順便他做下 表重組，降低高水位線。 重組之後的執行計畫，就很正常了  問題的解決方案： 1. 提交指令碼給dba，讓dba進行表重組，解決目前高水位線的問題2. 針對於周期性的檢索任務，不再採用先全部delete，再insert。不然後面還是有高水位線的問題。 新的方式是 ：重新檢索的資料跟老的對比，該insert的insert，該delete的delete3. 針對於頁面功能重新檢索，編輯的地方，需要刪除檢索明細的（這種刪除次數不是很多的）。改成分批刪除 如果很頻繁的做delete和insert的時候，可能就要考慮下會不會也存在這種隱患問題。

mysql高水位線問題