數(shù)據(jù)庫(kù)在使用一段時(shí)間后，時(shí)常會(huì)出現(xiàn)因數(shù)據(jù)刪除而造成數(shù)據(jù)庫(kù)中空閑空間太多的情況，這時(shí)就需要減少分配給數(shù)據(jù)庫(kù)文件和事務(wù)日志文件的磁盤空間，以免浪費(fèi)磁盤空間。當(dāng)數(shù)據(jù)庫(kù)中沒有數(shù)據(jù)時(shí)，可以修改數(shù)據(jù)庫(kù)文件屬性直接改變其占用空間，但當(dāng)數(shù)據(jù)庫(kù)中有數(shù)據(jù)時(shí)，這樣做會(huì)破壞數(shù)據(jù)庫(kù)中的數(shù)據(jù)，因此需要使用壓縮的方式來(lái)縮減數(shù)據(jù)庫(kù)空間?？梢栽跀?shù)據(jù)庫(kù)屬性選項(xiàng)中選擇“Auto shrink”選項(xiàng)，讓系統(tǒng)自動(dòng)壓縮數(shù)據(jù)庫(kù)，也可以用人工的方法來(lái)壓縮。人工壓縮數(shù)據(jù)庫(kù)有以下兩種方式：
目前創(chuàng)新互聯(lián)已為近1000家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、綿陽(yáng)服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計(jì)、吳橋網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
1、用Enterprise Manager 壓縮數(shù)據(jù)庫(kù)
在Enterprise Manager 中在所要壓縮的數(shù)據(jù)庫(kù)上單擊右鍵，從快捷菜單中的“所有任務(wù)（All Tasks）”中選擇“Shrink Database（壓縮數(shù)據(jù)庫(kù)）”選項(xiàng)
、用Transact-SQL 命令壓縮數(shù)據(jù)庫(kù)
可以使用DBCC SHRINKDATABASE 和DBCC SHRINKFILE 命令來(lái)壓縮數(shù)據(jù)庫(kù)。其中DBCC SHRINKDATABASE 命令對(duì)數(shù)據(jù)庫(kù)進(jìn)行壓縮，DBCC SHRINKFILE 命令對(duì)數(shù)據(jù)庫(kù)中指定的文件進(jìn)行壓縮。
（1） DBCC SHRINKDATABASE
DBCC SHRINKDATABASE 命令語(yǔ)法如下：
DBCC SHRINKDATABASE (database_name [, target_percent]
[, {NOTRUNCATE | TRUNCATEONLY}] )
各參數(shù)說明如下：
target_percent 指定將數(shù)據(jù)庫(kù)壓縮后，未使用的空間占數(shù)據(jù)庫(kù)大小的百分之幾。如果指定的百分比過大，超過了壓縮前未使用空間所占的比例，則數(shù)據(jù)庫(kù)不會(huì)被壓縮。并且壓縮后的數(shù)據(jù)庫(kù)不能比數(shù)據(jù)庫(kù)初始設(shè)定的容量小。
NOTRUECATE
將數(shù)據(jù)庫(kù)縮減后剩余的空間保留在數(shù)據(jù)庫(kù)，中不返還給操作系統(tǒng)。如果不選擇此選項(xiàng)，則剩余的空間返還給操作系統(tǒng)。
TRUNCATEONLY
將數(shù)據(jù)庫(kù)縮減后剩余的空間返還給操作系統(tǒng)。使用此命令時(shí)SQL Server 將文件縮減到最后一個(gè)文件分配，區(qū)域但不移動(dòng)任何數(shù)據(jù)文件。選擇此項(xiàng)后，target_percent 選項(xiàng)就無(wú)效了。
壓縮數(shù)據(jù)庫(kù)mytest 的未使用空間為數(shù)據(jù)庫(kù)大小的20%。
dbcc shrinkdatabase (mytest, 20)
運(yùn)行結(jié)果如下：
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
(2) DBCC SHRINKFILE
DBCC SHRINKFILE 命令壓縮當(dāng)前數(shù)據(jù)庫(kù)中的文件。其語(yǔ)法如下：
DBCC SHRINKFILE ( {file_name | file_id }
{ [, target_size] |
[, {EMPTYFILE | NOTRUNCATE | TRUNCATEONLY}] } )
各參數(shù)說明如下：
file_id
指定要壓縮的文件的鑒別號(hào)（Identification number， 即ID）。文件的ID 號(hào)可以通過 FILE_ID（）函數(shù)或如本章前面所講述的Sp_helpdb 系統(tǒng)存儲(chǔ)過程來(lái)得到。
target_size
指定文件壓縮后的大小。以MB 為單位。如果不指定此選項(xiàng)，SQL Server 就會(huì)盡最大可能地縮減文件。
EMPTYFILE
指明此文件不再使用，將移動(dòng)所有在此文件中的數(shù)據(jù)到同一文件組中的其它文件中去。執(zhí)行帶此參數(shù)的命令后，此文件就可以用ALTER DATABASE 命令來(lái)刪除了。
其余參數(shù)NOTRUNCATE 和TRUNCATEONLY 與DBCC SHRINKDATABASE 命令中的含義相同。
例6-15: 壓縮數(shù)據(jù)庫(kù)mydb 中的數(shù)據(jù)庫(kù)文件mydb_data2 的大小到1MB。 use mydb dbcc shrinkfile (mydb_data2, 1)
1，Cassandra:
Cassandra從安裝配置，到使用，負(fù)載平衡機(jī)制等等，無(wú)疑是這些新興的NoSQL中最方便使用的一個(gè)（個(gè)人使用體驗(yàn)觀點(diǎn)）
但從近期的消息來(lái)看由于出現(xiàn)過幾次較為嚴(yán)重的數(shù)據(jù)庫(kù)停止服務(wù)事件，Cassandra的創(chuàng)始人Facebook,及Twitter開始漸漸棄用
Cassandra,只把Cassandra用在非核心模塊上，不地Digg仍在使用，看來(lái)我們要謹(jǐn)慎地對(duì)待它。2008年Facebook已讓
Cassandra開源到Apache.
2.MongoDB:
它的風(fēng)格可以說，在當(dāng)今WebAPI流行的時(shí)代，它更易于被人使用，BJSON操作風(fēng)格，自動(dòng)數(shù)據(jù)平衡機(jī)制（當(dāng)然要當(dāng)心存貯碎片問題），相對(duì)
MySQL等SQL數(shù)據(jù)庫(kù)有優(yōu)秀考慮全面的，分布式方案，自動(dòng)M/S主從讀寫切換。對(duì)于數(shù)據(jù)集群來(lái)說，可以說相當(dāng)完美的Sharding等自動(dòng)化支持。至
今聽說過的最嚴(yán)重的事件就是FourSquare的11小時(shí)數(shù)據(jù)庫(kù)宕機(jī)事件。相對(duì)來(lái)說還能接受：），它是使用C++/Boost編寫，效率性能的確不錯(cuò)。
3.Redis:
它就是一個(gè)高效的內(nèi)存數(shù)據(jù)庫(kù)，用它來(lái)持久化數(shù)據(jù)存貯，那是扯淡，如果真拿它來(lái)與別的NoSQL一樣使用（考慮讀寫一致性或者寫安全）那它馬上慢下
來(lái)：）不過他提供了比Memcached更多的操作數(shù)據(jù)類型，倒可以完全用它來(lái)做為一個(gè)高效易用的緩存，Benchmark據(jù)說優(yōu)于memcached.
我用的數(shù)據(jù)規(guī)模沒有這么大，不敢妄加評(píng)論。
4.HBase:
概念上也相對(duì)完美，有Hive開源工具支持，使HBase,可以相對(duì)于其它NoSQL數(shù)據(jù)庫(kù)更易于使用，基于HDFS分布文件系統(tǒng)，使HBASE天
生就有對(duì)海量分布集群很好的支持。又因?yàn)榕cHadoop相伴而生，所以一個(gè)系統(tǒng)想使用數(shù)據(jù)分析，智能處理，海量邏輯執(zhí)行，完全可以選擇Hadoop +
HBase云計(jì)算方案。
MongoDB也支持js的Map/Reducer所以可以試著整合一下MongoDB進(jìn)云計(jì)算方案中。
當(dāng)我使有MySQL +
NoSQL方案時(shí)，我會(huì)選擇MongoDB,不僅是因?yàn)樗某錾暮Ａ糠植际椒桨傅闹С?，也不是因?yàn)榻?jīng)的Map/Reducer分布式計(jì)算的支持。而是因
為還沒聽說過它有過重大的失敗案例，相對(duì)較完美的文檔（還有中文手冊(cè)喲）還有JSON分格支持，在當(dāng)下WebAPI流行的時(shí)代，不僅是從個(gè)人喜愛角度，也
是從工程管理角度，開發(fā)人員更Love it,呵呵。
在大數(shù)據(jù)時(shí)代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫(kù)行業(yè)應(yīng)對(duì)大數(shù)據(jù)的基本思路，數(shù)據(jù)庫(kù)行業(yè)出現(xiàn)互為補(bǔ)充的三大陣營(yíng)，適用于事務(wù)處理應(yīng)用的OldSQL、適用于數(shù)據(jù)分析應(yīng)用的NewSQL和適用于互聯(lián)網(wǎng)應(yīng)用的NoSQL。但在一些復(fù)雜的應(yīng)用場(chǎng)景中，單一數(shù)據(jù)庫(kù)架構(gòu)都不能完全滿足應(yīng)用場(chǎng)景對(duì)海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)管理、復(fù)雜分析、關(guān)聯(lián)查詢、實(shí)時(shí)性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫(kù)混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫(kù)混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個(gè)案例對(duì)不同架構(gòu)數(shù)據(jù)庫(kù)的混合應(yīng)用部署進(jìn)行介紹。
OldSQL+NewSQL 在數(shù)據(jù)中心類應(yīng)用中混合部署
采用OldSQL+NewSQL模式構(gòu)建數(shù)據(jù)中心，在充分發(fā)揮OldSQL數(shù)據(jù)庫(kù)的事務(wù)處理能力的同時(shí)，借助NewSQL在實(shí)時(shí)性、復(fù)雜分析、即席查詢等方面的獨(dú)特優(yōu)勢(shì)，以及面對(duì)海量數(shù)據(jù)時(shí)較強(qiáng)的擴(kuò)展能力，滿足數(shù)據(jù)中心對(duì)當(dāng)前“熱”數(shù)據(jù)事務(wù)型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NewSQL不適合事務(wù)處理的不足，NewSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲(chǔ)能力和處理性能方面的缺陷。
商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫(kù)滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫(kù)集群對(duì)即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實(shí)現(xiàn)應(yīng)對(duì)海量數(shù)據(jù)存儲(chǔ)的擴(kuò)展能力。
商業(yè)銀行數(shù)據(jù)中心存儲(chǔ)架構(gòu)
與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計(jì)分析性能提升6倍以上。NewSQL MPP的高可擴(kuò)展性能夠應(yīng)對(duì)新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長(zhǎng)采用集群方式構(gòu)建存儲(chǔ)容量更大的數(shù)據(jù)中心。
OldSQL+NoSQL 在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中混合部署
在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用對(duì)海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行存儲(chǔ)和快速處理的需求。在諸如大型電子商務(wù)平臺(tái)、大型SNS平臺(tái)等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場(chǎng)景中，OldSQL在應(yīng)用中負(fù)責(zé)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和事務(wù)型處理，NoSQL在應(yīng)用中負(fù)責(zé)存儲(chǔ)和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NoSQL在ACID特性和復(fù)雜關(guān)聯(lián)運(yùn)算方面的不足，NoSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲(chǔ)和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。
數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲(chǔ)層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫(kù)集群MyFOX和基于HBase的NoSQL存儲(chǔ)集群Prom組成。由于OldSQL強(qiáng)大的語(yǔ)義和關(guān)系表達(dá)能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲(chǔ)在MyFOX中的統(tǒng)計(jì)結(jié)果數(shù)據(jù)已經(jīng)達(dá)到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面，NoSQL作為SQL的有益補(bǔ)充，解決了OldSQL數(shù)據(jù)庫(kù)無(wú)法解決的全屬性選擇器等問題。
淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)
基于OldSQL+NoSQL混合架構(gòu)的特點(diǎn)，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲(chǔ)空間，支持每天4000萬(wàn)的查詢請(qǐng)求，平均響應(yīng)時(shí)間在28毫秒，足以滿足未來(lái)一段時(shí)間內(nèi)的業(yè)務(wù)增長(zhǎng)需求。
NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應(yīng)用中混合部署
行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價(jià)值密度更高，并且對(duì)結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應(yīng)用場(chǎng)景主要是分析類應(yīng)用，如：電信、金融、政務(wù)、能源等行業(yè)的決策輔助、預(yù)測(cè)預(yù)警、統(tǒng)計(jì)分析、經(jīng)營(yíng)分析等。
在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢(shì)，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢(shì)，實(shí)現(xiàn)NewSQL與NoSQL的功能互補(bǔ)，解決行業(yè)大數(shù)據(jù)應(yīng)用對(duì)高價(jià)值結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等要求，以及對(duì)海量非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和分析處理工作，NoSQL承擔(dān)存儲(chǔ)和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的工作。
當(dāng)前電信運(yùn)營(yíng)商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對(duì)大量的固定應(yīng)用，以及占統(tǒng)計(jì)總數(shù)80%以上的突發(fā)性臨時(shí)統(tǒng)計(jì)(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢(shì)，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲(chǔ)方面的優(yōu)勢(shì)，實(shí)現(xiàn)高效低成本。
集中化BI系統(tǒng)數(shù)據(jù)存儲(chǔ)架構(gòu)
集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲(chǔ)在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺(tái)上存儲(chǔ)與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫(kù)或Hadoop平臺(tái);結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫(kù)中，短期高價(jià)值數(shù)據(jù)放在高性能平臺(tái)，中長(zhǎng)期放在低成本產(chǎn)品中。
結(jié)語(yǔ)
當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫(kù)架構(gòu)各自所具有的優(yōu)勢(shì)和局限性，造成任何一種架構(gòu)的數(shù)據(jù)庫(kù)都不能完全滿足應(yīng)用需求，因此不同架構(gòu)數(shù)據(jù)庫(kù)混合使用，從而彌補(bǔ)其他架構(gòu)的不足成為必然選擇。根據(jù)應(yīng)用場(chǎng)景采用不同架構(gòu)數(shù)據(jù)庫(kù)進(jìn)行組合搭配，充分發(fā)揮每種架構(gòu)數(shù)據(jù)庫(kù)的特點(diǎn)和優(yōu)勢(shì)，并且與其他架構(gòu)數(shù)據(jù)庫(kù)形成互補(bǔ)，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來(lái)一段時(shí)期內(nèi)信息化應(yīng)用主要采用的解決方式。
目前在國(guó)內(nèi)市場(chǎng)上，OldSQL主要為Oracle、IBM等國(guó)外數(shù)據(jù)庫(kù)廠商所壟斷，達(dá)夢(mèng)、金倉(cāng)等國(guó)產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國(guó)產(chǎn)新型數(shù)據(jù)庫(kù)GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場(chǎng)三強(qiáng);NoSQL方面用戶則大多采用Hadoop開源方案。
區(qū)別是：
1 MySQL支持enum,和set類型，sql server不支持
2 MySQL不支持nchar,nvarchar,ntext類型
3 MySQL的遞增語(yǔ)句是AUTO_INCREMENT，而mssql是identity(1,1)
4 msms默認(rèn)到處表創(chuàng)建語(yǔ)句的默認(rèn)值表示是((0)),而在MySQL里面是不允許帶兩括號(hào)的
5 MySQL需要為表指定存儲(chǔ)類型
6 mssql識(shí)別符是[],[type]表示他區(qū)別于關(guān)鍵字，但是MySQL數(shù)據(jù)庫(kù)卻是 `，也就是按鍵1左邊的那個(gè)符號(hào)
7 mssql支持getdate()方法獲取當(dāng)前時(shí)間日期，但是MySQL里面可以分日期類型和時(shí)間類型，獲取當(dāng)前日期是cur_date()，當(dāng)前完整時(shí)間是 now()函數(shù)
8 mssql不支持replace into 語(yǔ)句，但是在最新的sql20008里面，也支持merge語(yǔ)法
9 MySQL支持insert into table1 set t1 = ‘’, t2 = ‘’ ,但是mssql不支持這樣寫
10 MySQL支持insert into tabl1 values (1,1), (1,1), (1,1), (1,1), (1,1), (1,1), (1,1)
11 mssql不支持limit語(yǔ)句，是非常遺憾的，只能用top 取代limt 0,N，row_number() over()函數(shù)取代limit N,M
12 MySQL數(shù)據(jù)庫(kù)在創(chuàng)建表時(shí)要為每個(gè)表指定一個(gè)存儲(chǔ)引擎類型，而mssql只支持一種存儲(chǔ)引擎
13 MySQL不支持默認(rèn)值為當(dāng)前時(shí)間的datetime類型（mssql很容易做到），在MySQL里面是用timestamp類型
14 mssql里面檢查是否有這個(gè)表再刪除，需要這樣：
if exists (select * from dbo.sysobjects where id = object_id(N'uc_newpm') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
但是在MySQL里面只需要 DROP TABLE IF EXISTS cdb_forums;
15 MySQL支持無(wú)符號(hào)型的整數(shù)，那么比不支持無(wú)符號(hào)型的mssql就能多出一倍的最大數(shù)存儲(chǔ)
16 MySQL不支持在mssql里面使用非常方便的varchar(max)類型，這個(gè)類型在mssql里面既可做一般數(shù)據(jù)存儲(chǔ)，也可以做blob數(shù)據(jù)存儲(chǔ)
17 MySQL數(shù)據(jù)庫(kù)創(chuàng)建非聚集索引只需要在創(chuàng)建表的時(shí)候指定為key就行，比如：KEY displayorder (fid,displayorder) 在mssql里面必須要：create unique nonclustered index index_uc_protectedmembers_username_appid on dbo.uc_protectedmembers
(username asc,appid asc)
18 MySQL text字段類型不允許有默認(rèn)值
19MySQL的一個(gè)表的總共字段長(zhǎng)度不超過65XXX。
20一個(gè)很表面的區(qū)別就是MySQL的安裝特別簡(jiǎn)單，而且文件大小才110M（非安裝版），相比微軟這個(gè)龐然大物，安裝進(jìn)度來(lái)說簡(jiǎn)直就是.....
21MySQL的管理工具有幾個(gè)比較好的，MySQL_front,和官方那個(gè)套件，不過都沒有SSMS的使用方便，這是MySQL很大的一個(gè)缺點(diǎn)。
22MySQL的存儲(chǔ)過程只是出現(xiàn)在最新的版本中，穩(wěn)定性和性能可能不如mssql。
23 同樣的負(fù)載壓力，MySQL要消耗更少的CPU和內(nèi)存，mssql的確是很耗資源。
24php連接MySQL數(shù)據(jù)庫(kù)和mssql的方式都差不多，只需要將函數(shù)的MySQL替換成mssql即可。
25MySQL支持date,time,year類型，mssql到2008才支持date和time。
1、性能
都比較高，性能對(duì)我們來(lái)說應(yīng)該都不是瓶頸。
總體來(lái)講，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。
2、操作的便利性
memcache 數(shù)據(jù)結(jié)構(gòu)單一。（key-value）
redis 豐富一些，數(shù)據(jù)操作方面，redis 更好一些，較少的網(wǎng)絡(luò) IO 次數(shù)，同時(shí)還提供 list，set，
hash 等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
mongodb 支持豐富的數(shù)據(jù)表達(dá)，索引，最類似關(guān)系型數(shù)據(jù)庫(kù)，支持的查詢語(yǔ)言非常豐富。
3、內(nèi)存空間的大小和數(shù)據(jù)量的大小
redis 在 2.0 版本后增加了自己的 VM 特性，突破物理內(nèi)存的限制；可以對(duì) key value 設(shè)置過
期時(shí)間（類似 memcache）
memcache 可以修改最大可用內(nèi)存,采用 LRU 算法。Memcached 代理軟件 magent，比如建立
10 臺(tái) 4G 的 Memcache 集群，就相當(dāng)于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 適合大數(shù)據(jù)量的存儲(chǔ)，依賴操作系統(tǒng) VM 做內(nèi)存管理，吃內(nèi)存也比較厲害，服務(wù)
不要和別的服務(wù)在一起。
4、可用性（單點(diǎn)問題）
對(duì)于單點(diǎn)問題，
redis，依賴客戶端來(lái)實(shí)現(xiàn)分布式讀寫；主從復(fù)制時(shí)，每次從節(jié)點(diǎn)重新連接主節(jié)點(diǎn)都要依賴整
個(gè)快照,無(wú)增量復(fù)制，因性能和效率問題，
所以單點(diǎn)問題比較復(fù)雜；不支持自動(dòng) sharding,需要依賴程序設(shè)定一致 hash 機(jī)制。
一種替代方案是，不用 redis 本身的復(fù)制機(jī)制，采用自己做主動(dòng)復(fù)制（多份存儲(chǔ)），或者改成
增量復(fù)制的方式（需要自己實(shí)現(xiàn)），一致性問題和性能的權(quán)衡
Memcache 本身沒有數(shù)據(jù)冗余機(jī)制，也沒必要；對(duì)于故障預(yù)防，采用依賴成熟的 hash 或者環(huán)
狀的算法，解決單點(diǎn)故障引起的抖動(dòng)問題。
mongoDB 支持 master-slave,replicaset（內(nèi)部采用 paxos 選舉算法，自動(dòng)故障恢復(fù)）,auto sharding 機(jī)制，對(duì)客戶端屏蔽了故障轉(zhuǎn)移和切分機(jī)制。
5、可靠性（持久化）
對(duì)于數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù)，
redis 支持（快照、AOF）：依賴快照進(jìn)行持久化，aof 增強(qiáng)了可靠性的同時(shí)，對(duì)性能有所影
響
memcache 不支持，通常用在做緩存,提升性能；
MongoDB 從 1.8 版本開始采用 binlog 方式支持持久化的可靠性
6、數(shù)據(jù)一致性（事務(wù)支持）
Memcache 在并發(fā)場(chǎng)景下，用 cas 保證一致性redis 事務(wù)支持比較弱，只能保證事務(wù)中的每個(gè)操作連續(xù)執(zhí)行
mongoDB 不支持事務(wù)
7、數(shù)據(jù)分析
mongoDB 內(nèi)置了數(shù)據(jù)分析的功能(mapreduce),其他不支持
8、應(yīng)用場(chǎng)景
redis：數(shù)據(jù)量較小的更性能操作和運(yùn)算上
memcache：用于在動(dòng)態(tài)系統(tǒng)中減少數(shù)據(jù)庫(kù)負(fù)載，提升性能;做緩存，提高性能（適合讀多寫
少，對(duì)于數(shù)據(jù)量比較大，可以采用 sharding）
MongoDB:主要解決海量數(shù)據(jù)的訪問效率問題。
表格比較：
memcache redis 類型 內(nèi)存數(shù)據(jù)庫(kù) 內(nèi)存數(shù)據(jù)庫(kù)
數(shù)據(jù)類型 在定義 value 時(shí)就要固定數(shù)據(jù)類型 不需要
有字符串，鏈表，集 合和有序集合
虛擬內(nèi)存 不支持 支持
過期策略 支持 支持
分布式 magent master-slave，一主一從或一主多從
存儲(chǔ)數(shù)據(jù)安全 不支持 使用 save 存儲(chǔ)到 dump.rdb 中
災(zāi)難恢復(fù) 不支持 append only file(aof)用于數(shù)據(jù)恢復(fù)
性能
1、類型——memcache 和 redis 都是將數(shù)據(jù)存放在內(nèi)存，所以是內(nèi)存數(shù)據(jù)庫(kù)。當(dāng)然，memcache 也可用于緩存其他東西，例如圖片等等。
2、 數(shù)據(jù)類型——Memcache 在添加數(shù)據(jù)時(shí)就要指定數(shù)據(jù)的字節(jié)長(zhǎng)度,而 redis 不需要。
3、 虛擬內(nèi)存——當(dāng)物理內(nèi)存用完時(shí)，可以將一些很久沒用到的 value 交換到磁盤。
4、 過期策略——memcache 在 set 時(shí)就指定，例如 set key1 0 0 8,即永不過期。Redis 可以通
過例如 expire 設(shè)定，例如 expire name 10。
5、 分布式——設(shè)定 memcache 集群，利用 magent 做一主多從;redis 可以做一主多從。都可
以一主一從。
6、 存儲(chǔ)數(shù)據(jù)安全——memcache 斷電就斷了，數(shù)據(jù)沒了；redis 可以定期 save 到磁盤。
7、 災(zāi)難恢復(fù)——memcache 同上，redis 丟了后可以通過 aof 恢復(fù)。
Memecache 端口 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 啟動(dòng)一個(gè)守護(hù)進(jìn)程
-p 端口
-m 分配的內(nèi)存是 M
-c 最大運(yùn)行并發(fā)數(shù)-P memcache 的 pid
//0 壓縮（是否 MEMCACHE_COMPRESSED） 30 秒失效時(shí)間
//delete 5 是 timeout
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關(guān)系型的數(shù)據(jù)庫(kù)。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來(lái)的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。
（例如谷歌或Facebook每天為他們的用戶收集萬(wàn)億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模式，無(wú)需多余操作就可以橫向擴(kuò)展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫(kù)與NoSQL的區(qū)別？
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語(yǔ)言（SQL）
數(shù)據(jù)和關(guān)系都存儲(chǔ)在單獨(dú)的表中。
數(shù)據(jù)操縱語(yǔ)言，數(shù)據(jù)定義語(yǔ)言
嚴(yán)格的一致性
基礎(chǔ)事務(wù)
ACID
關(guān)系型數(shù)據(jù)庫(kù)遵循ACID規(guī)則
事務(wù)在英文中是transaction，和現(xiàn)實(shí)世界中的交易很類似，它有如下四個(gè)特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務(wù)里的所有操作要么全部做完，要么都不做，事務(wù)成功的條件是事務(wù)里的所有操作都成功，只要有一個(gè)操作失敗，整個(gè)事務(wù)就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個(gè)步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會(huì)莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說數(shù)據(jù)庫(kù)要一直處于一致的狀態(tài)，事務(wù)的運(yùn)行不會(huì)改變數(shù)據(jù)庫(kù)原本的一致性約束。
I (Isolation) 獨(dú)立性
所謂的獨(dú)立性是指并發(fā)的事務(wù)之間不會(huì)互相影響，如果一個(gè)事務(wù)要訪問的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改，只要另外一個(gè)事務(wù)未提交，它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個(gè)交易還未完成的情況下，如果此時(shí)B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務(wù)提交后，它所做的修改將會(huì)永久的保存在數(shù)據(jù)庫(kù)上，即使出現(xiàn)宕機(jī)也不會(huì)丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語(yǔ)言
沒有預(yù)定義的模式
鍵 - 值對(duì)存儲(chǔ)，列存儲(chǔ)，文檔存儲(chǔ)，圖形數(shù)據(jù)庫(kù)
最終一致性，而非ACID屬性
非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
CAP定理
高性能，高可用性和可伸縮性
分布式數(shù)據(jù)庫(kù)中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動(dòng)都是同步的
Availability(可用性), 好的響應(yīng)性能
Partition tolerance(分區(qū)容錯(cuò)性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。
定理：任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒法三者兼顧。
CAP理論的核心是：一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性，可用性和分區(qū)容錯(cuò)性這三個(gè)需求，
因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫(kù)分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點(diǎn)集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)大。
CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐?duì)一致性要求低一些。
CAP理論就是說在分布式存儲(chǔ)系統(tǒng)中，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。
而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。
所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒有NoSQL系統(tǒng)能同時(shí)保證這三點(diǎn)。
說明：C：強(qiáng)一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統(tǒng)Oracle數(shù)據(jù)庫(kù)
AP：大多數(shù)網(wǎng)站架構(gòu)的選擇
CP：Redis、Mongodb
注意：分布式架構(gòu)的時(shí)候必須做出取舍。
一致性和可用性之間取一個(gè)平衡。多余大多數(shù)web應(yīng)用，其實(shí)并不需要強(qiáng)一致性。
因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。
4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用
當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。
代表項(xiàng)目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機(jī)，很貴的，好像好幾萬(wàn)一臺(tái)；O 是指 Oracle 數(shù)據(jù)庫(kù)，也很貴的，好幾萬(wàn)呢；M 是指 EMC 的存儲(chǔ)設(shè)備，也很貴的。
難點(diǎn)：
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務(wù)平臺(tái)不需要大面積重構(gòu)。
重慶分公司
重慶分公司
