數(shù)據(jù)庫查找的原理是什么？

關(guān)系型數(shù)據(jù)庫采用結(jié)構(gòu)化查詢語言（即SQL）來對(duì)數(shù)據(jù)庫進(jìn)行查詢，SQL早已獲得了各個(gè)數(shù)據(jù)庫廠商的支持，成為數(shù)據(jù)庫行業(yè)的標(biāo)準(zhǔn)。它能夠支持?jǐn)?shù)據(jù)庫的CRUD（增加、查詢、更新、刪除）操作，具有非常強(qiáng)大的功能，SQL可以采用類似索引的方法來加快查詢操作。

創(chuàng)新互聯(lián)長(zhǎng)期為近1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為霞浦企業(yè)提供專業(yè)的做網(wǎng)站、成都網(wǎng)站制作，霞浦網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

NoSQL數(shù)據(jù)庫使用的是非結(jié)構(gòu)化查詢語言（UnQL），它以數(shù)據(jù)集（像文檔）為單位來管理和操作數(shù)據(jù)。由于它沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，所以每個(gè)數(shù)據(jù)庫廠商提供產(chǎn)品標(biāo)準(zhǔn)是不一樣的，NoSQL中的文檔Id與關(guān)系型表中主鍵的概念類似，NoSQL數(shù)據(jù)庫采用的數(shù)據(jù)訪問模式相對(duì)SQL更簡(jiǎn)單而精確。

擴(kuò)展資料

擴(kuò)展方式——

當(dāng)前社會(huì)和科學(xué)飛速發(fā)展，要支持日益增長(zhǎng)的數(shù)據(jù)庫存儲(chǔ)需求，當(dāng)然要求數(shù)據(jù)庫有良好的擴(kuò)展性能，并且要求數(shù)據(jù)庫支持更多數(shù)據(jù)并發(fā)量，擴(kuò)展方式是NoSQL數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫差別最大的地方。

NoSQL數(shù)據(jù)庫由于使用的是數(shù)據(jù)集的存儲(chǔ)方式，它的存儲(chǔ)方式一定是分布式的，它可以采用橫向的方式來開展數(shù)據(jù)庫，也就是可以添加更多數(shù)據(jù)庫服務(wù)器到資源池，然后由這些增加的服務(wù)器來負(fù)擔(dān)數(shù)據(jù)量增加的開銷。

nosql數(shù)據(jù)庫的幾大類型

1. 鍵值數(shù)據(jù)庫

相關(guān)產(chǎn)品：Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached

應(yīng)用：內(nèi)容緩存

優(yōu)點(diǎn)：擴(kuò)展性好、靈活性好、大量寫操作時(shí)性能高

缺點(diǎn)：無法存儲(chǔ)結(jié)構(gòu)化信息、條件查詢效率較低

使用者：百度云（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Ridis和Memcached）

2. 列族數(shù)據(jù)庫

相關(guān)產(chǎn)品：BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS

應(yīng)用：分布式數(shù)據(jù)存儲(chǔ)與管理

優(yōu)點(diǎn)：查找速度快、可擴(kuò)展性強(qiáng)、容易進(jìn)行分布式擴(kuò)展、復(fù)雜性低

使用者：Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Facebook（HBase）

3. 文檔數(shù)據(jù)庫

相關(guān)產(chǎn)品：MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit

應(yīng)用：存儲(chǔ)、索引并管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù)

優(yōu)點(diǎn)：性能好、靈活性高、復(fù)雜性低、數(shù)據(jù)結(jié)構(gòu)靈活

缺點(diǎn)：缺乏統(tǒng)一的查詢語言

使用者：百度云數(shù)據(jù)庫（MongoDB）、SAP（MongoDB）

4. 圖形數(shù)據(jù)庫

圖形數(shù)據(jù)庫-使用圖作為數(shù)據(jù)模型來存儲(chǔ)數(shù)據(jù)。

相關(guān)產(chǎn)品：Neo4J、OrientDB、InfoGrid、GraphDB

應(yīng)用：大量復(fù)雜、互連接、低結(jié)構(gòu)化的圖結(jié)構(gòu)場(chǎng)合，如社交網(wǎng)絡(luò)、推薦系統(tǒng)等

優(yōu)點(diǎn)：靈活性高、支持復(fù)雜的圖形算法、可用于構(gòu)建復(fù)雜的關(guān)系圖譜

缺點(diǎn)：復(fù)雜性高、只能支持一定的數(shù)據(jù)規(guī)模

使用者：Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）

mysql索引有幾種

Mysql目前主要有以下幾種索引類型：FULLTEXT，HASH，BTREE，RTREE。

那么，這幾種索引有什么功能和性能上的不同呢？

FULLTEXT

即為全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用，不過目前只有 CHAR、VARCHAR ，TEXT 列上可以創(chuàng)建全文索引。值得一提的是，在數(shù)據(jù)量較大時(shí)候，現(xiàn)將數(shù)據(jù)放入一個(gè)沒有全局索引的表中，然后再用CREATE INDEX創(chuàng)建FULLTEXT索引，要比先為一張表建立FULLTEXT然后再將數(shù)據(jù)寫入的速度快很多。

全文索引并不是和MyISAM一起誕生的，它的出現(xiàn)是為了解決WHERE name LIKE “%word%"這類針對(duì)文本的模糊查詢效率較低的問題。在沒有全文索引之前，這樣一個(gè)查詢語句是要進(jìn)行遍歷數(shù)據(jù)表操作的，可見，在數(shù)據(jù)量較大時(shí)是極其的耗時(shí)的，如果沒有異步IO處理，進(jìn)程將被挾持，很浪費(fèi)時(shí)間，當(dāng)然這里不對(duì)異步IO作進(jìn)一步講解，想了解的童鞋，自行谷哥。

全文索引的使用方法并不復(fù)雜：

創(chuàng)建ALTER TABLE table ADD INDEX `FULLINDEX` USING FULLTEXT(`cname1`[,cname2…]);

使用SELECT * FROM table WHERE MATCH(cname1[,cname2…]) AGAINST ('word' MODE );

其中， MODE為搜尋方式（IN BOOLEAN MODE ，IN NATURAL LANGUAGE MODE ，IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION / WITH QUERY EXPANSION）。

關(guān)于這三種搜尋方式，愚安在這里也不多做交代，簡(jiǎn)單地說，就是，布爾模式，允許word里含一些特殊字符用于標(biāo)記一些具體的要求，如+表示一定要有，-表示一定沒有，*表示通用匹配符，是不是想起了正則，類似吧；自然語言模式，就是簡(jiǎn)單的單詞匹配；含表達(dá)式的自然語言模式，就是先用自然語言模式處理，對(duì)返回的結(jié)果，再進(jìn)行表達(dá)式匹配。

對(duì)搜索引擎稍微有點(diǎn)了解的同學(xué)，肯定知道分詞這個(gè)概念，F(xiàn)ULLTEXT索引也是按照分詞原理建立索引的。西文中，大部分為字母文字，分詞可以很方便的按照空格進(jìn)行分割。但很明顯，中文不能按照這種方式進(jìn)行分詞。那又怎么辦呢？這個(gè)向大家介紹一個(gè)Mysql的中文分詞插件Mysqlcft，有了它，就可以對(duì)中文進(jìn)行分詞，想了解的同學(xué)請(qǐng)移步Mysqlcft，當(dāng)然還有其他的分詞插件可以使用。

HASH

Hash這個(gè)詞，可以說，自打我們開始碼的那一天起，就開始不停地見到和使用到了。其實(shí)，hash就是一種（key=value）形式的鍵值對(duì)，如數(shù)學(xué)中的函數(shù)映射，允許多個(gè)key對(duì)應(yīng)相同的value，但不允許一個(gè)key對(duì)應(yīng)多個(gè)value。正是由于這個(gè)特性，hash很適合做索引，為某一列或幾列建立hash索引，就會(huì)利用這一列或幾列的值通過一定的算法計(jì)算出一個(gè)hash值，對(duì)應(yīng)一行或幾行數(shù)據(jù)（這里在概念上和函數(shù)映射有區(qū)別，不要混淆）。在java語言中，每個(gè)類都有自己的hashcode()方法，沒有顯示定義的都繼承自object類，該方法使得每一個(gè)對(duì)象都是唯一的，在進(jìn)行對(duì)象間equal比較，和序列化傳輸中起到了很重要的作用。hash的生成方法有很多種，足可以保證hash碼的唯一性，例如在MongoDB中，每一個(gè)document都有系統(tǒng)為其生成的唯一的objectID（包含時(shí)間戳，主機(jī)散列值，進(jìn)程PID，和自增ID）也是一種hash的表現(xiàn)。額，我好像扯遠(yuǎn)了-_-!

由于hash索引可以一次定位，不需要像樹形索引那樣逐層查找,因此具有極高的效率。那為什么還需要其他的樹形索引呢？

在這里愚安就不自己總結(jié)了。引用下園子里其他大神的文章：來自 14的路 的MySQL的btree索引和hash索引的區(qū)別

（1）Hash 索引僅僅能滿足"=","IN"和"="查詢，不能使用范圍查詢。

由于 Hash 索引比較的是進(jìn)行 Hash 運(yùn)算之后的 Hash 值，所以它只能用于等值的過濾，不能用于基于范圍的過濾，因?yàn)榻?jīng)過相應(yīng)的 Hash 算法處理之后的 Hash 值的大小關(guān)系，并不能保證和Hash運(yùn)算前完全一樣。

（2）Hash 索引無法被用來避免數(shù)據(jù)的排序操作。

由于 Hash 索引中存放的是經(jīng)過 Hash 計(jì)算之后的 Hash 值，而且Hash值的大小關(guān)系并不一定和 Hash 運(yùn)算前的鍵值完全一樣，所以數(shù)據(jù)庫無法利用索引的數(shù)據(jù)來避免任何排序運(yùn)算；

（3）Hash 索引不能利用部分索引鍵查詢。

對(duì)于組合索引，Hash 索引在計(jì)算 Hash 值的時(shí)候是組合索引鍵合并后再一起計(jì)算 Hash 值，而不是單獨(dú)計(jì)算 Hash 值，所以通過組合索引的前面一個(gè)或幾個(gè)索引鍵進(jìn)行查詢的時(shí)候，Hash 索引也無法被利用。

（4）Hash 索引在任何時(shí)候都不能避免表掃描。

前面已經(jīng)知道，Hash 索引是將索引鍵通過 Hash 運(yùn)算之后，將 Hash運(yùn)算結(jié)果的 Hash 值和所對(duì)應(yīng)的行指針信息存放于一個(gè) Hash 表中，由于不同索引鍵存在相同 Hash 值，所以即使取滿足某個(gè) Hash 鍵值的數(shù)據(jù)的記錄條數(shù)，也無法從 Hash 索引中直接完成查詢，還是要通過訪問表中的實(shí)際數(shù)據(jù)進(jìn)行相應(yīng)的比較，并得到相應(yīng)的結(jié)果。

（5）Hash 索引遇到大量Hash值相等的情況后性能并不一定就會(huì)比B-Tree索引高。

對(duì)于選擇性比較低的索引鍵，如果創(chuàng)建 Hash 索引，那么將會(huì)存在大量記錄指針信息存于同一個(gè) Hash 值相關(guān)聯(lián)。這樣要定位某一條記錄時(shí)就會(huì)非常麻煩，會(huì)浪費(fèi)多次表數(shù)據(jù)的訪問，而造成整體性能低下。

愚安我稍作補(bǔ)充，講一下HASH索引的過程，順便解釋下上面的第4,5條：

當(dāng)我們?yōu)槟骋涣谢蚰硯琢薪ash索引時(shí)（目前就只有MEMORY引擎顯式地支持這種索引），會(huì)在硬盤上生成類似如下的文件：

hash值 存儲(chǔ)地址

1db54bc745a1 77#45b5

4bca452157d4 76#4556,77#45cc…

…

hash值即為通過特定算法由指定列數(shù)據(jù)計(jì)算出來，磁盤地址即為所在數(shù)據(jù)行存儲(chǔ)在硬盤上的地址（也有可能是其他存儲(chǔ)地址，其實(shí)MEMORY會(huì)將hash表導(dǎo)入內(nèi)存）。

這樣，當(dāng)我們進(jìn)行WHERE age = 18 時(shí)，會(huì)將18通過相同的算法計(jì)算出一個(gè)hash值==在hash表中找到對(duì)應(yīng)的儲(chǔ)存地址==根據(jù)存儲(chǔ)地址取得數(shù)據(jù)。

所以，每次查詢時(shí)都要遍歷hash表，直到找到對(duì)應(yīng)的hash值，如（4），數(shù)據(jù)量大了之后，hash表也會(huì)變得龐大起來，性能下降，遍歷耗時(shí)增加，如（5）。

BTREE

BTREE索引就是一種將索引值按一定的算法，存入一個(gè)樹形的數(shù)據(jù)結(jié)構(gòu)中，相信學(xué)過數(shù)據(jù)結(jié)構(gòu)的童鞋都對(duì)當(dāng)初學(xué)習(xí)二叉樹這種數(shù)據(jù)結(jié)構(gòu)的經(jīng)歷記憶猶新，反正愚安我當(dāng)時(shí)為了軟考可是被這玩意兒好好地折騰了一番，不過那次考試好像沒怎么考這個(gè)。如二叉樹一樣，每次查詢都是從樹的入口root開始，依次遍歷node，獲取leaf。

BTREE在MyISAM里的形式和Innodb稍有不同

在 Innodb里，有兩種形態(tài)：一是primary key形態(tài)，其leaf node里存放的是數(shù)據(jù)，而且不僅存放了索引鍵的數(shù)據(jù)，還存放了其他字段的數(shù)據(jù)。二是secondary index，其leaf node和普通的BTREE差不多，只是還存放了指向主鍵的信息.

而在MyISAM里，主鍵和其他的并沒有太大區(qū)別。不過和Innodb不太一樣的地方是在MyISAM里，leaf node里存放的不是主鍵的信息，而是指向數(shù)據(jù)文件里的對(duì)應(yīng)數(shù)據(jù)行的信息.

RTREE

RTREE在mysql很少使用，僅支持geometry數(shù)據(jù)類型，支持該類型的存儲(chǔ)引擎只有MyISAM、BDb、InnoDb、NDb、Archive幾種。

相對(duì)于BTREE，RTREE的優(yōu)勢(shì)在于范圍查找.

各種索引的使用情況

（1）對(duì)于BTREE這種Mysql默認(rèn)的索引類型，具有普遍的適用性

（2）由于FULLTEXT對(duì)中文支持不是很好，在沒有插件的情況下，最好不要使用。其實(shí)，一些小的博客應(yīng)用，只需要在數(shù)據(jù)采集時(shí)，為其建立關(guān)鍵字列表，通過關(guān)鍵字索引，也是一個(gè)不錯(cuò)的方法，至少愚安我是經(jīng)常這么做的。

（3）對(duì)于一些搜索引擎級(jí)別的應(yīng)用來說，F(xiàn)ULLTEXT同樣不是一個(gè)好的處理方法，Mysql的全文索引建立的文件還是比較大的，而且效率不是很高，即便是使用了中文分詞插件，對(duì)中文分詞支持也只是一般。真要碰到這種問題，Apache的Lucene或許是你的選擇。

（4）正是因?yàn)閔ash表在處理較小數(shù)據(jù)量時(shí)具有無可比擬的素的優(yōu)勢(shì)，所以hash索引很適合做緩存（內(nèi)存數(shù)據(jù)庫）。如mysql數(shù)據(jù)庫的內(nèi)存版本Memsql，使用量很廣泛的緩存工具M(jìn)encached，NoSql數(shù)據(jù)庫redis等，都使用了hash索引這種形式。當(dāng)然，不想學(xué)習(xí)這些東西的話Mysql的MEMORY引擎也是可以滿足這種需求的。

（5）至于RTREE，愚安我至今還沒有使用過，它具體怎么樣，我就不知道了。有RTREE使用經(jīng)歷的同學(xué)，到時(shí)可以交流下！

nosql數(shù)據(jù)庫庫和sql數(shù)據(jù)庫的區(qū)別

一、概念

SQL?(Structured?Query?Language)?數(shù)據(jù)庫，指關(guān)系型數(shù)據(jù)庫。主要代表：SQL?Server，Oracle，MySQL(開源)，PostgreSQL(開源)。

NoSQL（Not?Only?SQL）泛指非關(guān)系型數(shù)據(jù)庫。主要代表：MongoDB，Redis，CouchDB。

二、區(qū)別

1、存儲(chǔ)方式

SQL數(shù)據(jù)存在特定結(jié)構(gòu)的表中；而NoSQL則更加靈活和可擴(kuò)展，存儲(chǔ)方式可以省是JSON文檔、哈希表或者其他方式。SQL通常以數(shù)據(jù)庫表形式存儲(chǔ)數(shù)據(jù)。舉個(gè)栗子，存?zhèn)€學(xué)生借書數(shù)據(jù)：

而NoSQL存儲(chǔ)方式比較靈活，比如使用類JSON文件存儲(chǔ)上表中熊大的借閱數(shù)據(jù)：

2、表/數(shù)據(jù)集合的數(shù)據(jù)的關(guān)系

在SQL中，必須定義好表和字段結(jié)構(gòu)后才能添加數(shù)據(jù)，例如定義表的主鍵(primary?key)，索引(index),觸發(fā)器(trigger),存儲(chǔ)過程(stored?procedure)等。表結(jié)構(gòu)可以在被定義之后更新，但是如果有比較大的結(jié)構(gòu)變更的話就會(huì)變得比較復(fù)雜。在NoSQL中，數(shù)據(jù)可以在任何時(shí)候任何地方添加，不需要先定義表。例如下面這段代碼會(huì)自動(dòng)創(chuàng)建一個(gè)新的"借閱表"數(shù)據(jù)集合：

NoSQL也可以在數(shù)據(jù)集中建立索引。以MongoDB為例，會(huì)自動(dòng)在數(shù)據(jù)集合創(chuàng)建后創(chuàng)建唯一值_id字段，這樣的話就可以在數(shù)據(jù)集創(chuàng)建后增加索引。

從這點(diǎn)來看，NoSQL可能更加適合初始化數(shù)據(jù)還不明確或者未定的項(xiàng)目中。

3、外部數(shù)據(jù)存儲(chǔ)

SQL中如何需要增加外部關(guān)聯(lián)數(shù)據(jù)的話，規(guī)范化做法是在原表中增加一個(gè)外鍵，關(guān)聯(lián)外部數(shù)據(jù)表。例如需要在借閱表中增加審核人信息，先建立一個(gè)審核人表：

再在原來的借閱人表中增加審核人外鍵：

這樣如果我們需要更新審核人個(gè)人信息的時(shí)候只需要更新審核人表而不需要對(duì)借閱人表做更新。而在NoSQL中除了這種規(guī)范化的外部數(shù)據(jù)表做法以外，我們還能用如下的非規(guī)范化方式把外部數(shù)據(jù)直接放到原數(shù)據(jù)集中，以提高查詢效率。缺點(diǎn)也比較明顯，更新審核人數(shù)據(jù)的時(shí)候?qū)?huì)比較麻煩。

4、SQL中的JOIN查詢

SQL中可以使用JOIN表鏈接方式將多個(gè)關(guān)系數(shù)據(jù)表中的數(shù)據(jù)用一條簡(jiǎn)單的查詢語句查詢出來。NoSQL暫未提供類似JOIN的查詢方式對(duì)多個(gè)數(shù)據(jù)集中的數(shù)據(jù)做查詢。所以大部分NoSQL使用非規(guī)范化的數(shù)據(jù)存儲(chǔ)方式存儲(chǔ)數(shù)據(jù)。

5、數(shù)據(jù)耦合性

SQL中不允許刪除已經(jīng)被使用的外部數(shù)據(jù)，例如審核人表中的"熊三"已經(jīng)被分配給了借閱人熊大，那么在審核人表中將不允許刪除熊三這條數(shù)據(jù)，以保證數(shù)據(jù)完整性。而NoSQL中則沒有這種強(qiáng)耦合的概念，可以隨時(shí)刪除任何數(shù)據(jù)。

6、事務(wù)

SQL中如果多張表數(shù)據(jù)需要同批次被更新，即如果其中一張表更新失敗的話其他表也不能更新成功。這種場(chǎng)景可以通過事務(wù)來控制，可以在所有命令完成后再統(tǒng)一提交事務(wù)。而NoSQL中沒有事務(wù)這個(gè)概念，每一個(gè)數(shù)據(jù)集的操作都是原子級(jí)的。

7、增刪改查語法

8、查詢性能

在相同水平的系統(tǒng)設(shè)計(jì)的前提下，因?yàn)镹oSQL中省略了JOIN查詢的消耗，故理論上性能上是優(yōu)于SQL的。

簡(jiǎn)述什么是nosql數(shù)據(jù)庫，并列舉兩種常見的nosql數(shù)據(jù)庫名稱及其特點(diǎn)

NoSQL太火，冒出太多產(chǎn)品了，保守估計(jì)也成百上千了。

互聯(lián)網(wǎng)公司常用的基本集中在以下幾種，每種只舉一個(gè)比較常見或者應(yīng)用比較成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同時(shí)提供了更加豐富的數(shù)據(jù)結(jié)構(gòu)和運(yùn)算的能力，成功用法是替代memcached，通過checkpoint和commit log提供了快速的宕機(jī)恢復(fù)，同時(shí)支持replication提供讀可擴(kuò)展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盤的key-value storage, 模型單一簡(jiǎn)單，數(shù)據(jù)量不受限于內(nèi)存大小，數(shù)據(jù)落盤高可靠，Google的幾位大神出品的精品，LSM模型天然寫優(yōu)化，順序?qū)懕P的方式對(duì)于新硬件ssd再適合不過了，不足是僅提供了一個(gè)庫，需要自己封裝server端。

3. Document Store: Mongodb

分布式nosql，具備了區(qū)別mysql的最大亮點(diǎn)：可擴(kuò)展性。mongodb 最新引人的莫過于提供了sql接口，是目前nosql里最像mysql的，只是沒有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對(duì)于數(shù)據(jù)量遠(yuǎn)超內(nèi)存限制的場(chǎng)景來說，還需要慎重。

4. Column Table Store: HBase

這個(gè)富二代似乎不用贅述了，最大的優(yōu)勢(shì)是開源，對(duì)于普通的scan和基于行的get等基本查詢，性能完全不是問題，只是只提供裸的api,易用性上是短板，可擴(kuò)展性方面是最強(qiáng)的，其次坐上了Hadoop的快車，社區(qū)發(fā)展很快，各種基于其上的開源產(chǎn)品不少，來解決諸如join、聚集運(yùn)算等復(fù)雜查詢。

標(biāo)題名稱：nosql數(shù)據(jù)庫索引方式,請(qǐng)簡(jiǎn)述什么是NoSQL數(shù)據(jù)庫
URL網(wǎng)址：http://jinyejixie.com/article42/dsecpec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、網(wǎng)站設(shè)計(jì)、關(guān)鍵詞優(yōu)化、品牌網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、網(wǎng)站內(nèi)鏈

廣告

聲明：本網(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í)需注明來源： 創(chuàng)新互聯(lián)