如何分析SQLServer中的deadlocktrace

首先我們來(lái)看一個(gè)簡(jiǎn)單的例子，大結(jié)構(gòu)非常簡(jiǎn)單：

創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括新疆網(wǎng)站建設(shè)、新疆網(wǎng)站制作、新疆網(wǎng)頁(yè)制作以及新疆網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，新疆網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到新疆省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

1，process-list顯示了兩個(gè)進(jìn)程之間發(fā)生了死鎖process60fb88和processd11902c8。

2，vistim-list顯示了process60fb88被選為了犧牲者。

2，后面的resource-list顯示了兩個(gè)進(jìn)程爭(zhēng)取并導(dǎo)致死鎖的資源。

[html] view plain copy

deadlock

victim-list

victimProcess id="process60fb88" /

/victim-list

process-list

process id="process60fb88" taskpriority="0" logused="0" waitresource="KEY: 9:72057597664231424 (7506ff9b7b0d)" waittime="4376" ownerId="2656658629" transactionname="SELECT" lasttranstarted="2014-04-09T23:01:35.743" XDES="0x80059940" lockMode="S" schedulerid="4" kpid="10640" status="suspended" spid="80" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2014-04-09T23:01:35.657" lastbatchcompleted="2014-04-09T23:01:35.657" clientapp=".Net SqlClient Data Provider" hostname="BODCPRODVSQL128" hostpid="10088" loginname="PROD\s-propdata" isolationlevel="read committed (2)" xactid="2656658629" currentdb="9" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"

executionStack

frame procname="" line="9" stmtstart="336" stmtend="874" sqlhandle="0x030009003d00da3fa6087c0182a200000100000000000000" /

frame procname="" line="20" stmtstart="1022" stmtend="1206" sqlhandle="0x03000900941f284ed5929e00aba200000100000000000000" /

frame procname="" line="9" stmtstart="464" stmtend="642" sqlhandle="0x03000a006502e0715df5af00aba200000100000000000000" /

frame procname="" line="4" stmtstart="224" stmtend="420" sqlhandle="0x01000a00b6fca934509742900b0000000000000000000000" /

/executionStack

inputbuf

DECLARE @logText NVARCHAR(MAX)

EXEC IntegratedService_ProcessLatestCommand @logText OUTPUT

SELECT @logText /inputbuf

/process

process id="processd11902c8" taskpriority="0" logused="232" waitresource="KEY: 9:72057596808265728 (ed2e944beff9)" waittime="4379" ownerId="2656658630" transactionname="UPDATE" lasttranstarted="2014-04-09T23:01:35.743" XDES="0x80048570" lockMode="X" schedulerid="8" kpid="6620" status="suspended" spid="53" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-04-09T23:01:34.650" lastbatchcompleted="2014-04-09T23:01:34.650" clientapp=".Net SqlClient Data Provider" hostname="BODCPRODVSQL128" hostpid="10088" loginname="PROD\s-propdata" isolationlevel="read committed (2)" xactid="2656658630" currentdb="9" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"

executionStack

frame procname="" line="22" stmtstart="1230" stmtend="1496" sqlhandle="0x030009003d00da3fa6087c0182a200000100000000000000" /

frame procname="" line="20" stmtstart="1022" stmtend="1206" sqlhandle="0x03000900941f284ed5929e00aba200000100000000000000" /

frame procname="" line="9" stmtstart="464" stmtend="642" sqlhandle="0x03000a006502e0715df5af00aba200000100000000000000" /

frame procname="" line="4" stmtstart="224" stmtend="420" sqlhandle="0x01000a00b6fca934509742900b0000000000000000000000" /

/executionStack

inputbuf

DECLARE @logText NVARCHAR(MAX)

EXEC IntegratedService_ProcessLatestCommand @logText OUTPUT

SELECT @logText /inputbuf

/process

/process-list

resource-list

keylock hobtid="72057597664231424" dbid="9" objectname="" indexname="" id="lockc99859500" mode="X" associatedObjectId="72057597664231424"

owner-list

owner id="processd11902c8" mode="X" /

/owner-list

waiter-list

waiter id="process60fb88" mode="S" requestType="wait" /

/waiter-list

/keylock

keylock hobtid="72057596808265728" dbid="9" objectname="" indexname="" id="lock2f4de2d00" mode="S" associatedObjectId="72057596808265728"

owner-list

owner id="process60fb88" mode="S" /

/owner-list

waiter-list

waiter id="processd11902c8" mode="X" requestType="wait" /

/waiter-list

/keylock

/resource-list

/deadlock

下面是詳細(xì)分析。

1，victim-list沒(méi)什么可分析的。

2，process-list中關(guān)于各個(gè)process的詳細(xì)信息很重要。

waitresource="KEY: 9:72057597664231424 (7506ff9b7b0d)"

當(dāng)前process正在等待的資源。通常我們?cè)趓esource-list中可以看到同樣的信息。使用下面的sql查詢等待的資源是什么：

下面使用的hobtid是heap or b-tree id的縮寫。詳細(xì)見(jiàn)sys.partotions的解釋。

[sql] view plain copy

SELECT o.name, i.name

FROM sys.partitions p

JOIN sys.objects o ON p.object_id = o.object_id

JOIN sys.indexes i ON p.object_id = i.object_id

AND p.index_id = i.index_id

WHERE p.hobt_id = 72057597664231

name name

--------------------------------------------------------------------

MatchService PK_Matcher_ID

從結(jié)果我們就可以知道，等待的資源是一個(gè)表MatchService的主鍵PK_Matcher_ID。考察另外一個(gè)process的waitresource我們可以得知等待的資源是同一個(gè)表的另外一個(gè)索引。至此我們找到了直接導(dǎo)致死鎖的資源是什么。

同時(shí)可以看到兩個(gè)process一個(gè)是x lock，一個(gè)是s lock。因此可以判定發(fā)生在該表上的一個(gè)修改語(yǔ)句和一個(gè)查詢語(yǔ)句之間發(fā)生了死鎖。

另外，上例中可以清晰的看到是keylock導(dǎo)致的死鎖，因此查詢partitions可以找到對(duì)應(yīng)的object (sys.partitions contains a row for each partition of all

the tables and most types of indexes in the database.)。但有時(shí)是其他類型的資源發(fā)生了死鎖，例如pagelock, waitresource="PAGE: 9:1:28440841" 。 9是dbid; 1是fileid; 28440841是pageid。對(duì)于這種情況，使用下面的語(yǔ)句查詢對(duì)應(yīng)的資源：

[sql] view plain copy

DBCC TRACEON(3604)

GO

DBCC PAGE (9, 1, 28440841)

GO

DBCC TRACEOFF(3604)

GO

從返回的Metadata: objectId找到對(duì)應(yīng)的objectid。

3，再看process中的inputbuf。這個(gè)tag表明了process正在運(yùn)行的語(yǔ)句，因此對(duì)于定位死鎖非常重要。但這里有一個(gè)問(wèn)題，比如

上例中，inputbuf是一個(gè)存儲(chǔ)過(guò)程，其中又嵌套了很多其他的存儲(chǔ)過(guò)程，但inputbuf是用戶直接發(fā)出的sql，而我們需要在其中找出直接導(dǎo)致死

鎖的語(yǔ)句并優(yōu)化，從而解決或減少死鎖。自此我們已經(jīng)有的信息是：導(dǎo)致死鎖的語(yǔ)句由inputbuf中的語(yǔ)句調(diào)用，同時(shí)導(dǎo)致死鎖的語(yǔ)句必定是對(duì)表

MatchService的修改語(yǔ)句。如果存儲(chǔ)過(guò)程很簡(jiǎn)單，到此DBA已經(jīng)能夠找到直接導(dǎo)致死鎖的sql了，分析過(guò)程到此結(jié)束。而如果存儲(chǔ)過(guò)程很復(fù)雜，則

需要進(jìn)一步分析。

4，現(xiàn)在再進(jìn)一步考察tag, executionStack。executionStack表明了死鎖發(fā)生時(shí)，由inputbuf調(diào)用的一系列

sql。上例中有4條sql。同時(shí)仔細(xì)觀察上例可以發(fā)生，兩個(gè)process的executionStack是完全相同的，因此考察一個(gè)就可以了。另外，

如果procname不為空則直接得到了sql，但上例中該tag為空。

自此我們希望把executionStack中的所有sql顯示出來(lái)。使用下面的sql找出sqlhandle對(duì)應(yīng)的在內(nèi)存中的sql。需要注意的

是，如果deadlock已經(jīng)過(guò)去了一段時(shí)間，sqlhandle可能已經(jīng)被從內(nèi)存中清除掉了，這時(shí)就不可查了。還有sqlhandle是

varbinaryd，所以查詢時(shí)不可加引號(hào)。

另外還有一個(gè)有趣的地方：和其他程序語(yǔ)言報(bào)錯(cuò)時(shí)一樣，stack最上的一條是最直接的錯(cuò)誤，后面的錯(cuò)誤都是該錯(cuò)誤的上一層錯(cuò)誤(這么解釋可能有點(diǎn)

亂，寫過(guò)代碼的同學(xué)能理解哈)。因此在上面說(shuō)的存儲(chǔ)過(guò)程調(diào)用存儲(chǔ)過(guò)程的情況中，executionStack中第一條是直接導(dǎo)致死鎖的sql，第二條是調(diào)

用該sql的sql，以此類推，最后一條理論上就是inputbuf中的sql。

[sql] view plain copy

SELECT sql_handle AS Handle,

SUBSTRING(st.text, (qs.statement_start_offset/2)+1,

((CASE qs.statement_end_offset

WHEN -1 THEN DATALENGTH(st.text)

ELSE qs.statement_end_offset

END - qs.statement_start_offset)/2) + 1) AS Text

FROM sys.dm_exec_query_stats AS qs

CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st

where sql_handle = 0x030009003d00da3fa6087c0182a200000100000000000000

order by sql_handle

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

0x030009003D00DA3FA6087C0182A200000100000000000000SELECT

TOP 1 @matcherQueueID = lhs.MatcherService_MatcherQueue_ID,

@rootOperationUID = Root_Operation_UID FROM

MatcherService_MatcherQueue lhs WHERE lhs.Processing_State

= 'MATCHING' OR lhs.Processing_State = 'MATCHED' ORDER BY

Last_Execution_Date ASC

0x030009003D00DA3FA6087C0182A200000100000000000000

SELECT Top 1 @ticketID = OperationLog_ID FROM GEDemo.dbo.OperationLog

WHERE @rootOperationUID = Root_Operation_UID AND Status = 0

ORDER BY OperationLog_ID ASC

0x030009003D00DA3FA6087C0182A200000100000000000000

UPDATE MatcherService_MatcherQueue SET Last_Execution_Date =

GETDATE() WHERE MatcherService_MatcherQueue_ID = @matcherQueueID

注意看起來(lái)一個(gè)sql_handle有三條語(yǔ)句，原因是這三條sql是屬于同一個(gè)存儲(chǔ)過(guò)程的。

如果一個(gè)sql_handle包含的語(yǔ)句很多，比如是一個(gè)很長(zhǎng)的存儲(chǔ)過(guò)程，那么我們還可以使用一個(gè)有力的信息：executionStack中的

line

tag.這條語(yǔ)句表明了到底是哪一個(gè)sql直接導(dǎo)致了死鎖。如果一條statement中又包含了很多表，那么還需要和死鎖的資源結(jié)合起來(lái)判斷是哪個(gè)表或

索引的數(shù)據(jù)發(fā)生了死鎖。

如何提取并分析sqlserver的日志中的modify日志

定期分析sqlserver日志是DBA很重要的任務(wù),那如何才能查看sqlserver日志呢?

在SQL Server 7.0和SQL Server2000中，可以用下面的命令查看：

DBCC log ( {dbid|dbname}, [, type={0|1|2|3|4}] )

參數(shù):

Dbid or dbname - 任一數(shù)據(jù)庫(kù)的ID或名字

type - 輸出結(jié)果的類型:

0 - 最少信息(operation, context, transaction id)

1 - 更多信息(plus flags, tags, row length)

2 - 非常詳細(xì)的信息(plus object name, index name,page id, slot id)

3 - 每種操作的全部信息

4 - 每種操作的全部信息加上該事務(wù)的16進(jìn)制信息

默認(rèn) type = 0

要查看MSATER數(shù)據(jù)庫(kù)的事務(wù)日志可以用以下命令：

DBCC log (master)

釋放日志空間

1.清空日志

DUMP TRANSACTION 庫(kù)名 WITH NO_LOG

2.截?cái)嗍聞?wù)日志：

BACKUP LOG 數(shù)據(jù)庫(kù)名 WITH NO_LOG

3.收縮數(shù)據(jù)庫(kù)文件(如果不壓縮,數(shù)據(jù)庫(kù)的文件不會(huì)減小

企業(yè)管理器--右鍵你要壓縮的數(shù)據(jù)庫(kù)--所有任務(wù)--收縮數(shù)據(jù)庫(kù)--收縮文件

--選擇日志文件--在收縮方式里選擇收縮至XXM,這里會(huì)給出一個(gè)允許收縮到的最小M數(shù),直接輸入這個(gè)數(shù),確定就可以了

--選擇數(shù)據(jù)文件--在收縮方式里選擇收縮至XXM,這里會(huì)給出一個(gè)允許收縮到的最小M數(shù),直接輸入這個(gè)數(shù),確定就可以了

也可以用SQL語(yǔ)句來(lái)完成

--收縮數(shù)據(jù)庫(kù)

DBCC SHRINKDATABASE(客戶資料)

--收縮指定數(shù)據(jù)文件,1是文件號(hào),可以通過(guò)這個(gè)語(yǔ)句查詢到:select * from sysfiles

DBCC SHRINKFILE(1)

4.為了最大化的縮小日志文件(如果是sql 7.0,這步只能在查詢分析器中進(jìn)行)

a.分離數(shù)據(jù)庫(kù):

企業(yè)管理器--服務(wù)器--數(shù)據(jù)庫(kù)--右鍵--分離數(shù)據(jù)庫(kù)

b.在我的電腦中刪除LOG文件

c.附加數(shù)據(jù)庫(kù):

企業(yè)管理器--服務(wù)器--數(shù)據(jù)庫(kù)--右鍵--附加數(shù)據(jù)庫(kù)

此法將生成新的LOG，大小只有500多K

或用代碼：

下面的示例分離 pubs，然后將 pubs 中的一個(gè)文件附加到當(dāng)前服務(wù)器。

a.分離

E X E C sp_detach_db @dbname = 'pubs'

b.刪除日志文件

c.再附加

E X E C sp_attach_single_file_db @dbname = 'pubs',

@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'

5.為了以后能自動(dòng)收縮,做如下設(shè)置:

企業(yè)管理器--服務(wù)器--右鍵數(shù)據(jù)庫(kù)--屬性--選項(xiàng)--選擇"自動(dòng)收縮"

--SQL語(yǔ)句設(shè)置方式:

E X E C sp_dboption '數(shù)據(jù)庫(kù)名', 'autoshrink', 'TRUE'

6.如果想以后不讓它日志增長(zhǎng)得太大

企業(yè)管理器--服務(wù)器--右鍵數(shù)據(jù)庫(kù)--屬性--事務(wù)日志

--將文件增長(zhǎng)限制為xM(x是你允許的最大數(shù)據(jù)文件大小)

--SQL語(yǔ)句的設(shè)置方式:

alter database 數(shù)據(jù)庫(kù)名 modify file(name=邏輯文件名,maxsize=20)

特別注意：

請(qǐng)按步驟進(jìn)行,未進(jìn)行前面的步驟,請(qǐng)不要做后面的步驟

否則可能損壞你的數(shù)據(jù)庫(kù).

一般不建議做第4,6兩步

第4步不安全,有可能損壞數(shù)據(jù)庫(kù)或丟失數(shù)據(jù)

第6步如果日志達(dá)到上限,則以后的數(shù)據(jù)庫(kù)處理會(huì)失敗,在清理日志后才能恢復(fù).

另外提供一種更簡(jiǎn)單的方法，建議大家使用。

更簡(jiǎn)單的方法：

1。右建數(shù)據(jù)庫(kù)屬性窗口--故障還原模型--設(shè)為簡(jiǎn)單

2。右建數(shù)據(jù)庫(kù)所有任務(wù)--收縮數(shù)據(jù)庫(kù)

簡(jiǎn)述SQL Server企業(yè)管理器和查詢分析器的作用

它是用來(lái)對(duì)本地或者遠(yuǎn)程服務(wù)器進(jìn)行管理操作的服務(wù)器應(yīng)用程序查詢分析器：sqlserver2000查詢分析器是一種圖形工具，它允許用戶輸入和執(zhí)行sql語(yǔ)句，并返回語(yǔ)句的執(zhí)行結(jié)果。

一、企業(yè)管理器是SQLServer2000中最重要的一個(gè)產(chǎn)品組件。用戶和系統(tǒng)管理員通過(guò)企業(yè)管理器不僅能夠配置系統(tǒng)環(huán)境和管理SQLServer，而且所有SQLServer對(duì)象的建立與管理都可以通過(guò)它來(lái)完成。企業(yè)管理器的具體功能包括:注冊(cè)和管理SQLServer服務(wù)器;管理SQLServer服務(wù);創(chuàng)建和管理數(shù)據(jù)庫(kù)及各種數(shù)據(jù)庫(kù)對(duì)象;備份和恢復(fù)數(shù)據(jù)庫(kù);對(duì)SQLServer系統(tǒng)進(jìn)行安全管理;編寫和執(zhí)行T-SQL腳本等。

二、企業(yè)管理器，它具有一個(gè)遵從微軟管理控制臺(tái)(MMC)的管理界面。左窗格以層疊列表的形式(樹型)顯示注冊(cè)的所有SQLServer服務(wù)器，以及每個(gè)服務(wù)器中存儲(chǔ)的數(shù)據(jù)庫(kù)對(duì)象和提供的服務(wù);右窗格顯示樹型目錄中所選擇目錄項(xiàng)的具體內(nèi)容。

三、企業(yè)管理器和查詢分析器都是服務(wù)器端集成的工具，我們可以通過(guò)企業(yè)管理器查看數(shù)據(jù)庫(kù)的結(jié)構(gòu)和相關(guān)的對(duì)象，而用查詢分析器模擬客戶端的功能，這就類似聯(lián)接數(shù)據(jù)庫(kù)的操作，用查詢分析器可以在本地就把數(shù)據(jù)庫(kù)聯(lián)接的問(wèn)題解決。在“控制臺(tái)根目錄”下，有著我們要管理的SQLServer服務(wù)器，順著它逐級(jí)展開，展開每一個(gè)節(jié)點(diǎn)時(shí)，右邊的主界面中都會(huì)顯示這個(gè)節(jié)點(diǎn)的內(nèi)容。我們可以一直看到我們的SQLServer數(shù)據(jù)庫(kù)連接甚至更多。

四、菜單，選中“SQLServer服務(wù)器”，查看一下“操作”菜單上的內(nèi)容；再看一下“SQLServer服務(wù)器”的右鍵菜單，會(huì)發(fā)現(xiàn)它們完全一樣。我們?cè)龠x中“數(shù)據(jù)庫(kù)”這個(gè)節(jié)點(diǎn)，查看一下右鍵菜單和“操作”菜單的子菜單，它們還是完全一樣。這說(shuō)明，“控制臺(tái)”中的菜單，它們的內(nèi)容不是一成不變的，而是由“控制臺(tái)”所管理的內(nèi)容來(lái)決定的。

五、“查看”菜單，它包含有“大圖標(biāo)”、“小圖標(biāo)”、“列表”、“詳細(xì)信息”幾個(gè)選項(xiàng)，我們可以通過(guò)它來(lái)設(shè)定界面中的內(nèi)容以什么方式來(lái)顯示。下面的“自定義”命令可以打開“自定義視圖”對(duì)話框，我們可以通過(guò)這個(gè)對(duì)話框來(lái)更改選項(xiàng)以顯示或者隱藏MMC中的項(xiàng)目，例如“控制臺(tái)樹”或者“標(biāo)準(zhǔn)工具欄”等。“工具”菜單里面的內(nèi)容是SQLServer所特有的，單獨(dú)的“控制臺(tái)”不會(huì)有這項(xiàng)功能，它里面的內(nèi)容全部是針對(duì)“SQLServer企業(yè)管理器”的。我們可以通過(guò)它來(lái)調(diào)度作業(yè)、打開“SQL查詢分析器”、備份和還原數(shù)據(jù)庫(kù)以及管理SQLServer消息等。而且，“SQLServer企業(yè)管理器”自帶了許多向?qū)В覀円部梢栽谶@里啟動(dòng)這些向?qū)?事實(shí)上我們絕大多數(shù)情況下是通過(guò)這里啟動(dòng)這些向?qū)?。

sqlserver executionstack怎么分析

1，victim-list沒(méi)什么可分析的。

2，process-list中關(guān)于各個(gè)process的詳細(xì)信息很重要。

3，再看process中的inputbuf。這個(gè)tag表明了process正在運(yùn)行的語(yǔ)句，因此對(duì)于定位死鎖非常重要。但這里有一個(gè)問(wèn)題，比如上例中，inputbuf是一個(gè)存儲(chǔ)過(guò)程，其中又嵌套了很多其他的存儲(chǔ)過(guò)程，而我們需要在其中找出直接導(dǎo)致死鎖的語(yǔ)句并優(yōu)化，從而解決或減少死鎖。自此我們已經(jīng)有的信息是：導(dǎo)致死鎖的語(yǔ)句由inputbuf中的語(yǔ)句調(diào)用，同時(shí)導(dǎo)致死鎖的語(yǔ)句必定是對(duì)表MatchService的修改語(yǔ)句。如果存儲(chǔ)過(guò)程很簡(jiǎn)單，到此DBA已經(jīng)能夠找到直接導(dǎo)致死鎖的sql了，分析過(guò)程到此結(jié)束。而如果存儲(chǔ)過(guò)程很復(fù)雜，則需要進(jìn)一步分析。

4，現(xiàn)在再進(jìn)一步考察tag, executionStack。executionStack表明了死鎖發(fā)生時(shí)，由該process調(diào)用的，正在運(yùn)行的所有sql。上例中有4條sql。同時(shí)仔細(xì)觀察上例可以發(fā)生，兩個(gè)process的executionStack是完全相同的，因此考察一個(gè)就可以了。另外，如果procname不為空則直接得到了sql，但上例中該tag為空。

我們可能還需要找出包含該sql的具體存儲(chǔ)過(guò)程，然后進(jìn)行優(yōu)化。出了用sql查詢外，推薦使用一個(gè)叫“SQL Search”的第三方工具，很方便，免費(fèi)的。

如何顯示SQLServer 查詢分析器的行號(hào)

只需要在查詢分析器中設(shè)置，

操作如下

工具-

選項(xiàng)-

文本編輯器-

所有語(yǔ)言-

常規(guī)-

顯示-

行號(hào)

也可以參考下列圖片：

分享標(biāo)題：sqlserver分析,sqlserver分析存儲(chǔ)過(guò)程
轉(zhuǎn)載來(lái)源：http://chinadenli.net/article43/dsgphhs.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、品牌網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、營(yíng)銷型網(wǎng)站建設(shè)、手機(jī)網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站

廣告

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