經(jīng)常見到有在循環(huán)里面寫sql語句，這樣有什么問題嗎？一般來說如果幾十次操作，頁面就會等很久才響應(yīng)。如果幾十萬次操作數(shù)據(jù)庫，那么時間必然是不可接收的，我也不知道需要多久才能執(zhí)行完成。
其實如果學習過算法分析，假設(shè)操作的數(shù)據(jù)量是n，那么算法復雜度就是n，即線性復雜度。
如何優(yōu)化
一般來說合并sql，查詢的時候使用緩存。插入的時候大批量提交，如果數(shù)據(jù)足夠大就需要分批提交。
引入的問題
明顯循環(huán)的書寫更加簡單，更加的直接。經(jīng)常寫if判斷，好不容易寫一個循環(huán)還是很爽的。引入緩存，引入批量提交，代碼量會增加好幾倍。難以調(diào)試，更容易引入bug，下次閱讀的時候相對來說難以了解代碼原本的意思。
如果批量數(shù)據(jù)提交，包含錯誤處理，去重之類的，就需要一些更好的策略進行處理。
從直覺來說，復雜的代碼運行的也不會快。所以這些代碼應(yīng)該交給框架，或者至少腦子清醒的時候去寫。
可選的方案
可以考慮優(yōu)化表設(shè)計，簡化業(yè)務(wù)，去掉沒有必要的復雜操作。其他的策略包含定時處理存入臨時表，引入緩存等等。方法千千萬，總有適合你的。還有知道數(shù)據(jù)庫總不是萬能的，使用消息隊列，很多消息隊列性能優(yōu)秀，而基于發(fā)布訂閱模式的代碼，清晰且容易擴展。
當你遇到類似棘手的問題，你有什么好的解決辦法，可以告訴我嗎？
當我在說循環(huán)里面調(diào)用sql時，我在說什么
大多數(shù)時候，關(guān)心循環(huán)sql，是因為太慢了，到了性能調(diào)優(yōu)的時候了。業(yè)務(wù)量不大的操作，快速開發(fā)時，這樣寫是完全沒有問題的。因為關(guān)心這些東西的人畢竟是少數(shù)，而且影響并不大。
我想說的是，寫程序必須有一定的意識，理解代碼運行的值，也理解背后的代價。明白io操作巨慢無比，比內(nèi)存之類的慢了太多太多。循環(huán)里面請求http，循環(huán)里面讀文件也會很慢很慢。
即使是單純的數(shù)組循環(huán)有時候也很慢，而hash就很快。算法很重要，我認為更重要的是人，是的人的分析。
