1.Mysql
1.1mysql存儲引擎
引擎查看：show engines
為什么有不同的引擎：
mysql中通過各種不同的技術(shù)引擎將數(shù)據(jù)存儲在文件或內(nèi)存中。這些技術(shù)使用不同的存儲恭金、索引操禀、鎖定方法 從而提供不同的功能和能力。通過選擇不同的引擎 你能獲得額外的速度或功能横腿，從而改善你應(yīng)用的整體功能颓屑。
如何更改引擎：
不同的表可以使用不同的引擎
默認(rèn)引擎是innoDB。
1. 修改配置文件my.ini
2. 創(chuàng)建表的時候type指定
3. alter table type=InnoDB
查看修改：show table status from db; show create table table_name
引擎對比
常用到三個引擎：InnoDB耿焊、MyisAM揪惦、Memory
1.InnoDB（Mysql默認(rèn)的引擎）
InnoDB是一個事務(wù)型的數(shù)據(jù)引擎、支持行級鎖定和外鍵約束罗侯。
Innodb引擎提供了對數(shù)據(jù)庫ACID事務(wù)的支持器腋。該引擎還提供了行級鎖和外鍵約束，它的設(shè)計目標(biāo)是處理大容量數(shù)據(jù)庫系統(tǒng)钩杰，它本身其實就是基于MySQL后臺的完整數(shù)據(jù)庫系統(tǒng)纫塌，MySQL運行時Innodb會在內(nèi)存中建立緩沖池，用于緩沖數(shù)據(jù)和索引讲弄。但是該引擎不支持FULLTEXT類型的索引（5.7已經(jīng)支持）措左，而且它沒有保存表的行數(shù)，當(dāng)SELECT COUNT(*) FROM TABLE時需要掃描全表垂睬。當(dāng)需要使用數(shù)據(jù)庫事務(wù)時媳荒，該引擎當(dāng)然是首選抗悍。由于鎖的粒度更小，寫操作不會鎖定全表钳枕，所以在并發(fā)較高時缴渊，使用Innodb引擎會提升效率。但是使用行級鎖也不是絕對的鱼炒，如果在執(zhí)行一個SQL語句時MySQL不能確定要掃描的范圍衔沼，InnoDB表同樣會鎖全表。
適用場景：
1）經(jīng)常更新的表昔瞧，適合處理多重并發(fā)的更新請求指蚁。
2）支持事務(wù)。
3）可以從災(zāi)難中恢復(fù)（通過bin-log日志等）自晰。
4）外鍵約束凝化。只有他支持外鍵。
5）支持自動增加列屬性auto_increment酬荞。
2. MyisAM
它不提供數(shù)據(jù)庫對事務(wù)對支持搓劫、不支持行級鎖和外鍵約束，因此在insert和update的時候會全表鎖導(dǎo)致效率低一些混巧。
MyisAM獨立與操作系統(tǒng)枪向，引擎在創(chuàng)建表的時候會創(chuàng)建三個文件，一個是.frm文件用于存儲表的定義咧党，一個是.MYD文件用于存儲表的數(shù)據(jù)秘蛔，另一個是.MYI文件，存儲的是索引傍衡。操作系統(tǒng)對大文件的操作是比較慢的深员，這樣將表分為三個文件，那么.MYD這個文件單獨來存放數(shù)據(jù)自然可以優(yōu)化數(shù)據(jù)庫的查詢等操作聪舒。有索引管理和字段管理辨液。MyISAM還使用一種表格鎖定的機(jī)制虐急，來優(yōu)化多個并發(fā)的讀寫操作箱残，其代價是你需要經(jīng)常運行OPTIMIZE TABLE命令，來恢復(fù)被更新機(jī)制所浪費的空間
適用場景：
1）不支持事務(wù)的設(shè)計止吁，但是并不代表著有事務(wù)操作的項目不能用MyIsam存儲引擎被辑，可以在service層進(jìn)行根據(jù)自己的業(yè)務(wù)需求進(jìn)行相應(yīng)的控制。
2）不支持外鍵的表設(shè)計敬惦。
3）查詢速度很快盼理，如果數(shù)據(jù)庫insert和update的操作比較少的話比較適用。
4）整天 對表進(jìn)行加鎖的場景俄删。
5）MyISAM極度強(qiáng)調(diào)快速讀取操作宏怔。
6）MyIASM中存儲了表的行數(shù)奏路，于是SELECT COUNT(*) FROM TABLE時只需要直接讀取已經(jīng)保存好的值而不需要進(jìn)行全表掃描。如果表的讀操作遠(yuǎn)遠(yuǎn)多于寫操作且不需要數(shù)據(jù)庫事務(wù)的支持臊诊，那么MyIASM也是很好的選擇鸽粉。
缺點：
就是不能在表損壞后恢復(fù)數(shù)據(jù)。（是不能主動恢復(fù)）
3. Memory（也叫HEAP）堆內(nèi)存
定義：
使用存在內(nèi)存中的內(nèi)容來創(chuàng)建表抓艳。每個MEMORY表只實際對應(yīng)一個磁盤文件触机。MEMORY類型的表訪問非常得快，因為它的數(shù)據(jù)是放在內(nèi)存中的玷或，并且默認(rèn)使用HASH索引儡首。
但是一旦服務(wù)關(guān)閉，表中的數(shù)據(jù)就會丟失掉偏友。 HEAP允許只駐留在內(nèi)存里的臨時表格蔬胯。駐留在內(nèi)存里讓HEAP要比ISAM和MYISAM都快，但是它所管理的數(shù)據(jù)是不穩(wěn)定的位他，而且如果在關(guān)機(jī)之前沒有進(jìn)行保存笔宿，那么所有的數(shù)據(jù)都會丟失。在數(shù)據(jù)行被刪除的時候棱诱，HEAP也不會浪費大量的空間泼橘。HEAP表格在你需要使用SELECT表達(dá)式來選擇和操控數(shù)據(jù)的時候非常有用。
適用場景：
1）那些內(nèi)容變化不頻繁的代碼表迈勋，或者作為統(tǒng)計操作的中間結(jié)果表炬灭，便于高效地堆中間結(jié)果進(jìn)行分析并得到最終的統(tǒng)計結(jié)果。
2）目標(biāo)數(shù)據(jù)比較小靡菇，而且非常頻繁的進(jìn)行訪問重归，在內(nèi)存中存放數(shù)據(jù)，如果太大的數(shù)據(jù)會造成內(nèi)存溢出厦凤”撬保可以通過參數(shù)max_heap_table_size控制Memory表的大小，限制Memory表的最大的大小较鼓。
3）數(shù)據(jù)是臨時的椎木，而且必須立即可用得到，那么就可以放在內(nèi)存中博烂。
4）存儲在Memory表中的數(shù)據(jù)如果突然間丟失的話也沒有太大的關(guān)系香椎。
注意： Memory同時支持散列索引和B樹索引，B樹索引可以使用部分查詢和通配查詢禽篱，也可以使用<,>和>=等操作符方便數(shù)據(jù)挖掘畜伐，散列索引相等的比較快但是對于范圍的比較慢很多。
特性要求：
1）要求存儲的數(shù)據(jù)是數(shù)據(jù)長度不變的格式躺率，比如玛界，Blob和Text類型的數(shù)據(jù)不可用（長度不固定的）万矾。
2）要記住，在用完表格之后就刪除表格慎框。
https://blog.csdn.net/Jack__Frost/article/details/72904318
索引
索引：索引是一種幫助mysql高效的獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)勤众，這些數(shù)據(jù)結(jié)構(gòu)以某種方式引用數(shù)據(jù)，這種結(jié)構(gòu)就是索引鲤脏。
MySQL普遍使用B+tree實現(xiàn)其索引結(jié)構(gòu)们颜，B+tree是B-tree的一個變種，B是balance猎醇，使用B-tree結(jié)構(gòu)可以顯著減少定位記錄時所經(jīng)歷的中間過程窥突，從而加快存取速度
InnoDB索引：葉子節(jié)點存儲的是數(shù)據(jù)data
MyISAM索引：葉子節(jié)點存儲是數(shù)據(jù)的地址
Hash索引：
通過hash函數(shù)將索引列值映射到對應(yīng)碼值，索引存儲的是數(shù)據(jù)地址
如果多個列的哈希值相同（hash沖突）硫嘶，索引會以鏈表的方式存放多個記錄指針到同一個哈希條目中去阻问。
全文索引（fulltext）：
通過關(guān)鍵字的匹配來進(jìn)行查詢過濾，那么就需要基于相似度的查詢沦疾，而不是原來的精確數(shù)值比較称近。全文索引就是為這種場景設(shè)計，全文索引在大量的數(shù)據(jù)面前哮塞，能比 like + % 快 N 倍
MySQL 5.6 以前的版本刨秆，只有 MyISAM 存儲引擎支持全文索引；
MySQL 5.6 及以后的版本忆畅，MyISAM 和 InnoDB 存儲引擎均支持全文索引;
只有字段的數(shù)據(jù)類型為 char衡未、varchar、text 及其系列才可以建全文索引家凯。
全文索引場景
和常用的模糊匹配使用 like + % 不同缓醋，全文索引有自己的語法格式，使用 match 和 against 關(guān)鍵字绊诲，比如
select * from fulltext_test
where match(content,tag) against('xxx xxx');
1）使用全文索引前送粱，搞清楚版本支持情況；
2）全文索引比 like + % 快 N 倍掂之，但是可能存在精度問題（抗俄？）；
3）如果需要全文索引的是大量數(shù)據(jù)板惑，建議先添加數(shù)據(jù)橄镜，再創(chuàng)建索引；
4）對于中文冯乘，可以使用 MySQL 5.7.6 之后的版本，或者第三方插件晒夹。
2.Mongodb和mysql對比
| 比較類別 | MongoDB | Mysql |
|---|---|---|
| 數(shù)據(jù)庫模型 | 非關(guān)系型 | 關(guān)系型 |
| 存儲方式 | 虛擬內(nèi)存+磁盤持久化 | 磁盤 |
| 架構(gòu)特點 | 副本集分片實現(xiàn)高可用 | 單點裆馒、主從姊氓、集群等 |
| 數(shù)據(jù)處理 | 基于內(nèi)存、將熱點數(shù)據(jù)存在物理內(nèi)存中實現(xiàn)高速讀寫 | 不同引擎有不同特點 |
| 成熟度 | 新興數(shù)據(jù)庫成熟度較低 | 成熟體系 |
| 廣泛度 | 完善開源使用越來越廣 | 開源數(shù)據(jù)庫使用越來越廣 |
| 事務(wù)性 | 僅支持單文檔事務(wù)操作喷好，弱一致性 | 支持事務(wù)操作 |
一翔横、關(guān)系型數(shù)據(jù)庫-MySQL
1、在不同的引擎上有不同的存儲方式梗搅。
2禾唁、查詢語句是使用傳統(tǒng)的sql語句，擁有較為成熟的體系无切，成熟度很高荡短。
3、開源數(shù)據(jù)庫的份額在不斷增加哆键，mysql的份額頁在持續(xù)增長掘托。
4、缺點就是在海量數(shù)據(jù)處理的時候效率會顯著變慢籍嘹。
二闪盔、非關(guān)系型數(shù)據(jù)庫-MongoDB
非關(guān)系型數(shù)據(jù)庫(nosql ),屬于文檔型數(shù)據(jù)庫。先解釋一下文檔的數(shù)據(jù)庫辱士，即可以存放xml泪掀、json、bson類型系那個的數(shù)據(jù)颂碘。這些數(shù)據(jù)具備自述性族淮，呈現(xiàn)分層的樹狀數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)由鍵值(key=>value)對組成凭涂。
1祝辣、存儲方式：虛擬內(nèi)存+持久化。
2切油、查詢語句：是獨特的MongoDB的查詢方式蝙斜。
3、適合場景：事件的記錄澎胡，內(nèi)容管理或者博客平臺等等孕荠。
4、架構(gòu)特點：可以通過副本集攻谁，以及分片來實現(xiàn)高可用稚伍。
5、數(shù)據(jù)處理：數(shù)據(jù)是存儲在硬盤上的戚宦，只不過需要經(jīng)常讀取的數(shù)據(jù)會被加載到內(nèi)存中个曙，將數(shù)據(jù)存儲在物理內(nèi)存中，從而達(dá)到高速讀寫受楼。
6垦搬、成熟度與廣泛度：新興數(shù)據(jù)庫呼寸，成熟度較低，Nosql數(shù)據(jù)庫中最為接近關(guān)系型數(shù)據(jù)庫猴贰，比較完善的DB之一对雪，適用人群不斷在增長。
Mongodb優(yōu)勢：
- 快速 ：熱點數(shù)據(jù)存儲在物理內(nèi)存中米绕，使讀寫非成罚快速從而提高了整體性能
- 高擴(kuò)展性：MongoDB高可用與集群框架擁有十分高的擴(kuò)展性，通過物理機(jī)的增加以及sharding增加栅干，MongoDB的擴(kuò)展達(dá)到十分驚人的底部
- 自身的failover機(jī)制：mongoDB的副本集配置中迈套，當(dāng)主庫遇到問題，無法繼續(xù)提供服務(wù)時非驮，副本集將選舉一個新的主庫來繼續(xù)提供服務(wù)
- json的存儲格式交汤，json與bson存儲格式十分適合文檔格式的存儲與查詢
劣勢：
1、 不支持事務(wù)操作（4.0開始已經(jīng)支持）劫笙。MongoDB本身沒有自帶事務(wù)機(jī)制芙扎，若需要在MongoDB中實現(xiàn)事務(wù)機(jī)制，需通過一個額外的表填大，從邏輯上自行實現(xiàn)事務(wù)戒洼。
2、 應(yīng)用經(jīng)驗少允华，由于NoSQL興起時間短圈浇，應(yīng)用經(jīng)驗相比關(guān)系型數(shù)據(jù)庫較少。
3靴寂、MongoDB占用空間過大磷蜀。
mongo基礎(chǔ)：
https://www.cnblogs.com/clsn/p/8214194.html#auto-id-14
MongoDB水平擴(kuò)展：
https://www.infoq.cn/article/scale-out-mongodb
