mysql在常規(guī)配置下，一般只能承受2000萬(wàn)的數(shù)據(jù)量(同時(shí)讀寫，且表中有大文本字段，單臺(tái)服務(wù)器)。現(xiàn)在超過(guò)1億，并不斷增加的情況下，建議如下處理：

1 分表?？梢园磿r(shí)間，或按一定的規(guī)則拆分，做到查詢某一條數(shù)據(jù)庫(kù)，盡量在一個(gè)子表中即可。這是最有效的方法

2 讀寫分離。尤其是寫入，放在新表中，定期進(jìn)行同步。如果其中記錄不斷有update，最好將寫的數(shù)據(jù)放在 redis中，定期同步

3 表的大文本字段分離出來(lái)，成為獨(dú)立的新表。大文本字段，可以使用NOSQL數(shù)據(jù)庫(kù)

4 優(yōu)化架構(gòu)，或優(yōu)化SQL查詢，避免聯(lián)表查詢，盡量不要用count(*), in，遞歸等消耗性能的語(yǔ)句

5 用內(nèi)存緩存，或在前端讀的時(shí)候，增加緩存數(shù)據(jù)庫(kù)。重復(fù)讀取時(shí)，直接從緩存中讀取。

上面是低成本的管理方法，基本幾臺(tái)服務(wù)器即可搞定，但是管理起來(lái)麻煩一些。

當(dāng)然，如果整體數(shù)據(jù)量特別大的話，也不在乎投入費(fèi)用的話，用集群吧，用TIDB吧

通常來(lái)說(shuō)，Mysql表的數(shù)據(jù)量達(dá)到一兩千萬(wàn)之后，操作起來(lái)開始有些吃力了，如果數(shù)據(jù)量達(dá)到上億，估計(jì)系統(tǒng)是吃不消的。

那么解決方案有哪些呢？我提幾個(gè)思路：

就用Mysql，不考慮遷移

• 分庫(kù)分表其實(shí)是比較好的方案，但是已經(jīng)被題主否了，就不詳細(xì)說(shuō)了；
  

• 表設(shè)計(jì)的優(yōu)化：在設(shè)計(jì)表的時(shí)候，就要考慮性能問(wèn)題了。例如字段盡量避免NULL，時(shí)間類型盡量使用TIMESTAMP，單表的字段不宜過(guò)多等等。

• 索引的優(yōu)化：索引不是越多越好，也不是所有的字段都適合建立索引，使用多列索引的時(shí)候，要注意SQL中的條件順序等。

• SQL的優(yōu)化：有的時(shí)候查詢慢，可能是SQL寫的爛。查詢盡量用到索引，避免錯(cuò)誤的寫法導(dǎo)致索引失效，避免使用select *查詢出來(lái)所有的列，拆分復(fù)雜的SQL語(yǔ)句，查詢使用分頁(yè)等等。

• 分區(qū)：分區(qū)表是獨(dú)立的邏輯表，底層由多個(gè)物理表組成，這些對(duì)用戶來(lái)說(shuō)是透明的；如果按照分區(qū)字段查詢數(shù)據(jù)的話，就會(huì)在某一張分區(qū)表內(nèi)查詢，速度回比較快；分區(qū)字段的選擇，需要根據(jù)你們實(shí)際業(yè)務(wù)來(lái)；比如你們這張表如果可以分100個(gè)分區(qū)的話，那么每張表實(shí)際只有100萬(wàn)的數(shù)據(jù)；使用分區(qū)表盡量避免全表掃描；建議考慮這種優(yōu)化方式。

拋棄Mysql，遷移數(shù)據(jù)庫(kù)

• 如果公司有錢的話，可以直接上商業(yè)數(shù)據(jù)庫(kù)，Oracle、DB2什么的，一億的數(shù)據(jù)還是可以搞的定的，當(dāng)然會(huì)也比較貴。

• 其他開源數(shù)據(jù)庫(kù)，有可以支持千萬(wàn)級(jí)的產(chǎn)品，不過(guò)不建議使用，坑會(huì)比較多。

• 云數(shù)據(jù)庫(kù)，可以考慮把數(shù)據(jù)遷移到云上，比如ucloud云，花一些錢，少操一些；不過(guò)如果是比較敏感的數(shù)據(jù)，放到云上，多少會(huì)不太放心；私有云？這個(gè)也貴。

另外，如果不遷移Mysql的話，可以加以非關(guān)系型數(shù)據(jù)庫(kù)進(jìn)行輔助，例如一些數(shù)據(jù)放到Redis里面進(jìn)行緩存，或者通過(guò)跑數(shù)的方式，把原始數(shù)據(jù)加工好放到Mongodb中提供查詢，總之就是減少對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)。

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見(jiàn)解，希望能得到你的關(guān)注。

你不想分，就堆硬件堆帶寬唄。

單表數(shù)據(jù)上億可以采用以下方法

首先分表是必須的，然后分庫(kù)。

分表可以采用按時(shí)間分，根據(jù)實(shí)際情況一個(gè)月或一個(gè)季度的分。

網(wǎng)站前端列表采用只查詢最新表

另外是按分類分，如果數(shù)據(jù)還是大則在分類基礎(chǔ)上再時(shí)間拆分。

然后配合緩存，再不需要及時(shí)更新的頁(yè)面所有查詢都只從緩存中查詢。

這時(shí)候還慢的話，就再分庫(kù)

分庫(kù)最簡(jiǎn)單的就是讀者分離，兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。

如果讀者分離還慢，就考慮再加多臺(tái)讀服務(wù)器。

程序上不想改動(dòng)就采用負(fù)載均衡分?jǐn)倝毫Α?/p>

但是這樣還有個(gè)問(wèn)題就是，每臺(tái)服務(wù)器都要保存一樣的數(shù)據(jù)，及時(shí)同步，數(shù)據(jù)量大維護(hù)挺麻煩。

所以就得再業(yè)務(wù)層分庫(kù)了

最簡(jiǎn)單的就是按地區(qū)分庫(kù)，訪問(wèn)量高的地區(qū)都多帶帶使用服務(wù)器，只保存當(dāng)前地區(qū)的數(shù)據(jù)，同時(shí)該地區(qū)數(shù)據(jù)也可以再分表，分庫(kù)。

業(yè)務(wù)層要做的就是在訪問(wèn)入口判斷用戶所在地區(qū)，然后訪問(wèn)當(dāng)前地區(qū)數(shù)據(jù)庫(kù)。像58同城這種帶地區(qū)分站的網(wǎng)站都是這種策略。

一般大網(wǎng)站都是數(shù)據(jù)庫(kù)分布式，緩存分布式，模塊多帶帶部署，負(fù)載均衡，多節(jié)點(diǎn)，多種技術(shù)結(jié)合在一起的。

不過(guò)一億數(shù)據(jù)，分表和讀者分離，緩存就解決了。

負(fù)載均衡

緩存

很高興能夠看到和回答這個(gè)問(wèn)題,作為一個(gè)悟空問(wèn)答愛(ài)好者，我每天都在關(guān)注各個(gè)方面的消息，每天收獲也蠻多的。下面我將根據(jù)自己的經(jīng)驗(yàn)認(rèn)真回答這個(gè)問(wèn)題。

mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，除了分庫(kù)分表之外，還有沒(méi)有其他的解決方式？

MySQL是世界上最受歡迎的開源數(shù)據(jù)庫(kù)。憑借其經(jīng)過(guò)驗(yàn)證的性能，可靠性和易用性，MySQL已成為基于Web的應(yīng)用程序的領(lǐng)先數(shù)據(jù)庫(kù)選擇，被包括Facebook，Twitter，You Tube，Yahool等在內(nèi)的知名Web財(cái)產(chǎn)所使用。

Oracle推動(dòng)MySQL創(chuàng)新，提供了支持下一代Web，云服務(wù)，移動(dòng)和嵌入式應(yīng)用程序的新功能。MysQL是數(shù)據(jù)庫(kù)的相對(duì)控制系統(tǒng)。它將數(shù)據(jù)存儲(chǔ)在不同的表中，而不是存儲(chǔ)空間較廣，從而提高了速度和靈活性。

MySQL是最常用的訪問(wèn)數(shù)據(jù)庫(kù)的語(yǔ)言。根據(jù)雙因素認(rèn)證政策，MySQL軟件開發(fā)分為社區(qū)版和商業(yè)版。功率大、速度快、規(guī)模小、成本低，特別是使用開源數(shù)據(jù)庫(kù)，因?yàn)檎麄€(gè)網(wǎng)站都是選用MySQL。

例如，MysQL為中小企業(yè)提供了比Oracle、DB2、SQL Server、SQL Server等個(gè)人用戶更多的機(jī)會(huì)。由于MySQL是開源軟件，這可能會(huì)大大降低整體成本。

Linux是操作系統(tǒng)，Apache或Nginx是Web服務(wù)器，MySQL是數(shù)據(jù)庫(kù)，PHP/Perl/python是服務(wù)器解釋器。由于這四種軟體都是免費(fèi)或免費(fèi)(FLOSS)的，所以應(yīng)用這種方法可以不計(jì)成本地建立一個(gè)穩(wěn)定的免費(fèi)網(wǎng)絡(luò)系統(tǒng)LAMP或LNMP。

mysql數(shù)據(jù)庫(kù)本身是非常靈活的，這就導(dǎo)致了性能上的不足，嚴(yán)重依賴開發(fā)人員的能力。這就意味著開發(fā)人員的技術(shù)要高，mysql的性能要高。這也與很多數(shù)據(jù)庫(kù)類型有關(guān)，所以dba的工資通常較高。

為了避免表字段出現(xiàn)空值，空值難以優(yōu)化，而且占用額外的索引空間，默認(rèn)值為0，而不是空值。

mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，我們?cè)撛趺崔k呢？

思路一：

1. 用INT代替BIGINT，加上UNSIGNED(這樣體積會(huì)翻倍)，當(dāng)然可以用TINT、SmalLINT和MEDIUM.inti更好。
2. 用列表或整數(shù)代替字符串類型
3. 使用TIMSTATIME代替DATETIME。
4. 表上的字段不要太多，建議20歲以下。
5. 保持IP的完整性

思路二、修改索引：

索引沒(méi)有更好的選擇，要看是否按要求創(chuàng)建索引。如果是，EXPLAIN可以通過(guò)討論中的命令和列中的命令來(lái)決定是使用索引還是完全掃描表。

1. 不能根據(jù)子程序中NULL的值來(lái)判斷，否則可能會(huì)導(dǎo)致引擎在完全掃描表時(shí)停止使用索引。
2. 值分布非常罕見(jiàn)的字段不適合做索引。例如，性別只有兩個(gè)重要區(qū)域。
3. 字符字段只包含前綴。
4. 字符字段不應(yīng)該是主鍵。
5. 不要使用通過(guò)軟件連接的外部鍵。
6. 不要使用UNIQUE
7. 使用多行索引將保留搜索和條件序列，不必要的獨(dú)立索引將被刪除。

以上便是我的一些見(jiàn)解和回答，可能不能如您所愿，但我真心希望能夠?qū)δ兴鶐椭?！不清楚的地方您還可以關(guān)注我的頭條號(hào)“每日精彩科技”我將竭盡所知幫助您！

碼字不易，感覺(jué)寫的還行的話，還請(qǐng)點(diǎn)個(gè)贊哦！

作為一名IT行業(yè)的從業(yè)人員，主要在從事產(chǎn)品研發(fā)及項(xiàng)目管理工作，在項(xiàng)目過(guò)程中，經(jīng)常有優(yōu)化數(shù)據(jù)庫(kù)存儲(chǔ)、架構(gòu)方面的方案，所以我來(lái)探討一下這個(gè)問(wèn)題。

目前經(jīng)常使用的關(guān)系型數(shù)據(jù)庫(kù)如MySQL、SQL Server等，都是以“行”為單位進(jìn)行存儲(chǔ)，為了快速檢索，也都采用了B樹或其他索引技術(shù)。

從原理上來(lái)講，表中的數(shù)據(jù)越多，索引樹的范圍越大，磁盤讀取也越多，性能也就越低。

從實(shí)踐角度來(lái)看，一般以百萬(wàn)到千萬(wàn)作為一個(gè)表的存儲(chǔ)量級(jí)，超出該范圍之后，性能就會(huì)下降，需要采用其他技術(shù)手段解決。

首先想到的就是能否將讀和寫分離，主數(shù)據(jù)庫(kù)用于寫入，讀數(shù)據(jù)庫(kù)（多個(gè)）用于對(duì)外提供查詢，通過(guò)數(shù)據(jù)復(fù)制的方式將主數(shù)據(jù)庫(kù)的數(shù)據(jù)同步到讀庫(kù)。該架構(gòu)提升了數(shù)據(jù)庫(kù)的讀寫能力，但對(duì)于主數(shù)據(jù)庫(kù)的寫入能力依然沒(méi)法擴(kuò)展。

其次，垂直分表就是把一個(gè)數(shù)據(jù)量很大的表,可以按某個(gè)字段的屬性或使用頻繁程度分類,拆分為多個(gè)表。如有多種業(yè)務(wù)類型，每種業(yè)務(wù)類型建立不同的表，tb1,tb2,tb3。如果日常業(yè)務(wù)不需要使用所有數(shù)據(jù)，可以按時(shí)間分表，比如說(shuō)月表。每個(gè)表只存一個(gè)月的記錄。

再次，水平分表就是根據(jù)一列或多列數(shù)據(jù)的值把數(shù)據(jù)行放到多個(gè)獨(dú)立的表里，這里不具備業(yè)務(wù)意義。如按照id分表，末尾是0-9的數(shù)據(jù)分別插入到10個(gè)表里面。

這樣做的好處就是解決了數(shù)據(jù)存儲(chǔ)容量的問(wèn)題，但也帶來(lái)了諸多弊端，不再一一闡述。

mysql優(yōu)化的方式有很多，選擇上主要還是要考慮個(gè)人的實(shí)際情況，如代碼不可控的情況下，就不適合選擇按字段屬性分表的情況，這樣可能會(huì)帶來(lái)大量的重構(gòu)以及很多不可預(yù)期的風(fēng)險(xiǎn)。

而架構(gòu)的優(yōu)化，雖然對(duì)應(yīng)用是透明的，但對(duì)sql的寫法有很多局限性，比如說(shuō)不能使用聚合函數(shù)等等，同時(shí)也需要有充足的硬件資源，只有一臺(tái)服務(wù)器的情況下是沒(méi)有意義的。

相比起來(lái)，代價(jià)最低的是按時(shí)間分表或分區(qū)，這兩種辦法對(duì)應(yīng)用來(lái)說(shuō)都是透明的。分區(qū)只需要一次本地?cái)?shù)據(jù)遷移的操作。而通過(guò)分表把現(xiàn)網(wǎng)數(shù)據(jù)和歷史數(shù)據(jù)分離，唯一的代價(jià)是定期的數(shù)據(jù)維護(hù)。

一般如果表里面有1億數(shù)據(jù)的情況下，索引的問(wèn)題應(yīng)該是常識(shí)了，這方面我就不說(shuō)了。

在做垂直拆分或者水平擴(kuò)展的時(shí)候，要大概清楚2億條數(shù)據(jù)庫(kù)是都經(jīng)常性進(jìn)行大規(guī)模的查詢還是更新？這決定了你擴(kuò)展的思路，如果是范范的進(jìn)行擴(kuò)展，有時(shí)候會(huì)起到適得其反的效果。

1.首先要檢查哪些經(jīng)常查詢的SQL是否可以有優(yōu)化的地方，檢查數(shù)據(jù)庫(kù)的索引建立的是否合理，索引是否有效，可以嘗試建立分區(qū)表等，這一步主要是單個(gè)數(shù)據(jù)庫(kù)的優(yōu)化。

2.在mysql的擴(kuò)展上包括垂直拆分，即分庫(kù)分表的，這種需求需要在代碼層實(shí)現(xiàn)，需要開發(fā)人員在代碼層進(jìn)行一些配置。這個(gè)可以起到寫的負(fù)載均衡。而水平擴(kuò)展說(shuō)白一點(diǎn)就是增加服務(wù)器的個(gè)數(shù)，由原來(lái)的一臺(tái)變成幾臺(tái)，再通過(guò)mysql的中間件，比如proxysql或者mycat進(jìn)行一些配置（推薦proxysql），把寫請(qǐng)求放在那些性能好的服務(wù)器上，把讀分散到不同的服務(wù)器上，這樣就起到了讀的負(fù)載均衡。

3.如果上面垂直拆分或者水平擴(kuò)展還是不能解決問(wèn)題，可以考慮使用nosql，在前端增加一個(gè)緩存，memory cache或者redis來(lái)增加緩存，應(yīng)用層在首先會(huì)讀取redis里的數(shù)據(jù)，如果沒(méi)有才會(huì)往MySQL里去讀，當(dāng)然你的查詢不能是太過(guò)復(fù)雜的查詢。個(gè)人推薦redis，畢竟它可以磁盤落地化。

綜上所述，應(yīng)該可以解決問(wèn)題。當(dāng)然這里只是提供思路，沒(méi)有一種方案是完美的，都需要根據(jù)需求去定制。

軟件設(shè)計(jì)表數(shù)據(jù)量太大這個(gè)是架構(gòu)設(shè)計(jì)里，常遇到的問(wèn)題。

先考慮優(yōu)化，讀寫分離、合理索引、緩存數(shù)據(jù)、高頻讀取寫進(jìn)redis等產(chǎn)品，也可以買非常多的實(shí)例來(lái)做負(fù)載，不過(guò)這些操作撐不了多久。 分庫(kù)分表幾乎是唯一的，也是最好的辦法。

當(dāng)然分庫(kù)分表大家不愿意操作，主要還是因?yàn)橐膭?dòng)業(yè)務(wù)代碼，還有一種傻瓜式操作，不需要你改業(yè)務(wù)代碼，那就是分區(qū)，例如你把數(shù)據(jù)一個(gè)月分一個(gè)區(qū)，數(shù)據(jù)庫(kù) mysql 單表數(shù)據(jù)量達(dá)到千萬(wàn)、億級(jí)，可以通過(guò)分表與表分區(qū)提升服務(wù)性能。

不過(guò)你說(shuō)不想分庫(kù)分表，那就拿錢抗啊,上商業(yè)數(shù)據(jù)庫(kù)，Oracle、DB2、PGSQL等,即使上這些數(shù)據(jù)庫(kù)，你遲早還是得根據(jù)業(yè)務(wù)分庫(kù)分表，這個(gè)你可以問(wèn)下頭條，淘寶，知乎這些大量數(shù)據(jù)的工程師，長(zhǎng)期下去分庫(kù)，分表是唯一出入。

你看京東，淘寶你的訂單數(shù)據(jù)就知道了，默認(rèn)顯示三個(gè)月， 有可能他們就是定義最近三個(gè)月為熱數(shù)據(jù)，當(dāng)前常用庫(kù)，之前你的訂單在歷史數(shù)據(jù)庫(kù)里面。這樣的好處，顯而易見(jiàn)的，你的系統(tǒng)查詢速度最大的影響因素，就是數(shù)據(jù)量。

這就像一個(gè)箱子里面裝了100人，只能從上面往下面看找人， 如果你有1000人，做成10層的箱子， 要去箱子里面找出5個(gè)穿紅色衣服的人很慢。 如果分成10個(gè)箱子，即使查找10次，也比在一個(gè)箱子里面快。

架構(gòu)里面雖然沒(méi)有什么唯一的解決辦法，遇到大數(shù)據(jù)，思路基本都是統(tǒng)一的，減少源站數(shù)據(jù)庫(kù)訪問(wèn)，分庫(kù)分表。

請(qǐng)問(wèn)你描述的這個(gè)問(wèn)題說(shuō)的是我么？【哭臉】很不湊巧，由于預(yù)計(jì)錯(cuò)誤本來(lái)計(jì)算大概有800多萬(wàn)的數(shù)據(jù)，最終處理完共計(jì)4億9千多萬(wàn)【后面的零頭我甚至不想說(shuō)了】,一張表4億多的數(shù)據(jù)，用的自增id幸虧id沒(méi)有爆，不幸中的萬(wàn)幸透露著另一個(gè)不幸就是，因?yàn)檫@臺(tái)裝有mysql的服務(wù)器上數(shù)據(jù)量很大，在我往里插入數(shù)據(jù)的時(shí)候在插到4億多的時(shí)候磁盤滿了，一點(diǎn)空間都沒(méi)有了，驚不驚喜意不意外【哭笑臉】,因?yàn)檫@個(gè)數(shù)據(jù)屬于一次性的數(shù)據(jù)，用于進(jìn)行深度學(xué)習(xí)所需的訓(xùn)練數(shù)據(jù)，但是讀的壓力也很大，隨便一個(gè)select7分鐘起步~~~~

難難難啊！最后我的解決辦法就是刪除了當(dāng)前服務(wù)器上的一部分日志，讓mysql可以動(dòng)起來(lái)，然后將數(shù)據(jù)按1000萬(wàn)一個(gè)的導(dǎo)成小表，然后把大表數(shù)據(jù)刪除，步驟大概是

1、新建一個(gè)表結(jié)構(gòu)一致的表后綴按照xxx_0,xxx_1 等方式命名

2、將大表中的1000萬(wàn)數(shù)據(jù)導(dǎo)入創(chuàng)建的表中命令為

INSERT INTO `小表_01` (`xxx`) (SELECT `xxxx` FROM `大表` LIMIT 0, 10000000)

3、刪除掉大表中前1000萬(wàn)條數(shù)據(jù)

DELETE FROM 大表 LIMIT 10000000

我是按照上面的步驟搞得，會(huì)大大減少操作表所需的時(shí)間

不過(guò)如果問(wèn)不想分庫(kù)分表的話，有一個(gè)辦法就是加內(nèi)存，磁盤全部換固態(tài)，內(nèi)存是用來(lái)查詢數(shù)據(jù)時(shí)防止獲取到的數(shù)據(jù)量過(guò)大而導(dǎo)致內(nèi)存爆掉

換固態(tài)則會(huì)為數(shù)據(jù)的插入和讀出提高速度。

除此之外還有什么為了提高搜索速度設(shè)置索引一類的，不過(guò)幾億的數(shù)據(jù)設(shè)置索引效果也不會(huì)太大。

最終，建議還是不要叫一張表數(shù)據(jù)量超過(guò)1000萬(wàn)，會(huì)導(dǎo)致出現(xiàn)各種問(wèn)題，如果超了最方便的辦法就是分庫(kù)分表。

以上希望能對(duì)題主有幫助~~~~~~

一億數(shù)據(jù)其實(shí)也不算太大，分庫(kù)分表主要是解決以前mysql不支持online ddl，現(xiàn)在的版本很多都支持online了，即使一些少見(jiàn)操作不支持online 也有解決辦法，分表之后，應(yīng)用復(fù)雜了。

下面，我將用2分鐘的時(shí)間，與您深入探討，mysql表數(shù)據(jù)量達(dá)1億多條時(shí)，應(yīng)該采取什么措施，如果您有不同的見(jiàn)解，可以在評(píng)論區(qū)與我交流。(文末有免費(fèi)福利)

如果你不嫌麻煩，或不計(jì)成本，請(qǐng)看以下幾個(gè)方法

方法一：換機(jī)器，加硬盤，加內(nèi)存。

方法二：聘請(qǐng)一個(gè)數(shù)據(jù)顧問(wèn)。

方法三：看數(shù)據(jù)增量，每行數(shù)據(jù)的大小，一億數(shù)據(jù)，如果操作簡(jiǎn)單的話，也不是沒(méi)法處理。

方法四：一億多都是需要的記錄么？對(duì)于不需要的記錄，可以定時(shí)歸檔。

方法挺多，但都要根據(jù)情況細(xì)分，有點(diǎn)兒麻煩。

如果你想走捷徑，拿來(lái)即用，那么請(qǐng)看這里

用云表內(nèi)嵌的MySQL數(shù)據(jù)庫(kù)，其研發(fā)團(tuán)隊(duì)一直在升級(jí)維護(hù)MySQL，性能得以優(yōu)化，存儲(chǔ)一億數(shù)據(jù)量，不是問(wèn)題。

因?yàn)閷I(yè)且強(qiáng)大，所以MySQL是90%的企業(yè)都會(huì)選擇的數(shù)據(jù)庫(kù)。

如果你覺(jué)得不合適，那么你也可以根據(jù)云表的幫助文檔，設(shè)置成sql server，Oracle數(shù)據(jù)庫(kù)。

我們都知道數(shù)據(jù)庫(kù)的作用巨大，正是因?yàn)橛辛藬?shù)據(jù)庫(kù)，我們可以直接查找數(shù)據(jù)。

例如你每天使用余額寶查看自己的賬戶收益，就是從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)后給你的。

你的銀行卡賬號(hào)，密碼里面的RMB等等都是查詢的數(shù)據(jù)庫(kù)。

之所以建議你使用云表內(nèi)嵌的MySQL數(shù)據(jù)庫(kù)，是因?yàn)椋ㄟ^(guò)云表，還可以與企業(yè)微信、釘釘、用友金蝶、浪潮等第三方系統(tǒng)進(jìn)行對(duì)接。

而MySQL數(shù)據(jù)庫(kù)作用范圍下的，erp，oa，wms，商業(yè)智能（BI），進(jìn)銷存等各類業(yè)務(wù)應(yīng)用，通過(guò)它也是可以開發(fā)出來(lái)的。

并且開發(fā)出來(lái)的業(yè)務(wù)應(yīng)用，秉承了MySQL語(yǔ)句增刪改查的特性。

沒(méi)錯(cuò)，用云表開發(fā)出來(lái)的業(yè)務(wù)應(yīng)用，功能是隨時(shí)可以增刪查改的。

事實(shí)上，云表就是一個(gè)“辦公軟件+開發(fā)工具”。

由于云表內(nèi)嵌了MySQL數(shù)據(jù)庫(kù)的原因，所以通過(guò)它可以進(jìn)行復(fù)雜的數(shù)據(jù)運(yùn)算，如數(shù)據(jù)透視，數(shù)據(jù)分析等，億級(jí)數(shù)據(jù)，秒級(jí)響應(yīng)。

還可以對(duì)它設(shè)置精確到行列的權(quán)限管控，進(jìn)行工作流，流程審批，多人協(xié)同等工作。

當(dāng)然啦，其他大大小小的業(yè)務(wù)，也是可以解決的。

比如說(shuō)制作報(bào)表看板，H5頁(yè)面生成，掃碼出入庫(kù)，與API接口進(jìn)行對(duì)接，封裝PDA，鬧鐘提醒，群發(fā)信息，生成移動(dòng)端app......

像許繼電氣，中冶，中鐵，香港建滔集團(tuán)，南方物流，燕山大學(xué)等，都在使用它。

可以免費(fèi)使用

目前，云表是有提供永久免費(fèi)版本的。

內(nèi)嵌的MySQL數(shù)據(jù)庫(kù)，數(shù)據(jù)安全不丟失

它的數(shù)據(jù)存儲(chǔ)方式有：本地部署，云端部署，混合部署等多種部署方式。

也就是說(shuō)，云表不僅內(nèi)嵌了MySQL數(shù)據(jù)庫(kù)，而且還保證了數(shù)據(jù)的安全。

篇幅所限，就說(shuō)到這里。

高山流水，終須一別。免費(fèi)的軟件獲取方式在此奉上。

1. 點(diǎn)贊+評(píng)論+轉(zhuǎn)發(fā)

2. 關(guān)注我，點(diǎn)擊我的頭像，私信給我發(fā)送：cc

如果不是特別必要，我建議還是不要瞎折騰，不然數(shù)據(jù)庫(kù)沒(méi)搞好，還會(huì)添一堆麻煩事兒！

分庫(kù)分表是最常規(guī)也是最常見(jiàn)的一種解決數(shù)據(jù)量過(guò)大的方式。分表的話也分為垂直分和水平分。下面我列舉一下其他的方式

1、讀寫分離。就是將數(shù)據(jù)庫(kù)的讀寫操作分開，比如讓主服務(wù)器讀，從服務(wù)器去做寫操作，或者讓性能比較好的服務(wù)器去做寫操作，性能不太好的服務(wù)器做讀操作；具體如何去讀寫分離，要看我們?nèi)绾稳シ至恕?/p>

2、靜態(tài)緩存。分為本地緩存和服務(wù)緩存，本地緩存就是將數(shù)據(jù)加載到本地，服務(wù)緩存就是比如使用Redis這樣的k-v數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)熱點(diǎn)數(shù)據(jù)。但是使用服務(wù)緩存也有缺點(diǎn)，最常見(jiàn)的問(wèn)題就是，“擊穿”，就是假如緩存都失效了，這時(shí)候并發(fā)請(qǐng)求都去訪問(wèn)db，此時(shí)可能造成服務(wù)器掛掉，這個(gè)時(shí)候?yàn)榱吮苊膺@種情況，一般都是使用互斥量來(lái)解決這種問(wèn)題。

3、系統(tǒng)架構(gòu)。這個(gè)就要看我們整體項(xiàng)目的架構(gòu)設(shè)計(jì)，主要是包括SQL操作的設(shè)計(jì)