在這個信息化的時代，網(wǎng)絡(luò)已經(jīng)成為我們生活中不可或缺的一部分。無論是工作還是娛樂，網(wǎng)絡(luò)的穩(wěn)定性都顯得尤為重要。然而，有時候我們會遭遇一種讓人感到無奈的情況——網(wǎng)絡(luò)代理IP服務(wù)器連接失敗。就像一只飛不起來的鳥，心里明明渴望自由，卻被現(xiàn)實的桎梏所限制。這種失落感，想必每個網(wǎng)民都曾體驗過。

什么是網(wǎng)絡(luò)代理IP？

在深入探討連接失敗的原因之前，我們先來了解一下什么是網(wǎng)絡(luò)代理IP。簡單來說，網(wǎng)絡(luò)代理IP是一種中介服務(wù)，它允許用戶通過代理服務(wù)器訪問互聯(lián)網(wǎng)。就好比在一個繁忙的市場中，代理服務(wù)器就像是一個經(jīng)驗豐富的導購員，幫助你找到想要的商品，避開那些擁擠的人群。

使用代理IP的好處多多，比如可以隱藏真實IP地址、訪問被屏蔽的網(wǎng)站，甚至提高上網(wǎng)速度。可當這個“導購員”突然失聯(lián)，連接失敗時，我們就會感到無比的困惑和無助。

連接失敗的常見原因

網(wǎng)絡(luò)代理IP服務(wù)器連接失敗的原因多種多樣，可能是服務(wù)器本身的問題，也可能是我們使用的設(shè)備或網(wǎng)絡(luò)設(shè)置的問題。以下是一些常見的原因：

如何解決連接失敗的問題

面對網(wǎng)絡(luò)代理IP服務(wù)器連接失敗的問題，我們不能像無頭蒼蠅一樣四處亂撞，而是要采取一些有效的措施來解決。以下是一些建議：

預防連接失敗的小技巧

預防勝于治療，想要避免網(wǎng)絡(luò)代理IP服務(wù)器連接失敗的情況，平時的一些小技巧也是必不可少的：

結(jié)語

網(wǎng)絡(luò)代理IP服務(wù)器連接失敗的情況，就像是生活中的小插曲，雖然讓人感到煩惱，但只要我們認真對待，積極尋找解決方案，最終總能找到出路。記住，網(wǎng)絡(luò)世界雖復雜，但只要我們保持耐心和細心，便能夠在這片虛擬的海洋中暢游無阻。

希望每位讀者在遇到網(wǎng)絡(luò)代理IP服務(wù)器連接失敗時，能夠從這篇文章中找到一些啟示，輕松應對，繼續(xù)享受網(wǎng)絡(luò)帶來的便利與樂趣！

案例詳解 DB2 執(zhí)行計劃的各個要點（附：DB2 實用技巧）

對于DB2數(shù)據(jù)庫，很多人并不能理解執(zhí)行計劃所表達的含義，在此推薦一篇社區(qū)專家的文章，通過實際案例詳細探討DB2數(shù)據(jù)庫中執(zhí)行計劃的各個要點。文后附上IBM技術(shù)團隊出品的DB2 實用技巧8招，相信對大家會很有幫助。

《DB2 執(zhí)行計劃淺析》 作者：洪燁，專注于并擅長數(shù)據(jù)庫領(lǐng)域。主要負責哈爾濱銀行的服務(wù)器、存儲、數(shù)據(jù)庫的管理與維護工作。

個人主頁：

在數(shù)據(jù)庫調(diào)優(yōu)過程中，SQL語句往往是導致性能問題的主要原因，而執(zhí)行計劃則是解釋SQL語句執(zhí)行過程的語言，只有充分讀懂執(zhí)行計劃才能在數(shù)據(jù)庫性能優(yōu)化中做到游刃有余。

常見的關(guān)系型數(shù)據(jù)庫中，雖然執(zhí)行計劃的表示方法各自不同，但執(zhí)行原理卻大同小異。在我看來，SQL語句的執(zhí)行過程中總共包含兩個關(guān)鍵環(huán)節(jié)：

只要掌握這兩個關(guān)鍵環(huán)節(jié)，我們就可以迅速識別SQL語句在當前數(shù)據(jù)庫中的執(zhí)行邏輯，發(fā)現(xiàn)執(zhí)行計劃中存在的問題及隱患。由于不同數(shù)據(jù)庫之間對于執(zhí)行計劃的表示方法各不相同。對于DB2數(shù)據(jù)庫，很多人并不能理解執(zhí)行計劃所表達的含義，接下來我們就通過實際案例詳細探討DB2數(shù)據(jù)庫中執(zhí)行計劃的各個要點。

讀取數(shù)據(jù)的方式

談到讀取數(shù)據(jù)就離不開數(shù)據(jù)庫中的物理對象：表及索引。因此談到數(shù)據(jù)讀取的方式，只需理解表掃描及索引掃描，就能基本把握數(shù)據(jù)的來源。

全表掃描

在DB2 LUW中可以通過四種方式獲取語句的執(zhí)行計劃（工具），雖然工具不同，但展示的內(nèi)容基本相似，最大的區(qū)別就是詳細程度。詳細程度由大到小排序分別是：。為了方便展示，我們在這里只討論通過所展示的執(zhí)行計劃信息。首先我們來看一個抓取的完整的執(zhí)行計劃。

展示的信息總共分為三部分，分別是當前SQL 語句，執(zhí)行計劃詳細信息及執(zhí)行計劃圖示（需添加-g參數(shù)才能展示），第一部分是當前采集執(zhí)行計劃的語句（見圖1-1）：

這部分內(nèi)容基本一目了然，需要注意的就是里面:HV … :HI… 的信息是DB2將參數(shù)改寫的信息（基本可以忽略）。

接下來我們來看最關(guān)鍵的部分，執(zhí)行計劃的詳細信息（見圖1-2）：

這部分首先包括當前環(huán)境的字符集（），下面是根據(jù)統(tǒng)計信息評估出的成本及返回行數(shù)。在這個例子中執(zhí)行成本為124470，返回行數(shù)為1行。從第6行開始的位置內(nèi)容比較重要，我們采取逐行解釋：

第三部分為執(zhí)行計劃圖，我們可以通過執(zhí)行計劃圖快速直接地看出SQL語句的執(zhí)行過程，執(zhí)行計劃圖的閱讀順序是從下往上，從左往右，按照編號從大到小的順序進行閱讀。比如在這個例子中，首先看第三步，顯示對表進行表掃描操作（TBSCAN），然后對掃描的結(jié)果進行g(shù)roup by操作并將最終結(jié)果返回，這條SQL語句就執(zhí)行完畢了。

索引掃描

接下來來看個索引掃描的例子，為了快速理解這個執(zhí)行計劃，我們直接先看執(zhí)行計劃圖，可以看到這個SQL語句首先讀取索引，獲取RID后到表里獲取其他數(shù)據(jù)，進行g(shù)roup by后將結(jié)果返回。

其他部分和上一個例子差不多，就不一一詳細介紹了，主要看索引掃描的相關(guān)細節(jié)。從下面的信息可以看出用到的索引中包含4個字段，但這條SQL只用到了一個字段。其他三個字段都沒用使用。如果該表上有其他索引包含這條SQL所使用的更多的字段時，這個索引肯定不是最佳選擇。

數(shù)據(jù)讀取的方式還有更多的細節(jié)，這里暫時不一一討論了，但不論對數(shù)據(jù)采用何種方式讀取，最核心的內(nèi)容還是數(shù)據(jù)從哪里讀取，簡單來說就是有沒有更好的索引可以替代當前的掃描策略，所以，當我們對SQL語句進行優(yōu)化時，第一步就是需要考慮當前的讀取方式是否足夠有效。

表連接的方式

接下來我們來談表之間的連接，寫過SQL的童鞋都知道，寫SQL時Join方式可以有很多種情況：inner join,left join,right join,full join等，還包括一些子查詢，比如exist 或者In等方式。對于星型查詢，DB2 10以后還支持ZZJOIN。

Nest Loop(NLJOIN)

Nest Loop是最簡單的一種連接方式，數(shù)據(jù)庫會根據(jù)表中的記錄數(shù)選擇內(nèi)表及外表，在定義內(nèi)外表后，首先會對外表進行全表掃描，然后重復掃描內(nèi)表并與外表中的每一條記錄進行匹配，最終返回程序所需的結(jié)果集。

因此NLJOIN的總成本大約為外表掃描的成本+外表返回的行數(shù)×內(nèi)表掃描的成本。NLJOIN作為使用場景最多的連接方式，當外表匹配行數(shù)較少或內(nèi)外表行數(shù)差距較大時效率較高，但也正因為NLJOIN的運行方式，也經(jīng)常會發(fā)生性能隱患.

Merge Join(MSJOIN)

合并連接是為了解決Nest Loop中存在的一些問題所采用的一種連接方式，MSJOIN會將需要連接的兩張表進行排序，并將排序后的結(jié)果集按照交叉方式匹配，最終返回連接后的結(jié)果。

MSJOIN的總成本大約為單次外表掃描的成本＋單次內(nèi)表掃描的成本＋排序成本。MSJOIN常見的場景通常是SQL需要返回排序結(jié)果，亦或者主外表都比較大的情況，此外MSJOIN只能應用于SQL語句中包含唯一連接謂詞的情況，當主外表數(shù)量級都比較大，且連接謂詞上都存在索引時，MSJOIN的效率較高（避免了排序成本），通常MSJOIN比較穩(wěn)定，即使統(tǒng)計信息估算錯誤，也不會導致執(zhí)行效率出現(xiàn)較大的偏差。

Hash join(HSJOIN)

HSJOIN是一種比較高級的連接方式，進行連接前首先會將外表根據(jù)連接謂詞進行哈希產(chǎn)生哈希表，然后將哈希表與內(nèi)表進行連接并返回結(jié)果。與MSJOIN類似，HSJOIN也只對內(nèi)外表分別進行一次掃描，同時HSJOIN也支持多連接謂詞。在兩張大表通過多連接謂詞進行連接時效率很高。

HSJOIN的掃描成本約為內(nèi)表掃描成本＋外表掃描成本。但需要注意的是，生成的哈希表會存放在排序堆中，一旦排序堆內(nèi)存溢出，會額外產(chǎn)生大量的物理IO，這點需要特別注意。

半連接（semi-join）

半連接屬于一種比較奇怪的連接方式，在很多資料里并沒有將其劃分到連接方式中，因為有的時候，從執(zhí)行計劃中根本看不到連接操作符，比如下面這個SQL：

這是一個典型的子查詢，我們可以從SQL語句中猜出大概邏輯，首先會讀取子查詢中的表，然后根據(jù)返回的內(nèi)容與外部表進行匹配并返回結(jié)果。但從執(zhí)行計劃圖中并不能看到任何關(guān)于連接的信息。

執(zhí)行計劃圖中并沒有顯示任何join的信息，只是多個對象進行了fetch，但從文字描述中可以看到更詳細的內(nèi)容。

數(shù)據(jù)流1首先會對內(nèi)部表進行全表掃描（ANY／），讀取后的結(jié)果與外部表進行匹配，匹配到結(jié)果后不繼續(xù)掃描立刻返回結(jié)果（EXISTS ）。

多表間的連接順序選擇

不論在同一條SQL語句中包含了多少張表連接，在同一時刻只有兩張表進行連接，但多表間的連接順序也是決定性能的主要原因。數(shù)據(jù)庫對于表的順序的選擇，往往根據(jù)兩個表之間連接后得出的行數(shù)進行排序，如果統(tǒng)計信息與實際情況偏差較大，有可能會導致由于連接順序不當而導致的性能問題。

10

總結(jié)

通過對執(zhí)行計劃的解析，我們講解了SQL執(zhí)行過程中對于性能影響較大的各個要點，但如何在生產(chǎn)上保持SQL的高效穩(wěn)定，還需對執(zhí)行計劃進行更深入的理解。 再解答一些常見的疑問：

Q & A

Q1：在查詢時，有一個驅(qū)動表，通常是from后的第一個表，后面一堆左連接右連接，這個驅(qū)動表如何選擇？對性能有影響么？自己人為該順序不會影響執(zhí)行計劃？

A1：在數(shù)據(jù)庫中，會根據(jù)當前表的情況進行內(nèi)外表的選擇，SQL語句中的寫法只能從一定程度上決定連接次序，但不會做連接中內(nèi)外表的決策。

舉個例子， a,( b,c where b.id=c.id)where……，比如這個SQL，在寫法中指明了需要先將b c表連接，再與a表連接，但在連接時候的方式以及連接時候內(nèi)表外表的選擇，都由數(shù)據(jù)庫決定。

-----------

Q2：關(guān)于連接方式的選擇，是由連接的兩個表和連接的字段是否排序決定的？

A2：這個不絕對，但是會作為選擇的因素之一。

-----------

Q4：訪問某表的access plan改變了，統(tǒng)計信息沒變，是什么情況？這是優(yōu)化器自動調(diào)整了嗎？可是優(yōu)化器根據(jù)統(tǒng)計信息生成訪問計劃，按道理應該是不會變的啊？

A4：執(zhí)行計劃的選擇會根據(jù)數(shù)據(jù)庫參數(shù)，統(tǒng)計信息作為參考，但在編譯過程中數(shù)據(jù)庫還會收集一些物理信息。比如數(shù)據(jù)的物理分布可能會對掃描的方式產(chǎn)生影響。

-----------

Q5：這個物理信息是什么，是表空間信息嗎？

A5：表在物理中存放的情況。

-----------

Q6：有什么手段跟蹤一個SQL完整的執(zhí)行過程，包括你說的動態(tài)收集物理信息？

A6：可以抓trace或者stack。db2trc，和db2pd –stack。

-----------

Q7：老師，db2的優(yōu)化器是對越復雜的sql支持的越好嗎？有這個說法嗎？

A7：db2的優(yōu)化器對復雜SQL的支持在關(guān)系型數(shù)據(jù)庫里應該是最好的，但是對于聯(lián)機交易系統(tǒng)來講，我覺得SQL的穩(wěn)定性比較重要。但復雜SQL牽扯到的變化因素太多，任何一個表的統(tǒng)計信息改變都有可能導致SQL性能下降，所以在聯(lián)機交易系統(tǒng)不太推薦寫復雜SQL。

-----------

Q8：那我們寫sql時該怎么注意呢？NL join類似笛卡爾集，時間復雜度最高，其次是merge。我覺得從sql上避免不了，因為選擇了那個列，就基本確定了連接類型。

A8：在編寫SQL的時候很難決定用什么連接方式，但有些需要注意的地方，比如避免多張大表連接，這些在開發(fā)過程中還是可以辦到的。

-----------

Q9：hash連接，如果探測表很大，內(nèi)建表很小，hash的成本顯示很高，因為探測表做了表掃描，沒有用到索引，這種如何優(yōu)化，只能減少探測表的返回集嗎？

A9：可以在探測表上創(chuàng)建適當索引。

-----------

Q10：對表做完統(tǒng)計更新后需要做rbind嗎？

A10：這個需要取決于你的應用是靜態(tài)SQL還是動態(tài)SQL。靜態(tài)SQL的話執(zhí)行計劃在bind的時候保持在數(shù)據(jù)庫中，統(tǒng)計信息更新后建議rebind，但動態(tài)的就沒必要了。

-----------

Q11：通常謂詞出現(xiàn)在索引的第一個字段應該就是有效索引，可有時候這個索引存在，但是個復合索引，跑時卻建議在這個謂詞上創(chuàng)建新的單一的索引，為什么數(shù)據(jù)庫不用現(xiàn)有的復合？

A11：復合索引并不一定高效，這個需要根據(jù)數(shù)據(jù)分布來判斷，如果單一索引的非常好（也就是和表存放的順序匹配度非常高），這樣可以用到大量預取操作，性能會比同步讀好很多。

-----------

Q12：嵌入式C、C++、COBOL的包BND（包括靜態(tài)SQL），要綁， 用戶SP也建議綁定吧？

A12：UDI的成本其實很大程度上和表設(shè)計有關(guān)。比如在做DML語句的時候發(fā)生行溢出和頁重組，帶來的消耗遠大于插入索引。相關(guān)信息可以看db2pd -tcb或者 for table。

-----------

Q13：請問一下對于表壓縮有什么建議？比如要做大表的壓縮，有沒有一些量化指標供參考，因為有一些表開了壓縮批次插入較多記錄時候影延長了批次1/3的時間。

A13：對于壓縮，需要分析當前數(shù)據(jù)庫的瓶頸在哪。壓縮是以cpu為代價降低磁盤io，如果瓶頸在磁盤io上，肯定會有幫助，但如果瓶頸在cpu上只會雪上加霜。

-----------

Q14：調(diào)整呢？有沒有量化的一些指標？

A14：這個不是很好量化。對于磁盤io瓶頸，可以先從索引，語句甚至表設(shè)計入手。如果都已經(jīng)調(diào)整到很好了但還是存在iO瓶頸，同時CPU使用率又比較低（30-40以下）。可以考慮壓縮。

（本文由作者授權(quán)發(fā)布）

DB2 實用技巧八招