今天遇到的神祕現象, Statistics bottleneck on large table 這篇講得超清楚的, 包含問題和他試過的各種無效方案。我的情境和他差不多, 單純地從一個 table 用 primary key 取出一筆資料, 結果花了 0.02s, 用 profiling 看才發覺都花在 statistics 上, 但 analyze table、用 force index 等方法都無效, 實在是太詭異了。
最後是 drop 掉某個暫時沒用到的 index, 結果就好了。剛好我有好幾個之前實驗用的 index 和兩組一模一樣的 database, 在另一個 database 的同一 table 裡 drop 掉另一個 index, 結果也修正這個問題。無法理解啊。
Btw, 上網查沒看到 statistics 的詳細說明, 印象中 High Performance MySQL 2e 好像有提到過, 不過翻書沒查到什麼東西。印象中說是依 static statistics 和 dynamic statistics 決定如何執行 query。反到在官網 SHOW PROFILES 裡看到, profiling 是企業版沒有的功能。雖說沒有仔細解釋各 state 的含意, 沒有 profiling, 企業版怎麼抓瓶頸啊? 還是有更好的替代工具?
訂閱:
張貼留言 (Atom)
在 Fedora 下裝 id-utils
Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...
-
find -uid 可以找目錄下特定使用者有的檔案, 反過來不知怎麼找。 今天靈機一動, 想到可以這麼搞, 不夠直接, 至少能用就是了: ls -lR DIR | grep "^[-rw]\{10\} " | grep -v USER 2011-01-...
-
昨天意外發現 rsync 有 -z 的參數, 可以壓縮再傳。好奇它的效果就試了一下, 結果得到出人意外的結論: 有時候直接全部重新複製還比較快........, 雖然是很明顯的事實, 用慣 rsync 後到沒想到這點。 簡易的測試環境如下: 原始檔案: 一堆目錄合起來 7G...
-
以使用 LevelDB 為例。 抓好並編好相關檔案,編譯方式見第三方函式庫附的說明: $ ls include/ # header files leveldb/ $ ls out-shared/libleveldb.so* # shared library out-sha...
沒有留言:
張貼留言