本篇內(nèi)容介紹了“怎么理解Oracle等待事件的分類、發(fā)現(xiàn)及優(yōu)化”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)公司專注于企業(yè)營銷型網(wǎng)站建設、網(wǎng)站重做改版、潤州網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、成都h5網(wǎng)站建設、商城建設、集團公司官網(wǎng)建設、外貿(mào)營銷網(wǎng)站建設、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為潤州等各大城市提供網(wǎng)站開發(fā)制作服務。

一、等待事件由來

大家可能有些奇怪，為什么說等待事件，先談到了指標體系。其實，正是因為指標體系的發(fā)展，才導致等待事件的引入?？偨Y(jié)一下，Oracle的指標體系，大致經(jīng)歷了下面三個階段：

• 以命中率為主要參考指標

以各種命中率為主要的優(yōu)化入口依據(jù)，常見的有”library cache hit radio“等。但這種方式弊端很大，一個命中率為99%的系統(tǒng)，不一定就比95%的系統(tǒng)優(yōu)化的更好。在老的Oracle版本中，往往采用這種方式，如8i、9i等。

• 以等待事件為主要參考指標

以各種等待事件為優(yōu)化入口依據(jù)，常見的有"db file sequential read"等?？梢暂^直觀的了解，在一段時間內(nèi)，數(shù)據(jù)庫主要經(jīng)歷了那些等待。這些"瓶頸"，往往就是我們優(yōu)化的著手點。在10g、11g版本中，廣泛使用。

• 以時間模型為主要參考指標

以各種資源整體消耗為優(yōu)化入口依據(jù)?？梢詮恼w角度了解數(shù)據(jù)庫在一段時間內(nèi)的消耗情況。較等待事件的方式，更有概括性。常見的如"DB Time"。Oracle在不斷加強這個方面的工作。

從上面三個階段可見，等待事件的引入，正是為了解決以命中率為指標的諸多弊端。與后面的時間模型相比，等待事件以更加直觀、細粒度的方式觀察Oracle的行為，往往作為優(yōu)化的重要入口。而時間模型，更側(cè)重于整體、系統(tǒng)性的了解數(shù)據(jù)庫運行狀態(tài)。兩者的側(cè)重點不同。

二、等待事件分類

讓我們首先從等待事件的分類入手，認識等待事件。從大的分類上來看，等待事件可分為空閑的、非空閑的兩大部分。在非空閑的等待事件，又可進一步劃分細的類別。

可以通過下面的方法，觀察系統(tǒng)包含的等待事件數(shù)量及大致分類（以下語句在11g環(huán)境運行）。

其中WAIT_CLASS為“Idle”的等待事件就是空閑的，其他的都是非空閑的等待事件。

1. 區(qū)分 — 空閑與非空閑等待事件

空閑等待事件，是指Oracle正等待某種工作，比如用sqlplus登錄之后，但沒有進一步發(fā)出任何命令，此時該session就處于SQL*Net message from/to client等待事件狀態(tài)，等待用戶發(fā)出命令，任何的在診斷和優(yōu)化數(shù)據(jù)庫的時候，一般不用過多注意這部分事件。

非空閑等待事件，專門針對Oracle的活動，指數(shù)據(jù)庫任務或應用運行過程中發(fā)生的等待，這些等待事件是調(diào)整數(shù)據(jù)庫的時候應該關(guān)注與研究的。

2. 等待事件分類說明

• 管理類-Administrative

此類等待事件是由于DBA的管理命令引起的，這些命令要求用戶處于等待狀態(tài)（比如，重建索引） 。

• 應用程序類-Application

此類等待事件是由于用戶應用程序的代碼引起的（比如，鎖等待） 。

• 群集類-Cluster

此類等待事件和真正應用群集RAC的資源有關(guān)（比如，gc cr block busy等待事件） 。

• 提交確認類-Commit

此類等待事件只包含一種等待事件——在執(zhí)行了一個commit命令后，等待一個重做日志寫確認（也就是log file sync） 。

• 并發(fā)類-Concurrency

此類等待事件是由內(nèi)部數(shù)據(jù)庫資源引起的（比如閂鎖） 。

• 配置類-Configuration

此類等待事件是由數(shù)據(jù)庫或?qū)嵗牟划斉渲迷斐傻模ū热?，重做日志文件尺寸太小，共享池的大小等?。

• 空閑類-Idle

此類等待事件意味著會話不活躍，等待工作（比如，sql * net messages from client） 。

• 網(wǎng)絡類-Network

和網(wǎng)絡環(huán)境相關(guān)的一些等待事件（比如sql* net more data to dblink） 。

• 其它類-Other

此類等待事件通常比較少見（比如wait for EMON to spawn） 。

• 調(diào)度類-Scheduler

此類等待事件和資源管理相關(guān)（比如resmgr: become active'） 。

• 系統(tǒng)I/O類-System I/O

此類等待事件通過是由后臺進程的I/O操作引起的（比如DBWR等待-db file paralle write） 。

• 用戶I/O類-User I/O

此類等待事件通常是由用戶I/O操作引起的（比如db file sequential read） 。

三、理解等待事件

每一個等待事件，都表明數(shù)據(jù)庫的一種活動狀態(tài)。從上面的查詢可見，系統(tǒng)內(nèi)置了很多等待事件，可以通過數(shù)據(jù)字典V$EVENT_NAME去了解每個等待事件。下面通過一個最為常見的等待事件進行說明。

這個等待事件“db file sequential read”,直譯過來為“數(shù)據(jù)文件順序讀取”，是屬于“User I/O”類的等待事件。它通常是與單個數(shù)據(jù)塊相關(guān)的讀取操作，大多數(shù)情況下讀取一個索引塊或者通過索引讀取一個數(shù)據(jù)塊，會記錄這個等待。該事件說明在單個數(shù)據(jù)塊上大量等待，該值過高通常是由于表間連接順序很糟糕，或者使用了非選擇性索引。通過將這種等待與statspack報表中已知其它問題聯(lián)系起來（如效率不高的sql），通過檢查確保索引掃描是必須的，并確保多表連接的連接順序來調(diào)整，DBCACHESIZE可以決定該事件出現(xiàn)的頻率。

該等待事件包含了三個參數(shù)，分別為：

• file#: 代表oracle要讀取的文件的絕對文件號

• block#: 從這個文件中開始讀取的起始數(shù)據(jù)塊塊號

• blocks: 讀取的block數(shù)量。通常是1，表示單個block讀取。

通過上面這些參數(shù)，關(guān)聯(lián)數(shù)據(jù)字典可以確定發(fā)生等待事件的對象（即找到了熱點對象）。然后針對不同的情況，有針對性的進行解決。

對等待事件的了解越多，可更加深入理解數(shù)據(jù)庫運行機制，進而提高整體優(yōu)化能力。后面，我會介紹一下常見的等待事件。

四、觀察等待事件

系統(tǒng)內(nèi)置了一些視圖，通過這些視圖可以了解整體（系統(tǒng)級）、局部（會話級）的等待事件發(fā)生情況及各類別事件的分類統(tǒng)計。下面針對一些主要的視圖，說明一下。

1、v$event_name

系統(tǒng)支持的等待事件，可以查看等待事件所屬類別、參數(shù)的含義等信息。

2、v$system_wait_class

displays the instance-wide time totals for each registered wait class.

等待事件類別的統(tǒng)計信息（系統(tǒng)級）。通過這一視圖，可從全局角度了解系統(tǒng)那類操作等待較多。

3、v$system_event

等待事件的統(tǒng)計信息（系統(tǒng)級）。展開來說，是提供了自實例啟動后各個等待事件的概括。常用于獲取系統(tǒng)等待信息的歷史影象。而通過兩個snapshot獲取等待項增量，則可以確定這段時間內(nèi)系統(tǒng)的等待項。

主要的字段包括：

• TOTAL_WAITS

自數(shù)據(jù)庫啟動到現(xiàn)在，此等待事件總等待次數(shù)。

• TIME_WAITED

此等待事件的總等待時間（單位：百分之一秒）。這個數(shù)據(jù)表示從數(shù)據(jù)庫啟動以來這個等待事件在所有會話（包括已經(jīng)結(jié)束和正保持連接狀態(tài)的會話）總的等待事件之和。

• AVERAGE_WAIT 

此等待事件的平均等待用時（單位：百分之一秒）。

time_waited/total_waits

• TOTAL_TIMEOUTS

此等待事件總等待超時次數(shù)。

SQL – 按等待時長查看頂級事件

4、v$session_event

和v$system_event相類似，記錄的是會話在其生命周期中各個等待事件的累計值。跟前者相比，增加了session_id信息。這些信息也會被同時累積到v$system_event中。需要注意的是，當一個會話重新建立時，統(tǒng)計信息將被設置為0。

5、v$session_wait、v$session

活動會話正在等待的資源或事件信息。在10g將這個視圖和v$session視圖進行了合并。這是一個尋找性能瓶頸的關(guān)鍵視圖。它提供了任何情況下session在數(shù)據(jù)庫中當前正在等待什么。當系統(tǒng)存在性能問題時，本視圖可以做為一個起點指明探尋問題的方向。

需要注意的是，當?shù)却辉俅嬖跁r，會話先前出現(xiàn)的那些等待的歷史也將消失，從而使得事后診斷非常困難。V$SESSION_EVENT提供了累積的但不是非常詳細的數(shù)據(jù)?？梢酝ㄟ^歷史視圖v$session_wait_history獲得歷史信息。

主要的字段包括：

• EVENT

會話當前等待的事件，或者最后一次等待事件。

• WAIT_TIME

會話等待事件的時間（單位：百分之一秒）。

值>0: 最后一次等待時間(單位:10ms)，當前未在等待狀態(tài)。

值=0: session正在等待當前的事件。

值=-1: 最后一次等待時間小于1個統(tǒng)計單位，當前未在等待狀態(tài)。

值=-2: 時間統(tǒng)計狀態(tài)未置為可用，當前未在等待狀態(tài)。

• STATE

等待狀態(tài)(提供對wait_time和second_in_wait字段的解釋)

1) waiting：

SESSION正等待這個事件。

2) waited unknown time：

由于設置了timed_statistics值為false，導致不能得到時間信息。表示發(fā)生了等待，但時間很短。

3）wait short time：

表示發(fā)生了等待，但由于時間非常短不超過一個時間單位，所以沒有記錄。

4）waited knnow time:

如果session等待然后得到了所需資源，那么將從waiting進入本狀態(tài)。

• WAIT_TIME/SECOND_IN_WAIT

Wait_time和Second_in_wait字段值與state相關(guān)。

1）state=waiting

wait_time無用，second_in_wait值是實際的等待時間(單位:秒)。

2）state=wait unknow time

wait_time和second_in_wait都無用。

3）state=wait short time

wait_time和second_in_wait都無用。

4）state=waiting known time

wait_time值就是實際等待時間(單位:秒)，second_in_wait值無用。

6、v$sessionwaithistory

記錄會話最近n次等待事件，即v$session_wait的歷史記錄。默認是記錄10次，可進行修改。

7、v$event_histogram

這個視圖記錄了等待事件的柱狀圖分布，從而可以對一個等待事件具體分布有進一步了解。在v$session_event或v$system_event視圖記錄的是累積信息以及關(guān)于等待的平均值，無法得知個別等待消耗的時間。

下面將會話等待事件與各視圖之間的關(guān)系，總結(jié)整理如下：

• 一個會話一次只發(fā)生一個等待事件。如果看到了其他的等待事件，那僅僅表示在下一個時間片上發(fā)生了等待。在某個時刻只存在一個等待。

• v$session_wait中的wait_time和second_in_wait字段以秒為單位，而v$session_event中的time_waited和average_wait字段是以百分之一秒為單位。

• v$session_wait的等待事件結(jié)束后，v$session_event的統(tǒng)計信息將會發(fā)生改變。

• v$session_wait的統(tǒng)計信息意義不大，因為信息是實時變化的。

• 當v$session_wait里面的等待事件結(jié)束時，v$session_wait中的seconds_in_wait字段值被復制到v$session_event中time_waited字段，而v$session_event視圖的average_time字段同時也被修改。

五、常見等待事件

Oracle的等待事件非常多，不同的版本也有些差異。下面對一些常見的等待事件進行說明。希望對大家的日常工作能帶來幫助。

1、buffer busy waits

發(fā)生原因：

當一個會話將數(shù)據(jù)塊從磁盤讀到內(nèi)存中時，它需要到內(nèi)存中找到空閑的內(nèi)存空間來存放這些數(shù)據(jù)塊，當內(nèi)存中沒有空閑的空間時，就會產(chǎn)生這個等待。除此之外，還有一種情況就是會話在做一致性讀時，需要構(gòu)造數(shù)據(jù)塊在某個時刻的前映像。此時需要申請內(nèi)存塊來存放這些新構(gòu)造的數(shù)據(jù)塊，如果內(nèi)存中無法找到這樣的內(nèi)存塊，也會發(fā)生這個等待事件。

參數(shù)含義：

• File#

等待訪問數(shù)據(jù)塊所在的文件id號

• Blocks

等待訪問的數(shù)據(jù)塊號

• Id

10g之前，這個值表示等待事件原因；10g之后則表示等待事件的類別。

優(yōu)化方向：根據(jù)產(chǎn)生此等待事件的類別不同，優(yōu)化方向也不太一樣。

• 數(shù)據(jù)塊

一般優(yōu)化方向是優(yōu)化SQL，減少邏輯讀、物理讀；或者是減少單塊的存儲數(shù)據(jù)規(guī)模。

• 數(shù)據(jù)段頭

一般優(yōu)化方向是增加FREELISTS和FREELIST GROUPS。確保FCTFREE和PCTUSED之間的間隙不是太小，從而可以最小化FREELIST的塊循環(huán)。

• 撤銷塊

一般優(yōu)化方向為應用程序，錯峰使用數(shù)據(jù)對象。

• 撤銷段頭

如果是數(shù)據(jù)庫系統(tǒng)管理UNDO段，一般不需要干預。如果是自行管理的，可以減少每個回滾段的事務個數(shù)。

2、buffer latch

發(fā)生原因：

內(nèi)存中數(shù)據(jù)塊的存放位置是記錄在一個Hash列表當中的。當一個會話需要訪問某個數(shù)據(jù)塊時，它首先要搜索這個Hash列表，從列表中獲得數(shù)據(jù)塊的地址，然后通過這個地址去訪問需要的數(shù)據(jù)塊，這個列表oracle會使用一個latch來保護它的完整性。當一個會話需要訪問這個列表時，需要獲取一個latch，只有這樣，才能保證這個列表在這個會話的瀏覽當中不會發(fā)生改變。如果列表過長，導致會話搜索這個列表花費的時間太長，使其他的會話處于等待狀態(tài)。同樣的數(shù)據(jù)塊被頻繁訪問，就是我們通常說的熱塊問題。

參數(shù)含義：

• latch addr

會話申請的latch在SGA中的虛擬地址。

• chain#

buffer chains hash列表中的索引值。當這個參數(shù)的值等于0xffffff時，說明當前的會話正在等待一個LRU latch。

優(yōu)化方向：

可以考慮的優(yōu)化方向有使用多個buffer pool的方式來創(chuàng)建更多的buffer chains或者使用參數(shù)db_block_lru_latches來增加latch的數(shù)量，以便于更多的會話可以獲得latch，這兩種方法可以同時使用。

3、db file sequential read

發(fā)生原因：

通常是與單個數(shù)據(jù)塊相關(guān)的讀取操作，大多數(shù)情況下讀取一個索引塊或者通過索引讀取一個數(shù)據(jù)塊，會記錄這個等待?？赡茱@示表的連接順序不佳，或者不加選擇地進行索引。對于大量事務處理、調(diào)整良好的系統(tǒng)，這一數(shù)值大多是很正常的，但在某些情況下，它可能暗示著系統(tǒng)中存在問題。應當將這一等待統(tǒng)計量與性能報告中的已知問題（如效率較低的SQL）聯(lián)系起來。檢查索引掃描，以保證每個掃描都是必要的，并檢查多表連接的連接順序。

DB_CACHE_SIZE 也是這些等待出現(xiàn)頻率的決定因素。有問題的散列區(qū)域(Hash-area)連接應當出現(xiàn)在PGA 內(nèi)存中，但它們也會消耗大量內(nèi)存，從而在順序讀取時導致大量等待。它們也可能以直接路徑讀/寫等待的形式出現(xiàn)。

參數(shù)含義：

• file#

代表oracle要讀取的文件的絕對文件號

• block#

從這個文件中開始讀取的起始數(shù)據(jù)塊塊號

• blocks

讀取的block數(shù)量。通常是1，表示單個block讀取。

優(yōu)化方向：

這個等待事件，不一定代表一定有問題。如果能確定是有問題，可以按照下面優(yōu)化思路。

• 修改應用，避免出現(xiàn)大量IO的sql，或者減少其頻率。

• 增加data buffer，提高命中率。

• 采用更好的磁盤子系統(tǒng)，減少單個IO的響應時間，防止物理瓶頸的出現(xiàn)。

4、db file scattered read

發(fā)生原因：

這是一個用戶操作引起的等待事件，當用戶發(fā)出每次I/O需要讀取多個數(shù)據(jù)塊這樣的SQL操作時，會產(chǎn)生這個等待事件，最常見的兩種情況全表掃描和索引快速掃描。這個名稱中的scattered（發(fā)散）可能會導致很多人認為它是以scattered的方式來讀取數(shù)據(jù)塊的，其實恰恰相反，當發(fā)生這種等待事件時，SQL的操作都是順序地讀取數(shù)據(jù)塊的，比如FTS或IFFS方式。其實這里scattered指的是讀取的數(shù)據(jù)塊在內(nèi)存中的存放方式。它們被讀取到內(nèi)存中后，是以分散的方式存放在內(nèi)存中，而不是連續(xù)的。

參數(shù)含義：

• file#

代表oracle要讀取的文件的絕對文件號。

• block#

從這個文件中開始讀取的起始數(shù)據(jù)塊塊號。

• blocks

讀取的block數(shù)量。

優(yōu)化方向：

這種情況通常顯示與全表掃描相關(guān)的等待。當全表掃描被限制在內(nèi)存時，它們很少會進入連續(xù)的緩沖區(qū)內(nèi)，而是分散于整個緩沖存儲器中。如果這個數(shù)目很大，就表明該表找不到索引，或者只能找到有限的索引。盡管在特定條件下執(zhí)行全表掃描可能比索引掃描更有效，但如果出現(xiàn)這種等待時，最好檢查一下這些全表掃描是否必要。

5、direct path read

發(fā)生原因：

這個等待事件發(fā)生在會話將數(shù)據(jù)塊直接讀取到PGA當中而不是SGA中的情況，這些被讀取的數(shù)據(jù)通常是這個會話私有的數(shù)據(jù)，所以不需要放到SGA作為共享數(shù)據(jù)，因為這樣做沒有意義。這些數(shù)據(jù)通常是來自于臨時段上的數(shù)據(jù)，比如一個會話中SQL的排序數(shù)據(jù)，并行執(zhí)行過程中間產(chǎn)生的數(shù)據(jù)，以及Hash join、Merge join產(chǎn)生的排序數(shù)據(jù)，因為這些數(shù)據(jù)只對當前會話的SQL操作有意義，所以不需要放到SGA當中。當發(fā)生direct path read等待事件時，意味著磁盤上有大量的臨時數(shù)據(jù)產(chǎn)生，比如排序、并行執(zhí)行等操作，或者意味著PGA中空閑空間不足。

在11g中，全表掃描可能使用direct path read方式，繞過buffer cache，這樣的全表掃描就是物理讀了。在10g中，都是通過gc buffer來讀的，所以不存在direct path read的問題。

參數(shù)含義：

• file#

文件號

• first block#

讀取的起始塊號

• block count

以first block為起點，連續(xù)讀取的物理塊數(shù)

優(yōu)化方向：

有了這個等待事件，需要區(qū)分幾種情況。一個方向是增大排序區(qū)等手段，一個方向是減少讀取IO量或判斷是否通過緩沖區(qū)讀的方式更加高效。

6、direct path write

發(fā)生原因：

發(fā)生在oracle直接從PGA寫數(shù)據(jù)到數(shù)據(jù)文件或臨時文件，這個操作可以繞過SGA。在磁盤排序中最為常見。對于這種情況應該找到操作最為頻繁的數(shù)據(jù)文件(如果是排序，很有可能是臨時文件)，分散負載。

參數(shù)含義：

• file#

文件號

• first block#

讀取的起始塊號

• block count

以first block為起點，連續(xù)寫入的物理塊數(shù)

優(yōu)化方向：減少IO寫入規(guī)模。

7、library cache lock

發(fā)生原因：

這個等待事件發(fā)生在不同用戶在共享池中由于并發(fā)操作同一個數(shù)據(jù)庫對象導致的資源爭用的時候。比如當一個用戶正在對一個表做DDL操作時，其他的用戶如果要訪問這張表，就會發(fā)生library cache lock等待事件，它要一直等到DDL操作完畢后，才能繼續(xù)操作。

參數(shù)含義：

• Handle address

被加載的對象的地址。

• Lock address

鎖的地址。

• Mode

被加載對象的數(shù)據(jù)片段。

• Namespace

被加載對象在v$db_object_cache視圖中的namespace的名稱。

優(yōu)化方向：優(yōu)化方向是查看鎖定對象，減少爭用。

8、library cache pin

發(fā)生原因：

這個等待事件和library cache lock一樣是發(fā)生在共享池中并發(fā)操作引起的等待事件。通常來講，如果oracle要對一些pl/sql或視圖這樣的對象做重新編譯，需要將這些對象pin到共享池中。如果此時這個對象被其他的對象持有，就會產(chǎn)生一個library cache pin的等待。

參數(shù)含義：

• Handle address

被加載的對象的地址。

• Lock address

鎖的地址。

• Mode

被加載對象的數(shù)據(jù)片段。

• Namespace

被加載對象在v$db_object_cache視圖中的namespace的名稱。

優(yōu)化方向：優(yōu)化方向是查看鎖定對象，減少爭用。

9、log file sync

發(fā)生原因：

這是一個用戶會話行為導致的等待事件。當一個會話發(fā)出一個commit命令時，LGWR進程會將這個事務產(chǎn)生的redo log從log buffer里寫到磁盤上，以保證用戶提交的信息被安全地記錄到數(shù)據(jù)庫中。會話發(fā)出commit指令后，需要等待LGWR將這個事務產(chǎn)生的redo成功寫入到磁盤之后，才可以繼續(xù)進行后續(xù)的操作，這個等待事件就叫做log file sync。當系統(tǒng)中出現(xiàn)大量的log file sync等待事件時，應該檢查數(shù)據(jù)庫中是否有用戶在做頻繁的提交操作。這種等待事件通常發(fā)生在OLTP系統(tǒng)上。OLTP系統(tǒng)中存在很多小的事務，如果這些事務頻繁被提交，可能引起大量log file sync的等待事件。

優(yōu)化方向：

• 提高LGWR性能，盡量使用快速磁盤

• 使用批量提交

• 適當使用nologging/unrecoverable等選項

10、SQL*Net message from client

發(fā)生原因：

表明前臺服務器進程等待客戶進行響應。這個等待事件是由于等待用戶進程的響應所引起的，它并不表明數(shù)據(jù)庫就存在什么不正常。如果網(wǎng)絡出現(xiàn)故障時，這種等待時間就會經(jīng)常發(fā)生。

11、SQL*Net message to client

發(fā)生原因：

這個等待事件發(fā)生在服務器端向客戶端發(fā)送消息的時候。當服務器端向客戶端發(fā)送消息產(chǎn)生等待時，可能的原因是用戶端太繁忙，無法及時接收服務器端送來的消息，也可能是網(wǎng)絡問題導致消息無法從服務器端發(fā)送給客戶端。

“怎么理解Oracle等待事件的分類、發(fā)現(xiàn)及優(yōu)化”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

當前標題：怎么理解Oracle等待事件的分類、發(fā)現(xiàn)及優(yōu)化-創(chuàng)新互聯(lián)
當前URL：http://jinyejixie.com/article6/cccpig.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設、企業(yè)建站、小程序開發(fā)、微信小程序、外貿(mào)建站、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)