mysql索引優(yōu)化有幾種

MYSQL只是針對(duì)索引的優(yōu)化有3種：

成都創(chuàng)新互聯(lián)主營(yíng)阜南網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,App定制開發(fā),阜南h5微信小程序開發(fā)搭建,阜南網(wǎng)站營(yíng)銷推廣歡迎阜南等地區(qū)企業(yè)咨詢

改成唯一。這樣查詢速度比普通索引要快，不過(guò)也得看你那個(gè)字段是否唯一了。

根據(jù)查詢條件建多個(gè)欄位的索引，這樣比單一索引更快

針對(duì)文字建全文索引

mysql索引

在mysql中，索引是一種特殊的數(shù)據(jù)庫(kù)結(jié)構(gòu)，由數(shù)據(jù)表中的一列或多列組合而成，可以用來(lái)快速查詢數(shù)據(jù)表中有某一特定值的記錄。

通過(guò)索引，查詢數(shù)據(jù)時(shí)不用讀完記錄的所有信息，而只是查詢索引列即可。

通過(guò)索引，查詢數(shù)據(jù)時(shí)不用讀完記錄的所有信息，而只是查詢索引列。否則，數(shù)據(jù)庫(kù)系統(tǒng)將讀取每條記錄的所有信息進(jìn)行匹配。

可以把索引比作新華字典的音序表。例如，要查“庫(kù)”字，如果不使用音序，就需要從字典的 400 頁(yè)中逐頁(yè)來(lái)找。但是，如果提取拼音出來(lái)，構(gòu)成音序表，就只需要從 10 多頁(yè)的音序表中直接查找。這樣就可以大大節(jié)省時(shí)間。

因此，使用索引可以很大程度上提高數(shù)據(jù)庫(kù)的查詢速度，還有效的提高了數(shù)據(jù)庫(kù)系統(tǒng)的性能。

索引的優(yōu)缺點(diǎn)

索引有其明顯的優(yōu)勢(shì)，也有其不可避免的缺點(diǎn)。

優(yōu)點(diǎn)

索引的優(yōu)點(diǎn)如下：

1、通過(guò)創(chuàng)建唯一索引可以保證數(shù)據(jù)庫(kù)表中每一行數(shù)據(jù)的唯一性。

2、可以給所有的 MySQL 列類型設(shè)置索引。

3、可以大大加快數(shù)據(jù)的查詢速度，這是使用索引最主要的原因。

4、在實(shí)現(xiàn)數(shù)據(jù)的參考完整性方面可以加速表與表之間的連接。

5、在使用分組和排序子句進(jìn)行數(shù)據(jù)查詢時(shí)也可以顯著減少查詢中分組和排序的時(shí)間

缺點(diǎn)

增加索引也有許多不利的方面，主要如下：

1、創(chuàng)建和維護(hù)索引組要耗費(fèi)時(shí)間，并且隨著數(shù)據(jù)量的增加所耗費(fèi)的時(shí)間也會(huì)增加。

2、索引需要占磁盤空間，除了數(shù)據(jù)表占數(shù)據(jù)空間以外，每一個(gè)索引還要占一定的物理空間。如果有大量的索引，索引文件可能比數(shù)據(jù)文件更快達(dá)到最大文件尺寸。

3、當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時(shí)候，索引也要?jiǎng)討B(tài)維護(hù)，這樣就降低了數(shù)據(jù)的維護(hù)速度。

使用索引時(shí)，需要綜合考慮索引的優(yōu)點(diǎn)和缺點(diǎn)。

mysql---索引優(yōu)化

索引就是為特定的mysql字段進(jìn)行一些特定的算法排序，比如二叉樹的算法和哈希算法，哈希算法是通過(guò)建立特征值，然后根據(jù)特征值來(lái)快速查找。

1.普通索引:(index)最基本的索引，沒(méi)有任何限制? 目的:加快數(shù)據(jù)的查詢速度

2.唯一索引:(unique)? 與"普通索引"類似，不同的就是：索引列的值必須唯一，但允許有空值。

3.主鍵索引(primary key) 它 是一種特殊的唯一索引，不允許有空值。

4.復(fù)合索引:index(a,b,c)? 為了更多的提高mysql效率可建立組合索引，遵循”最左前綴“原則。

5.全文索引:fulltext? 僅可用于 MyISAM 表，針對(duì)較大的數(shù)據(jù)，生成全文索引很耗時(shí)耗空間。

第一類是myisam存儲(chǔ)引擎使用的叫做b-tree結(jié)構(gòu)，

第二類是innodb存儲(chǔ)引擎使用的叫做聚簇結(jié)構(gòu)（也是一種 b-tree）。 如下圖：

注意：

1.myisam不需要回行處理?

2.innodb不需要回行處理,直接可以獲取數(shù)據(jù),因?yàn)閕nnodb的儲(chǔ)存引擎是包含了數(shù)據(jù)和索引文件的,其主鍵索引包含了數(shù)據(jù),(唯一索引及普通索是沒(méi)有直接包含數(shù)據(jù)的)

1、索引列不能參與計(jì)算

有索引列參與計(jì)算的查詢條件對(duì)索引不友好（甚至無(wú)法使用索引），如from_unixtime(create_time) = '2014-05-29'。

原因很簡(jiǎn)單，如何在節(jié)點(diǎn)中查找到對(duì)應(yīng)key？如果線性掃描，則每次都需要重新計(jì)算，成本太高；如果二分查找，則需要針對(duì)from_unixtime方法確定大小關(guān)系。

因此，索引列不能參與計(jì)算。上述from_unixtime(create_time) = '2014-05-29'語(yǔ)句應(yīng)該寫成create_time = unix_timestamp('2014-05-29')。

2、最左前綴匹配

如有索引(a, b, c, d)，查詢條件a = 1 and b = 2 and c 3 and d = 4，則會(huì)在每個(gè)節(jié)點(diǎn)依次命中a、b、c，無(wú)法命中d。也就是最左前綴匹配原則。

3、冗余和重復(fù)索引

冗余索引是指在相同的列上按照相同的順序創(chuàng)建的相同類型的索引，應(yīng)當(dāng)盡量避免這種索引，發(fā)現(xiàn)后立即刪除。比如有一個(gè)索引(A,B)，再創(chuàng)建索引(A)就是冗余索引。冗余索引經(jīng)常發(fā)生在為表添加新索引時(shí)，比如有人新建了索引(A,B)，但這個(gè)索引不是擴(kuò)展已有的索引(A)

4、避免多個(gè)范圍條件

? ? select user.* from user where login_time '2017-04-01' and age between 18 and 30;

比如想查詢某個(gè)時(shí)間段內(nèi)登錄過(guò)的用戶：它有兩個(gè)范圍條件，login_time列和age列，MySQL可以使用login_time列的索引或者age列的索引，但無(wú)法同時(shí)使用它們 .

5、覆蓋索引 (能擴(kuò)展就不新建)

如果一個(gè)索引包含或者說(shuō)覆蓋所有需要查詢的字段的值，那么就沒(méi)有必要再回表查詢，這就稱為覆蓋索引。覆蓋索引是非常有用的工具，可以極大的提高性能，因?yàn)椴樵冎恍枰獟呙杷饕龝?huì)帶來(lái)許多好處：

1.索引條目遠(yuǎn)小于數(shù)據(jù)行大小，如果只讀取索引，極大減少數(shù)據(jù)訪問(wèn)量2.索引是有按照列值順序存儲(chǔ)的，對(duì)于I/O密集型的范圍查詢要比隨機(jī)從磁盤讀取每一行數(shù)據(jù)的IO要少的多

6、選擇區(qū)分度高的列作索引

如，用性別作索引，那么索引僅能將1000w行數(shù)據(jù)劃分為兩部分（如500w男，500w女），索引幾乎無(wú)效。

區(qū)分度的公式是count(distinct ) / count(*)，表示字段不重復(fù)的比例，比例越大區(qū)分度越好。唯一鍵的區(qū)分度是1，而一些狀態(tài)、性別字段可能在大數(shù)據(jù)面前的區(qū)分度趨近于0。

7、刪除長(zhǎng)期未使用的索引

場(chǎng)景一(覆蓋索引 5)

索引應(yīng)該建在選擇性高的字段上（鍵值唯一的記錄數(shù)/總記錄條數(shù)），選擇性越高索引的效果越好、價(jià)值越大，唯一索引的選擇性最高；

組合索引中字段的順序，選擇性越高的字段排在最前面；

where條件中包含兩個(gè)選擇性高的字段時(shí)，可以考慮分別創(chuàng)建索引，引擎會(huì)同時(shí)使用兩個(gè)索引（在OR條件下，應(yīng)該說(shuō)必須分開建索引）；

不要重復(fù)創(chuàng)建彼此有包含關(guān)系的索引，如index1(a,b,c) 、index2(a,b)、index3(a)；

組合索引的字段不要過(guò)多，如果超過(guò)4個(gè)字段，一般需要考慮拆分成多個(gè)單列索引或更為簡(jiǎn)單的組合索引；

不要濫用索引。因?yàn)檫^(guò)多的索引不僅僅會(huì)增加物理存儲(chǔ)的開銷，對(duì)于插入、刪除、更新操作也會(huì)增加處理上的開銷，而且會(huì)增加優(yōu)化器在選擇索引時(shí)的計(jì)算代價(jià)。

因此太多的索引與不充分、不正確的索引對(duì)性能都是毫無(wú)益處的。一言以蔽之，索引的建立必須慎重，對(duì)每個(gè)索引的必要性都應(yīng)該經(jīng)過(guò)仔細(xì)分析，要有建立的依據(jù)。

mysql 中 創(chuàng)建索引很慢，怎么解決

1. 執(zhí)行計(jì)劃中明明有使用到索引，為什么執(zhí)行還是這么慢？

2. 執(zhí)行計(jì)劃中顯示掃描行數(shù)為 644，為什么 slow log 中顯示 100 多萬(wàn)行？

a. 我們先看執(zhí)行計(jì)劃，選擇的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。結(jié)合 sql 來(lái)看，因?yàn)橛?"ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能會(huì)更差，優(yōu)化器選擇這個(gè)索引避免了排序。

那為什么不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡(jiǎn)單，TASK_DATE 字段區(qū)分度太低了，走這個(gè)索引需要掃描的行數(shù)很大，而且還要進(jìn)行額外的排序，優(yōu)化器綜合判斷代價(jià)更大，所以就不選這個(gè)索引了。不過(guò)如果我們強(qiáng)制選擇這個(gè)索引（用 force index 語(yǔ)法），會(huì)看到 SQL 執(zhí)行速度更快少于 10s，那是因?yàn)閮?yōu)化器基于代價(jià)的原則并不等價(jià)于執(zhí)行速度的快慢；

b. 再看執(zhí)行計(jì)劃中的 type:index，"index" 代表 “全索引掃描”，其實(shí)和全表掃描差不多，只是掃描的時(shí)候是按照索引次序進(jìn)行而不是行，主要優(yōu)點(diǎn)就是避免了排序，但是開銷仍然非常大。

Extra:Using where 也意味著掃描完索引后還需要回表進(jìn)行篩選。一般來(lái)說(shuō)，得保證 type 至少達(dá)到 range 級(jí)別，最好能達(dá)到 ref。

在第 2 點(diǎn)中提到的“慢日志記錄Rows_examined: 1161559，看起來(lái)是全表掃描”，這里更正為“全索引掃描”，掃描行數(shù)確實(shí)等于表的行數(shù)；

c. 關(guān)于執(zhí)行計(jì)劃中：“rows：644”，其實(shí)這個(gè)只是估算值，并不準(zhǔn)確，我們分析慢 SQL 時(shí)判斷準(zhǔn)確的掃描行數(shù)應(yīng)該以 slow log 中的 Rows_examined 為準(zhǔn)。

4. 優(yōu)化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)

優(yōu)化過(guò)程：

TASK_DATE 字段存在索引，但是選擇度很低，優(yōu)化器不會(huì)走這個(gè)索引，建議后續(xù)可以刪除這個(gè)索引：

select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+

在這個(gè) sql 中 REL_DEVID 字段從命名上看選擇度較高，通過(guò)下面 sql 來(lái)檢驗(yàn)確實(shí)如此：

select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+

由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：

select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+

在測(cè)試環(huán)境添加 REL_DEVID，TASK_ID 組合索引，測(cè)試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);

添加索引后執(zhí)行計(jì)劃：

這里還要注意一點(diǎn)“隱式轉(zhuǎn)換”：REL_DEVID 字段數(shù)據(jù)類型為 varchar，需要在 sql 中加引號(hào)：AND T.REL_DEVID = 000000025xxx AND T.REL_DEVID = '000000025xxx'

執(zhí)行時(shí)間從 10s+ 降到 毫秒級(jí)別：

1 row in set (0.00 sec)

結(jié)論

一個(gè)典型的 order by 查詢的優(yōu)化，添加更合適的索引可以避免性能問(wèn)題：執(zhí)行計(jì)劃使用索引并不意味著就能執(zhí)行快。

MySQL性能優(yōu)化之索引設(shè)計(jì)

上一篇給小伙伴們講了關(guān)于SQL查詢性能優(yōu)化的相關(guān)技巧，一個(gè)好的查詢SQL離不開合理的索引設(shè)計(jì)。這篇小二就來(lái)嘮一嘮怎么合理的設(shè)計(jì)一個(gè)索引來(lái)優(yōu)化我們的查詢速度，要是有不合理的地方...嗯..

當(dāng)然啦，開個(gè)玩笑，歡迎小伙伴們指正！

通常情況下，字段類型的選擇是需要根據(jù)業(yè)務(wù)來(lái)判斷的，通常需要遵循以下幾點(diǎn)。

下列各種類型表格內(nèi)容來(lái)自菜鳥教程，權(quán)當(dāng)備忘。

優(yōu)化建議：

注意： INT(2)設(shè)置的為顯示寬度，而不是整數(shù)的長(zhǎng)度，需要配合 ZEROFILL 使用 。

例如 id 設(shè)置為 TINYINT(2) UNSIGNED ，表示無(wú)符號(hào)，可以存儲(chǔ)的最大數(shù)值為255，其中 TINYINT(2) 沒(méi)有配合 ZEROFILL 實(shí)際沒(méi)有任何意義，例如插入數(shù)字200，長(zhǎng)度雖然超過(guò)了兩位，但是這個(gè)時(shí)候是可以插入成功的，查詢結(jié)果同樣為200；插入數(shù)字5時(shí)，同樣查詢結(jié)果為5。

而 TINYINT(2) 配合 ZEROFILL 后，當(dāng)插入數(shù)字5時(shí)，實(shí)際存儲(chǔ)的還是5，不過(guò)在查詢是MySQL會(huì)在前面補(bǔ)上一個(gè)0，即查詢出來(lái)的實(shí)際為 05 。

優(yōu)化建議：

優(yōu)化建議：

通常來(lái)說(shuō)，考慮好表中每個(gè)字段應(yīng)該使用什么類型和長(zhǎng)度，建完表需要做的事情不是馬上建立索引，而是先把相關(guān)主體業(yè)務(wù)開發(fā)完畢，然后把涉及該表的SQL都拿出來(lái)分析之后再建立索引。

盡量少建立單值索引( 唯一索引除外 )，應(yīng)當(dāng)設(shè)計(jì)一個(gè)或者兩三個(gè)聯(lián)合索引，讓每一個(gè)聯(lián)合索引都盡量去包含SQL語(yǔ)句中的 where、order by、group by 的字段，同時(shí)確保聯(lián)合索引的字段順序盡量滿足SQL查詢的最左前綴原則。

索引基數(shù)是指這個(gè)字段在表里總共有多少個(gè)不同的值，比如一張表總共100萬(wàn)行記錄，其中有個(gè)性別字段，性別一共有三個(gè)值：男、女、保密，那么該字段的基數(shù)就是3。

如果對(duì)這種小基數(shù)字段建立索引的話，因?yàn)樗饕龢渲兄挥心小⑴⒈Ｃ苋齻€(gè)值，根本沒(méi)法進(jìn)行快速的二分查找，同時(shí)還需要回表查詢，還不如全表掃描嘞。

一般建立索引，盡量使用那些基數(shù)比較大的字段，那么才能發(fā)揮出B+樹快速二分查找的優(yōu)勢(shì)來(lái)。

在 where 和 order by 出現(xiàn)索引設(shè)計(jì)沖突時(shí)，是優(yōu)先針對(duì)where去設(shè)計(jì)索引？還是優(yōu)先針對(duì)order by設(shè)計(jì)索引？

通常情況下都是優(yōu)先針對(duì) where 來(lái)設(shè)計(jì)索引，因?yàn)橥ǔＧ闆r下都是先 where 條件使用索引快速篩選出來(lái)符合條件的數(shù)據(jù)，然后對(duì)進(jìn)行篩選出來(lái)的數(shù)據(jù)進(jìn)行排序和分組，而 where 條件快速篩選出來(lái)的的數(shù)據(jù)往往不會(huì)很多。

對(duì)生產(chǎn)實(shí)際運(yùn)行過(guò)程中，或者測(cè)試環(huán)境大數(shù)據(jù)量測(cè)試過(guò)程中發(fā)現(xiàn)的慢查詢SQL進(jìn)行特定的索引優(yōu)化、代碼優(yōu)化等策略。

終于輪到實(shí)戰(zhàn)了，小二最喜歡實(shí)戰(zhàn)了。

寫到這里不得不吐槽一下，這個(gè)金三銀四的跳槽季節(jié)，年前提離職了，結(jié)果離職還沒(méi)辦完就封村整整兩個(gè)禮拜了，嗚嗚嗚...

上節(jié)小二就提到會(huì)有個(gè)很有意思的小案例，那么在疫情當(dāng)下，門都出不去的日子，感覺這個(gè)例子更有意思了，咱們來(lái)討論一下各種社交平臺(tái)怎么做的用戶信息搜索呢。

社交平臺(tái)有一個(gè)小伙伴們都喜歡的功能，搜索好友信息，比如小二熟練的點(diǎn)開省份...城市..性別..年齡..身高...

咳咳咳...小二怎么可能干這種事情，小二的心里只有代碼，嗯...沒(méi)錯(cuò)，就是這樣。

這個(gè)就可以說(shuō)是對(duì)于用戶信息的查詢篩選了，通常這種表都是非常大數(shù)據(jù)量的，在不考慮分庫(kù)分表的情況下，怎么通過(guò)索引配合SQL來(lái)優(yōu)化呢？

通常我們?cè)诰帉慡QL是會(huì)寫出類似如下的SQL來(lái)執(zhí)行，有 where、order by、limit 等條件來(lái)查詢。

那么接下來(lái)小二一個(gè)一個(gè)慢慢增加字段來(lái)分析分析，怎么根據(jù)業(yè)務(wù)場(chǎng)景來(lái)設(shè)計(jì)索引。

針對(duì)這種情況，很簡(jiǎn)單，設(shè)計(jì)一個(gè)聯(lián)合索引 (provice, city, sex) 就完事了。

那么這時(shí)候有小伙伴就會(huì)說(shuō)了，很簡(jiǎn)單啊，范圍字段放最后咱還是知道的，聯(lián)合索引改成 (provice, city, sex, age) 不就可以了。

嗯，是的，這么干沒(méi)毛病，但是小伙伴們有沒(méi)有想過(guò)有些人萬(wàn)一既喜歡帥哥又喜歡美女，別想歪了哈...，挺多小姐姐就既喜歡帥哥又喜歡美女的。

那么這個(gè)時(shí)候小姐姐就不搜索性別了，那么這個(gè)時(shí)候聯(lián)合索引只能用到前兩個(gè)字段了，那么不符合咱們的專業(yè)標(biāo)準(zhǔn)啊，咋辦呢？這時(shí)候還是有辦法的，咱們只需要?jiǎng)觿?dòng)小腦袋改改SQL就行了，在沒(méi)有選擇性別時(shí)判斷一下，改成下面這樣就可以了。

咋辦嘞，同樣往聯(lián)合索引里面塞，例如 (provice, city, sex, hobby, xx, age) 。

針對(duì)這種多個(gè)范圍查詢的話，為了比較好的利用索引，在業(yè)務(wù)允許的情況下可以使用固定范圍，然后數(shù)據(jù)庫(kù)字段存儲(chǔ)范圍標(biāo)識(shí)就可以了，這樣就轉(zhuǎn)化為了等值匹配，就可以很好地利用索引了。

例如最后登錄時(shí)間字段不記錄最后登錄時(shí)間，而是記錄設(shè)置字段 is_login_within_seven_days 在7天內(nèi)有登錄則為1，否則為0，最后索引設(shè)計(jì)成 (provice, city, sex, hobby, xx, is_login_within_seven_days, age) 。

那么根據(jù)場(chǎng)景最后設(shè)計(jì)出來(lái)的這個(gè)索引可能已經(jīng)可以覆蓋大部分的查詢流量了，那么如果還有其他一部分熱度比較高的查詢?cè)趺崔k呢，辦法也很簡(jiǎn)單啊，再加一兩個(gè)索引即可。

例如通常會(huì)查詢這個(gè)城市比較受歡迎(評(píng)分：score)的小姐姐，這時(shí)候添加一個(gè)聯(lián)合索引 (provice, city, sex, score) 那么就可以了。

可以看出，索引時(shí)必須結(jié)合場(chǎng)景來(lái)設(shè)計(jì)的，思路就是盡量用不超過(guò)3個(gè)復(fù)雜的聯(lián)合索引來(lái)抗住大部分的80%以上的常用查詢流量，然后再用一兩個(gè)二級(jí)索引來(lái)抗下一些非常用查詢流量。

以上就是小二要給大家分享的索引設(shè)計(jì)，如果能動(dòng)動(dòng)你發(fā)財(cái)?shù)男∈纸o小二點(diǎn)個(gè)免費(fèi)的贊就更好啦~

下篇小二就來(lái)講講MySQL事務(wù)和鎖機(jī)制。

MySQL單表索引設(shè)置

1、索引并不是越多越好，要根據(jù)查詢有針對(duì)性的創(chuàng)建，考慮在WHERE和ORDER BY命令上涉及的列建立索引，可根據(jù)EXPLAIN來(lái)查看是否用了索引還是全表掃描

2、應(yīng)盡量避免在WHERE子句中對(duì)字段進(jìn)行NULL值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

3、值分布很稀少的字段不適合建索引，例如”性別”這種只有兩三個(gè)值的字段

4、字符字段只建前綴索引

5、字符字段最好不要做主鍵

6、不用外鍵，由程序保證約束

7、盡量不用UNIQUE，由程序保證約束

8、使用多列索引時(shí)主意順序和查詢條件保持一致，同時(shí)刪除不必要的單列索引

分享名稱：mysql索引怎么設(shè)置快,mysql添加索引的時(shí)候特別慢
地址分享：http://chinadenli.net/article23/dsippjs.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、網(wǎng)站制作、品牌網(wǎng)站建設(shè)、靜態(tài)網(wǎng)站、搜索引擎優(yōu)化、服務(wù)器托管

廣告

聲明：本網(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)