如何在MYSQL插數(shù)據(jù) ID自增

如何在MYSQL插數(shù)據(jù)ID自增的方法。

我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、南湖ssl等。為成百上千企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的南湖網(wǎng)站制作公司

如下參考：

1.在添加字段之前，第一個應(yīng)該首先檢查當前tb1表的結(jié)構(gòu)，如下圖所示。

2.實例字段列添加到表，如下所示。

3.再次看表結(jié)構(gòu)和比較之前和之后的情況添加字段，如下圖所示。

4.最后，插入新的數(shù)據(jù)行看到的樣子，最后添加自動增長的字段，如下所示。

注意事項：

MySQL使用的SQL語言是訪問數(shù)據(jù)庫最常用的標準語言。MySQL軟件采用雙重許可政策,分為社區(qū)版,商業(yè)版，由于其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特性，一般中小網(wǎng)站開發(fā)選擇MySQL作為數(shù)據(jù)庫。

mysql如何設(shè)置ID自增

設(shè)置自增列

MYSQL的自增列一定要是有索引的列，設(shè)置種子值要在表的后面設(shè)置

--mysql

-- 設(shè)置自增ID從N開始

CREATE TABLE empautoinc(

ID INT PRIMARY KEY AUTO_INCREMENT

) AUTO_INCREMENT = 100 ; --（設(shè)置自增ID從100開始）

insert into empautoinc(id) values(null);

Query OK, 1 row affected (0.00 sec)

mysql select * from empautoinc;

+-----+

| ID |

+-----+

| 100 |

+-----+

1 row in set (0.00 sec)

show table status like 'empautoinc'G;

*************************** 1. row ***************************

Name: empautoinc

Engine: InnoDB

Version: 10

Row_format: Compact

Rows: 1

Avg_row_length: 16384

Data_length: 16384

Max_data_length: 0

Index_length: 0

Data_free: 0

Auto_increment: 101

Create_time: 2016-10-27 01:50:32

Update_time: NULL

Check_time: NULL

Collation: utf8_general_ci

Checksum: NULL

Create_options:

Comment:

1 row in set (0.00 sec)

設(shè)置自增列的步長，可以分為全局級別和會話級別

如果是會話級別，那么當用戶新建一個會話的時候，那么步長又回到了全局級別，所以mysql的步長跟sqlserver的步長有很大的不同

mysql不能設(shè)置為 表級別 的步長

私信666領(lǐng)取資料

技術(shù)分享 | 關(guān)于 MySQL 自增 ID 的事兒

當我們使用 MySQL 進行數(shù)據(jù)存儲時，一般會為一張表設(shè)置一個自增主鍵，當有數(shù)據(jù)行插入時，該主鍵字段則會根據(jù)步長與偏移量增長（默認每次+1）。

下文以 Innodb 引擎為主進行介紹，使用自增主鍵的好處有很多，如：索引空間占比小、范圍查詢與排序都友好、避免像 UUID 這樣隨機字符串帶來的頁分裂問題等...

當我們對該表設(shè)置了自增主鍵之后，則會在該表上產(chǎn)生一個計數(shù)器，用于為自增列分配 ID 。

自增的值并不是保存在表結(jié)構(gòu)信息內(nèi)的，對于不同的版本它們有如下的區(qū)別：

計數(shù)器的值存儲在內(nèi)存中的，重啟后丟棄，下一次將讀取最大的一個自增ID往后繼續(xù)發(fā)號。

計數(shù)器的值將會持久化到磁盤。在每次發(fā)號時都將寫入 Redolog ，并在每個 Checkpoint 都進行保存，重啟時候使用 Redolog 恢復(fù)重啟之前的值。

可以預(yù)先確定插入行數(shù)的語句（像簡單 insert 的語句包含多個 value 這種情況也是屬于簡單插入，因為在進行插入時就已經(jīng)可以確定行數(shù)了）

預(yù)先不知道要插入的行數(shù)的語句（包括 INSERT ... SELECT, REPLACE ... SELECT 和 LOAD DATA 語句，但不包括 plain INSERT ）

如果一個事務(wù)正在向表中插入值，則會產(chǎn)生表級的共享鎖，以便當前事務(wù)插入的行接收連續(xù)的主鍵值。

當處于[ 傳統(tǒng)模式 ]與[ 連續(xù)模式 ]時，每次訪問計數(shù)器時都會加上一個名為 AUTO-INC 的表級鎖

傳統(tǒng)模式：鎖只持有到該語句執(zhí)行結(jié)束，注意是語句結(jié)束，不是事務(wù)結(jié)束

連續(xù)模式：批量插入時鎖持有到該語句執(zhí)行結(jié)束，簡單插入時鎖持有到申請完自增ID后即釋放，不直到語句完成

通過調(diào)整 innodb_autoinc_lock_mode 配置項，可以定義 AUTO-INC 鎖的模式，不同的模式對應(yīng)的策略與鎖的粒度也將不同。

當使用基于 Binlog 的復(fù)制場景時，對于 statement（SBR）同步模式下只有[ 傳統(tǒng)模式 ]與[ 連續(xù)模式 ]能保證語句的正確性。

基于 row（RBR）行復(fù)制的情況下任何配置模式都可以。

執(zhí)行語句時加 AUTO-INC 表級鎖，執(zhí)行完畢后釋放

針對 Bulk Inserts 時才會采用 AUTO-INC 鎖，而針對 Simple Inserts 時，則采用了一種新的輕量級的互斥鎖來分配 auto_increment 列的值。

該模式下可以保證同一條 insert 語句中新插入的自增 ID 都是連續(xù)的，但如果前一個事務(wù) rollback 丟棄了一部分 ID 的話也會存在后續(xù) ID 出現(xiàn)間隔的情況。

來一個分配一個，不會產(chǎn)生 AUTO-INC 表級鎖 ，僅僅會鎖住分配 ID 的過程。

由于鎖的粒度減少，多條語句在插入時進行鎖競爭，自增長的值可能不是連續(xù)的。

且當 Binlog 模式為 statement（SBR）時自增 ID 不能保證數(shù)據(jù)的正確性

不一定，業(yè)務(wù)也不應(yīng)該過分依賴 MySQL 自增 ID 的連續(xù)性，在以下三種情況下，并不能保證自增 ID 的連續(xù)性：

假設(shè)已存在數(shù)據(jù){1,張三}，且張三所屬的字段設(shè)置了唯一主鍵

此時再次插入{null,張三}時候，主鍵沖突插入失敗，但表的計數(shù)器已由2變成了3

當下次插入{null,李四}的時候最終入庫的會變成{3,李四}

在一個事務(wù)里進行數(shù)據(jù)的插入，但最后并沒提交，而是執(zhí)行了 Rollback 。那么計數(shù)器已遞增的 ID 是不會返還的，而是被直接丟棄。

發(fā)生大量插入時可能會出現(xiàn)自增 ID 并不是連續(xù)的情況

當我們?yōu)楸碓O(shè)置了自增主鍵后，自增 ID 的范圍則與主鍵的數(shù)據(jù)類型長度相關(guān)。

如果沒有一張表里沒有設(shè)置任何主鍵，則會自動生成一個隱性的6字節(jié)的 row_id 作為主鍵，它的取值范圍為 0 到 2^48-1。

row_id 是由一個全局的 dict_sys.row_id 參數(shù)進行維護的，所有沒有主鍵的表都會用上它（并不是每一個表單獨占一份 row_id list ）

那么針對這兩種主鍵，則會有以下兩種情況發(fā)生：

當自增 ID 到達上限后，受到主鍵數(shù)據(jù)類型的影響，計數(shù)器發(fā)放的下一個 ID 也是當前這個 Max ID ，當執(zhí)行語句時則會提示主鍵沖突。

建議根據(jù)業(yè)務(wù)合理規(guī)劃，在進行表設(shè)計時就選擇適合的數(shù)據(jù)類型。

當然也可以直接選擇 Bigint 類型，它的取值范圍是無符號情況下：0到 2^64–1（18446744073709551615）

這里并不是指 bigint 類型一定不會用完，畢竟一個有范圍的持續(xù)增長的值一定會有溢出的時候，只是說一般場景下它都是足夠使用的。

當 row_id 使用完后則又會從 0 開始發(fā)放，此時新插入的數(shù)據(jù)將覆蓋回 row_id=0 的數(shù)據(jù)行。

由于它并不產(chǎn)生錯誤，還會造成數(shù)據(jù)的覆蓋寫。所以我們平時還是盡量給表都設(shè)置一個合理的主鍵才是。

在實際業(yè)務(wù)場景中，ID 常常需要返回給客戶端用來進行相關(guān)業(yè)務(wù)操作。

假如我們有個 userinfo?uid=? 的 API 接口，而用戶 ID 是自增的，這時會發(fā)生什么？

該接口通過簡單的嘗試就可以暴露出真實的業(yè)務(wù)用戶總數(shù)，可以很方便的使用爬蟲從1開始遞增獲取數(shù)據(jù)信息。

那么有的同學(xué)說，我既想使用自增 ID 帶來的好處，也不想承受這種比較常見的問題，那該怎么辦呢？

在輸出或者獲取前對指定字段進行可逆的轉(zhuǎn)義操作

優(yōu)點：實現(xiàn)起來比較簡單，無論單體業(yè)務(wù)或者分布式應(yīng)用都無需考慮對數(shù)據(jù)源的解析，只需在客戶端實現(xiàn)自己的轉(zhuǎn)義與解析方法即可；

缺點：業(yè)務(wù)入侵較大，且需要前后端各個合作方確認統(tǒng)一的標準；如果轉(zhuǎn)義方法有調(diào)整，變更影響面也會很大；字符串長度會隨ID長度而變化，使用空位填充也會特別明顯；

優(yōu)點：由于采用了時間戳進行 ID 生成，該 ID 是有序的，對范圍查詢與排序都比較友好；

缺點：需要保證發(fā)號節(jié)點的高可用性；另外由于生成時依賴時間戳，需要考慮時鐘回撥與時鐘同步的問題；

維護一份 ID 與 hash 的映射字典，它可以存在于客戶端本身，也可以依賴其他如 Redis 、ETCD 之類的組件

優(yōu)點：hash 長度不會隨著 ID 長度或值的變化而變化；可以根據(jù)已有的 hash code 來造布隆過濾器；

缺點：業(yè)務(wù)入侵較大，查詢時同樣需要先根據(jù) hash key 找到對應(yīng)的 ID 值；需要考慮選擇合適的 hash 算法以及解決 hash 沖突或擴容的問題。

一文讓你徹底弄懂MySQL自增列

MYSQL的自增列在實際生產(chǎn)中應(yīng)用的非常廣泛，相信各位所在的公司or團隊，MYSQL開發(fā)規(guī)范中一定會有要求盡量使用自增列去充當表的主鍵，為什么DBA會有這樣的要求，各位在使用MYSQL自增列時遇到過哪些問題？這些問題是由什么原因造成的呢？本文由淺入深，帶領(lǐng)大家徹底弄懂MYSQL的自增機制。

1.? 通過auto_increment關(guān)鍵字來指定自增的列，并指定自增列的初始值為1。

[root@localhost][test1]Create table t(id int auto_increment ,namevarchar(10),primary key(id))auto_increment=1;

QueryOK, 0 rows affected (0.63 sec)

2.? 自增列上必須有索引，將t表的主鍵索引刪除掉，會報錯

[root@localhost][test1]alter table t drop primary key;

ERROR1075 (42000): Incorrect table definition; there can be only one auto column andit must be defined as a key

3.? 設(shè)定auto_increment_increment參數(shù)，可以調(diào)整自增步長，該參數(shù)有session級跟global級，在分庫分表以及雙主or多主的模式下比較有用。

4.? 一個表上只能有一個自增列

5.? Mysql5.7及以下版本，innodb表的自增值保存在內(nèi)存中，重啟后表的自增值會設(shè)為max(id)+1，而myisam引擎的自增值是保存在文件中，重啟不會丟失。Mysql8.0開始，innodb的自增id能持久化了，重啟mysql，自增ID不會丟。

首先：表中自增列的上限是根據(jù)自增列的字段類型來定的。

若設(shè)定了自增id充當主鍵，當達到了自增id的上限值時，會發(fā)生什么樣的事情呢？還是以上面創(chuàng)建的 t表為例， 先回顧它的表結(jié)構(gòu)：

CREATETABLE `t` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(10) COLLATE utf8mb4_binDEFAULT NULL,

PRIMARY KEY (`id`)

)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

無符號的int類型，上限是2147483647。這里我們將表的自增值設(shè)為2147483647，再插入兩行數(shù)據(jù)：

[root@localhost][test1]alter table t auto_increment=2147483647;

QueryOK, 0 rows affected (0.01 sec)

Records:0? Duplicates: 0? Warnings: 0

[root@localhost][test1]insert into t(name) values ('test');??????????

QueryOK, 1 row affected (0.01 sec)

[root@localhost][test1]insert into t(name) values ('test');

ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'

可以看到，第一個插入沒問題，因為自增列的值為2147483647，這是達到了上限，還沒有超過，第二行數(shù)據(jù)插入時，則報出主鍵重復(fù)，在達到上限后，無法再分配新的更大的自增值，也沒有從1開始從頭分配，在這里表的auto_increment值會一直是2147483647。

對于寫入量大，且經(jīng)常刪除數(shù)據(jù)的表，自增id設(shè)為int類型還是偏小的，所以我們?yōu)榱吮苊獬霈F(xiàn)自增id漲滿的情況，這邊統(tǒng)一建議自增id的類型設(shè)為unsigned bingint，這樣基本可以保障表的自增id是永遠夠用的。

這里內(nèi)容比較多，innodb是索引組織表，所以涉及到索引的知識，但這不是本文的重點，我們快速回顧索引知識：

1.? Innodb索引分為主鍵跟輔助索引，主鍵即全表，輔助索引葉子節(jié)點保存主鍵的值，而主鍵的葉子節(jié)點保存數(shù)據(jù)行，中間節(jié)點存著葉子節(jié)點的路由值。

2.? Innodb存儲數(shù)據(jù)（索引）的單位是頁，這里默認是16K，這也意味著，數(shù)據(jù)本身越小，一個頁中能存數(shù)據(jù)的量越多，而檢索效率不僅僅由索引的層數(shù)來決定，更是由一次能夠緩存的數(shù)據(jù)量來定，也就是說數(shù)據(jù)本身越小，則一次IO能夠提取到緩沖區(qū)的數(shù)據(jù)越多（OS每次IO的量是固定的4K），查詢的效率越好。

其實能夠理解索引的結(jié)構(gòu)及索引寫入插入、更新的原理，則自然就明白為何建議使用自增id。這里我直接列出使用自增id 當主鍵的好處吧：

1.? 順序?qū)懭?，避免了葉的分裂，數(shù)據(jù)寫入效率好

2.? 縮小了表的體積，特別是相比于UUID當主鍵，甚至組合字段當主鍵時，效果更明顯

3.? 查詢效率好，原因就是我上面說到索引知識的第二點。

4.? 某些情況下，我們可以利用自增id來統(tǒng)計大表的大致行數(shù)。

5.? 在數(shù)據(jù)歸檔or垃圾數(shù)據(jù)清理時，也可方便的利用這個id去操作，效率高。

容易出現(xiàn)不連續(xù)的id

有的同志會發(fā)現(xiàn)，自己的表中id值存在空洞，如類似于1、2、3、8、9、10這樣，有的適合有想依賴于自增id的連續(xù)性來實現(xiàn)業(yè)務(wù)邏輯，所以會想方設(shè)法去修改id讓其變的連續(xù)，其實，這是沒有必要的，這一塊的業(yè)務(wù)邏輯交由MySQL實現(xiàn)是很不理智的，表的記錄小還好，要是表的數(shù)據(jù)量很大，修改起來就糟糕了。那么，為什么自增id會容易出現(xiàn)空洞呢？

自增id的修改機制如下：

在MySQL里面，如果字段id被定義為AUTO_INCREMENT，在插入一行數(shù)據(jù)的時候，自增值的行為如下：

1. 如果插入數(shù)據(jù)時id字段指定為0、null 或未指定值，那么就把這個表當前的

AUTO_INCREMENT值填到自增字段；

2. 如果插入數(shù)據(jù)時id字段指定了具體的值，就直接使用語句里指定的值。

根據(jù)要插入的值和當前自增值的大小關(guān)系，自增值的變更結(jié)果也會有所不同。假設(shè)，某次要插入的值是X，當前的自增值是Y。

1. 如果XY，那么這個表的自增值不變；

2. 如果X≥Y，就需要把當前自增值修改為 新的自增值 。

新的自增值生成算法是：從auto_increment_offset開始，以auto_increment_increment為步長，持續(xù)疊加，直到找到第一個大于X的值，作為新的自增值。

Insert、update、delete操作會讓id不連續(xù)。

Delete、update：刪除中間數(shù)據(jù)，會造成空動，而修改自增id值，也會造成空洞（這個很少）。

Insert：插入報錯（唯一鍵沖突與事務(wù)回滾），會造成空洞，因為這時候自增id已經(jīng)分配出去了，新的自增值已經(jīng)生成，如下面例子：

[root@localhost][test1] select * fromt;

+----+------+

| id | name |

+----+------+

|? 1| aaa? |

|? 2| aaa? |

|? 3| aaa? |

|? 4| aaa? |

+----+------+

4 rows in set (0.00 sec)

[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';

+----------------+

| Auto_increment |

+----------------+

|????????????? 5 |

+----------------+

1 row in set (0.00 sec)

[root@localhost][test1] begin;

Query OK, 0 rows affected (0.00 sec)

[root@localhost][test1] insert intot(name) values('aaa');

Query OK, 1 row affected (0.00 sec)

[root@localhost][test1] select * fromt;

+----+------+

| id | name |

+----+------+

|? 1| aaa? |

|? 2| aaa? |

|? 3| aaa? |

|? 4| aaa? |

|? 5| aaa? |

+----+------+

5 rows in set (0.00 sec)

[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';

+----------------+

| Auto_increment |

+----------------+

|????????????? 6 |

+----------------+

1 row in set (0.00 sec)

[root@localhost][test1] rollback;

Query OK, 0 rows affected (0.00 sec)

[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';

+----------------+

| Auto_increment |

+----------------+

|????????????? 6 |

+----------------+

1 row in set (0.01 sec)

[root@localhost][test1] select * fromt;

+----+------+

| id | name |

+----+------+

|? 1| aaa? |

|? 2| aaa? |

|? 3| aaa? |

|? 4| aaa? |

+----+------+

4 rows in set (0.00 sec)

可以看到，雖然事務(wù)回滾了，但自增id已經(jīng)回不到從前啦，唯一鍵沖突也是這樣的，這里就不做測試了。

在批量插入時（insert select等），也存在空洞的問題?？聪旅鎸嶒灒?/p>

[root@localhost][test1] select * fromt;

+----+------+

| id | name |

+----+------+

|? 1| aaa? |

|? 2| aaa? |

|? 3| aaa? |

|? 4| aaa? |

+----+------+

4 rows in set (0.00 sec)

[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';

+----------------+

| Auto_increment |

+----------------+

|????????????? 5 |

+----------------+

1 row in set (0.00 sec)

[root@localhost][test1] insert intot(name) select name from t;??????????????????????

Query OK, 4 rows affected (0.04 sec)

Records: 4?Duplicates: 0? Warnings: 0

[root@localhost][test1] select * fromt;

+----+------+

| id | name |

+----+------+

|? 1| aaa? |

|? 2| aaa? |

|? 3| aaa? |

|? 4| aaa? |

|? 5| aaa? |

|? 6| aaa? |

|? 7| aaa? |

|? 8| aaa? |

+----+------+

8 rows in set (0.00 sec)

[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';

+----------------+

| Auto_increment |

+----------------+

|???????????? 12 |

+----------------+

1 row in set (0.00 sec)

可以看到，批量插入，導(dǎo)致下一個id值不為9了，再插入數(shù)據(jù)，即產(chǎn)生了空洞，這里是由mysql申請自增值的機制所造成的，MySQL在批量插入時，若一個值申請一個id，效率太慢，影響了批量插入的速度，故mysql采用下面的策略批量申請id。

1.? 語句執(zhí)行過程中，第一次申請自增id，會分配1個；

2.? 1個用完以后，這個語句第二次申請自增id，會分配2個；

3.? 2個用完以后，還是這個語句，第三次申請自增id，會分配4個；

4.? 依此類推，同一個語句去申請自增id，每次申請到的自增id個數(shù)都是上一次的兩倍。

在對自增列進行操作時，存在著自增鎖，mysql的innodb_autoinc_lock_mode參數(shù)控制著自增鎖的上鎖機制。該參數(shù)有0、1、2三種模式：

0：語句執(zhí)行結(jié)束后釋放自增鎖，MySQL5.0時采用這種模式，并發(fā)度較低。

1：mysql的默認設(shè)置。普通的insert語句申請后立馬釋放，insert select、replace insert、load data等批量插入語句要等語句執(zhí)行結(jié)束后才釋放，并發(fā)讀得到提升

2：所有的語句都是申請后立馬釋放，并發(fā)度大大提升！但是在binlog為statement格式時，主從數(shù)據(jù)會發(fā)生不一致。這一塊網(wǎng)上有很多介紹，我不做介紹了。

在徹底了解了MYSQL的自增機制以后，在實際生產(chǎn)中就能靈活避坑，這里建議不要用自增id值去當表的行數(shù)，當需要對大表準確統(tǒng)計行數(shù)時，可以去count(*)從庫，如果業(yè)務(wù)很依賴大表的準確行數(shù)，直接弄個中間表來統(tǒng)計，或者考慮要不要用mysql的innodb來存儲數(shù)據(jù)，這個是需要自己去權(quán)衡。另外對于要求很高的寫入性能，但寫入量又比較大的業(yè)務(wù)，自增id的使用依然存在熱點寫入的問題，存在性能瓶頸，這時候可通過分庫分表來解決。

mysql 主鍵自增 怎么處理

方法一： 如果曾經(jīng)的數(shù)據(jù)都不需要的話，可以直接清空所有數(shù)據(jù)，并將自增字段恢復(fù)從1開始計數(shù)

truncate table 表名

方法二： dbcc checkident (’table_name’, reseed, new_reseed_value) 當前值設(shè)置為 new_reseed_value。如果自創(chuàng)建表后沒有將行插入該表，則在執(zhí)行 DBCC CHECKIDENT 后插入的第一行將使用 new_reseed_value 作為標識。否則，下一個插入的行將使用 new_reseed_value + 1。如果 new_reseed_value 的值小于標識列中的最大值，以后引用該表時將產(chǎn)生 2627 號錯誤信息。

方法二不會清空已有數(shù)據(jù)，操作比較靈活，不僅可以將自增值歸零，也適用于刪除大量連續(xù)行后，重新設(shè)置自增值并插入新的數(shù)據(jù)；或從新的值開始，當然不能和已有的沖突。

$sql="delete from $table_vote";

mysql_query($sql, $link);

$sql="alter table $table_vote auto_increment=1";

mysql_query($sql, $link);

網(wǎng)頁名稱：mysql自增怎么用 mysql實現(xiàn)自增
轉(zhuǎn)載來源：http://jinyejixie.com/article20/dosedco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、定制網(wǎng)站、搜索引擎優(yōu)化、建站公司、外貿(mào)建站、外貿(mào)網(wǎng)站建設(shè)

廣告

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