※ 引述《JYHuang (夏天到了，冷不起來了說)》之銘言： : 先查詢的會因為回傳慢而後顯示？ : 在PHP那方面有取消資料庫Query的功能嗎？ : client這方面該怎麼防範這種 : 重複執行同一支ajax造成的問題？ : -- : → TonyQ:一個查詢進行中時先lock住 ui , 不要讓使用者改就好. 05/16 18:03 : → TonyQ:多個ajax同時進行中時 , 的確是不能保證順序沒錯. 05/16 18:03 : 推 TonyQ:不然就是你讓checkbox的反應時間慢一點 , ex.兩秒後才反應 05/16 18:14 : → TonyQ:這段期間使用者的異動讓它動這樣. 總的來說 ,減少request跟 05/16 18:14 : → TonyQ:提高 mysql 查詢的效能 (index,減少查詢複雜度) 雙管齊下. 05/16 18:15 : → TonyQ:才能得到比較好的效益. 05/16 18:15 : → JYHuang:效能會低我猜主要是因為資料相當多 05/16 19:41 : ※ JYHuang:轉錄至看板 PHP 05/16 19:42 : → fillano:另一個方法是用queue來管理這些ajax動作，讓他保證循序執 05/16 20:43 : → fillano:行。不過我怕如果多了，說不定放在queue裡面的東西越來越 05/16 20:44 : → fillano:多...所以lock住ui是第一個選擇，除非對方要求... 05/16 20:45 : → JYHuang:我提出的方案也是lock ui，不過不被接受 = =" 05/16 20:54 這個大概只能用硬解（至少小弟也只想的到這種…囧） client 端的硬解有幾種，其一是 T 大的 ui lock， 另一種是費大的 request queue， 不過如果是小弟的話，會視情況在 request queue 上做一些手腳， 也就是每一個 ui event / action 轉成 request 進入 queue 的時候， 都先 hold 住 2 秒（或 1 秒半或任何比較好的秒數）， 如果確認沒有新的 request 送過來，就視為正確然後放他進 queue， 不然就更新當下的 request 並且再多 hold 住 1 秒。 （因為連續性操作有可能是使用者在更新前次的操作失誤） 伺服器端的硬解就比較麻煩了，我們將他拆成兩個情況檢討， 如果是屬於多層次的運算程序，可以在各運算之間插入檢查點， 也就是預先準備一個 table 或 file 或 mem 的 cache， 新進的 request 會去產生異動記錄，讓運算間的檢查點做 check， 發現有新的 request 就放棄所有已做過的運算全部重來一次 （也可以視情況不理會，先丟出一個階段性的結果， 偽裝成 ui 的過度操作導致 server 沒有收到訊號或著什麼的… :p ） 如果伺服端的運算是屬於直深式的那就很難做了， （譬如一組複雜的 SQL 就進去拉結果資料） 當然你可以 show processlist 做 filter 然後 kill（在 mysql 下）， 但若用這種危險到不行的動作，還不如直接讓他算完吧… orz 這邊能避免的也只有，如果後面有進來新的 request ， 在送出資料前做剛剛提到的最後一次異動檢查， 假如需求被更新了，那是不是要放棄目前的結果集再重新撈一次。 講個比較不負責任的東西 XDD 如果這些 checkbox 的觸發，是在對原本的 query 做 filter 或擴展， 那麼上面提到的伺服器端的重新運算，其實可以分別降低成 將已取得的結果集篩選後傳回（如果是 filter）， 將目前缺少的集合部份用新的 query 下去取然後合併至目前的（如果是拓展） -- 題外話，要提昇 DB 效能就又是另一回事了， 抓 memcache 出來用，或針對 key data 做衍生的新 table， 甚至用打基礎的方式做每日的 data parsing 拆解出 search 用的資料等等… 小弟能想到的幾個作法大概也就是這樣了吧 XDD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.228.229