這篇文章給大家介紹數(shù)據(jù)庫(kù)分表以及優(yōu)化需要注意什么，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

翔安網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。成都創(chuàng)新互聯(lián)公司成立于2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專(zhuān)注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)公司。

數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)，為什么進(jìn)行分表?分庫(kù)?一般多少數(shù)據(jù)量開(kāi)始分表?分庫(kù)?分庫(kù)分表的目的?什么是數(shù)據(jù)庫(kù)垂直拆分?水平拆分?分區(qū)等等

一：為什么要分表

當(dāng)一張表的數(shù)據(jù)達(dá)到幾百萬(wàn)時(shí)，你查詢(xún)一次所花的時(shí)間會(huì)變多，如果有聯(lián)合查詢(xún)的話，有可能會(huì)死在那兒了。分表的目的就在于此，減小數(shù)據(jù)庫(kù)的負(fù)擔(dān)，縮短查詢(xún)時(shí)間。日常開(kāi)發(fā)中我們經(jīng)常會(huì)遇到大表的情況，所謂的大表是指存儲(chǔ)了百萬(wàn)級(jí)乃至千萬(wàn)級(jí)條記錄的表。這樣的表過(guò)于龐大，導(dǎo)致數(shù)據(jù)庫(kù)在查詢(xún)和插入的時(shí)候耗時(shí)太長(zhǎng)，性能低下，如果涉及聯(lián)合查詢(xún)的情況，性能會(huì)更加糟糕。分表和表分區(qū)的目的就是減少數(shù)據(jù)庫(kù)的負(fù)擔(dān)，提高數(shù)據(jù)庫(kù)的效率，通常點(diǎn)來(lái)講就是提高表的增刪改查效率。數(shù)據(jù)庫(kù)中的數(shù)據(jù)量不一定是可控的，在未進(jìn)行分庫(kù)分表的情況下，隨著時(shí)間和業(yè)務(wù)的發(fā)展，庫(kù)中的表會(huì)越來(lái)越多，表中的數(shù)據(jù)量也會(huì)越來(lái)越大，相應(yīng)地，數(shù)據(jù)操作，增刪改查的開(kāi)銷(xiāo)也會(huì)越來(lái)越大;另外，由于無(wú)法進(jìn)行分布式式部署，而一臺(tái)服務(wù)器的資源(CPU、磁盤(pán)、內(nèi)存、IO 等)是有限的，最終數(shù)據(jù)庫(kù)所能承載的數(shù)據(jù)量、數(shù)據(jù)處理能力都將遭遇瓶頸。

二：分表的方案

1，做 MySQL 集群，有人會(huì)問(wèn) mysql 集群，根分表有什么關(guān)系嗎?雖然它不是實(shí)際意義上的分表，但是它啟到了分表的作用，做集群的意義是什么呢?為一個(gè)數(shù)據(jù)庫(kù)減輕負(fù)擔(dān)，說(shuō)白了就是減少 sql 排隊(duì)隊(duì)列中的 sql 的數(shù)量，舉個(gè)例子：有 10 個(gè) sql 請(qǐng)求，如果放在一個(gè)數(shù)據(jù)庫(kù)服務(wù)器的排隊(duì)隊(duì)列中，他要等很長(zhǎng)時(shí)間，如果把這 10 個(gè) sql 請(qǐng)求，分配到 5 個(gè)數(shù)據(jù)庫(kù)服務(wù)器的排隊(duì)隊(duì)列中，一個(gè)數(shù)據(jù)庫(kù)服務(wù)器的隊(duì)列中只有 2 個(gè)，這樣等待時(shí)間是不是大大的縮短了呢?

linux mysql proxy 的安裝，配置，以及讀寫(xiě)分離

mysql replication 互為主從的安裝及配置，以及數(shù)據(jù)同步

優(yōu)點(diǎn)：擴(kuò)展性好，沒(méi)有多個(gè)分表后的復(fù)雜操作(php 代碼)

缺點(diǎn)：?jiǎn)蝹€(gè)表的數(shù)據(jù)量還是沒(méi)有變，一次操作所花的時(shí)間還是那么多，硬件開(kāi)銷(xiāo)大。

2. 數(shù)據(jù)庫(kù)優(yōu)化有哪些?分別需要注意什么?

SQL 優(yōu)化的原則是：將一次操作需要讀取的 BLOCK 數(shù)減到最低，即在最短的時(shí)間達(dá)到最大的數(shù)據(jù)吞吐量。

調(diào)整不良 SQL 通?？梢詮囊韵聨c(diǎn)切入：

檢查不良的 SQL，考慮其寫(xiě)法是否還有可優(yōu)化內(nèi)容

檢查子查詢(xún) 考慮 SQL 子查詢(xún)是否可以用簡(jiǎn)單連接的方式進(jìn)行重新書(shū)寫(xiě)

檢查優(yōu)化索引的使用

考慮數(shù)據(jù)庫(kù)的優(yōu)化器

避免出現(xiàn) SELECT * FROM table 語(yǔ)句，要明確查出的字段。

在一個(gè) SQL 語(yǔ)句中，如果一個(gè) where 條件過(guò)濾的數(shù)據(jù)庫(kù)記錄越多，定位越準(zhǔn)確，則該 where 條件越應(yīng)該前移。

查詢(xún)時(shí)盡可能使用索引覆蓋。即對(duì) SELECT 的字段建立復(fù)合索引，這樣查詢(xún)時(shí)只進(jìn)行索引掃描，不讀取數(shù)據(jù)塊。

在判斷有無(wú)符合條件的記錄時(shí)建議不要用 SELECT COUNT ()和 select top 1 語(yǔ)句。

使用內(nèi)層限定原則，在拼寫(xiě) SQL 語(yǔ)句時(shí)，將查詢(xún)條件分解、分類(lèi)，并盡量在 SQL 語(yǔ)句的最里層進(jìn)行限定，以減少數(shù)據(jù)的處理量。

應(yīng)絕對(duì)避免在 order by 子句中使用表達(dá)式。

如果需要從關(guān)聯(lián)表讀數(shù)據(jù)，關(guān)聯(lián)的表一般不要超過(guò) 7 個(gè)。

小心使用 IN 和 OR，需要注意 In 集合中的數(shù)據(jù)量。建議集合中的數(shù)據(jù)不超過(guò) 200 個(gè)。

<> 用 < 、> 代替，> 用 >= 代替，< 用 <= 代替，這樣可以有效的利用索引。 　　在查詢(xún)時(shí)盡量減少對(duì)多余數(shù)據(jù)的讀取包括多余的列與多余的行。 　　對(duì)于復(fù)合索引要注意，例如在建立復(fù)合索引時(shí)列的順序是 F1，F(xiàn)2，F(xiàn)3，則在 where 或 order by 子句中這些字段出現(xiàn)的順序要與建立索引時(shí)的字段順序一致，且必須包含第一列。只能是 F1 或 F1，F(xiàn)2 或 F1，F(xiàn)2，F(xiàn)3。否則不會(huì)用到該索引。 　　多表關(guān)聯(lián)查詢(xún)時(shí)，寫(xiě)法必須遵循以下原則，這樣做有利于建立索引，提高查詢(xún)效率。格式如下 　　select sum(table1.je) from table1 table1, table2 table2, table3 table3 where (table1的等值條件(=)) and(table1的非等值條件) and (table2與table1的關(guān)聯(lián)條件) and (table2的等值條件) and (table2的非等值條件) and(table3與table2的關(guān)聯(lián)條件) and (table3的等值條件) and (table3的非等值條件)。 　　注：關(guān)于多表查詢(xún)時(shí) from 后面表的出現(xiàn)順序?qū)π实挠绊戇€有待研究。 　　子查詢(xún)問(wèn)題。對(duì)于能用連接方式或者視圖方式實(shí)現(xiàn)的功能，不要用子查詢(xún) 　　在 WHERE 子句中，避免對(duì)列的四則運(yùn)算，特別是 where 條件的左邊，嚴(yán)禁使用運(yùn)算與函數(shù)對(duì)列進(jìn)行處理。比如有些地方 substring 可以用 like 代替。 　　如果在語(yǔ)句中有 not in(in)操作，應(yīng)考慮用 not exists(exists)來(lái)重寫(xiě)，最好的辦法是使用外連接實(shí)現(xiàn)。 　　對(duì)一個(gè)業(yè)務(wù)過(guò)程的處理，應(yīng)該使事物的開(kāi)始與結(jié)束之間的時(shí)間間隔越短越好，原則上做到數(shù)據(jù)庫(kù)的讀操作在前面完成，數(shù)據(jù)庫(kù)寫(xiě)操作在后面完成，避免交叉。 　　請(qǐng)小心不要對(duì)過(guò)多的列使用列函數(shù)和 order by,group by 等，謹(jǐn)慎使用 disti 軟件開(kāi)發(fā) t。 　　用 union all 代替 union，數(shù)據(jù)庫(kù)執(zhí)行 union 操作，首先先分別執(zhí)行 union 兩端的查詢(xún)，將其放在臨時(shí)表中，然后在對(duì)其進(jìn)行排序，過(guò)濾重復(fù)的記錄。 　　當(dāng)已知的業(yè)務(wù)邏輯決定 query A 和 query B 中不會(huì)有重復(fù)記錄時(shí)，應(yīng)該用 union all 代替 union，以提高查詢(xún)效率。 　　20、選取最適用的字段屬性 ，MySQL 可以很好的支持大數(shù)據(jù)量的存取，但是一般說(shuō)來(lái)，數(shù)據(jù)庫(kù)中的表越小，在它上面執(zhí)行的查詢(xún)也就會(huì)越快。因此，在創(chuàng)建表的時(shí)候，為了獲得更好的性能，我們可以將表中字段的寬度設(shè)得盡可能小。 　　例如，在定義郵政編碼這個(gè)字段時(shí)，如果將其設(shè)置為 CHAR (255), 顯然給數(shù)據(jù)庫(kù)增加了不必要的空間，甚至使用 VARCHAR 這種類(lèi)型也是多余的，因?yàn)?CHAR (6) 就可以很好的完成任務(wù)了。同樣的，如果可以的話，我們應(yīng)該使用 MEDIUMINT 而不是 BIGIN 來(lái)定義整型字段。 　　另外一個(gè)提高效率的方法是在可能的情況下，應(yīng)該盡量把字段設(shè)置為 NOTNULL，這樣在將來(lái)執(zhí)行查詢(xún)的時(shí)候，數(shù)據(jù)庫(kù)不用去比較 NULL 值。 　　對(duì)于某些文本字段，例如 “省份” 或者 “性別”，我們可以將它們定義為 ENUM 類(lèi)型。因?yàn)樵?MySQL 中，ENUM 類(lèi)型被當(dāng)作數(shù)值型數(shù)據(jù)來(lái)處理，而數(shù)值型數(shù)據(jù)被處理起來(lái)的速度要比文本類(lèi)型快得多。這樣，我們又可以提高數(shù)據(jù)庫(kù)的性能。 　　3. web 開(kāi)發(fā)方面會(huì)遇到哪些緩存?分別如何優(yōu)化?

瀏覽器緩存

在任何現(xiàn)代瀏覽器上 (如 IE, FireFox, Chrome) 折騰清除隱私數(shù)據(jù)的對(duì)話框，你很可能會(huì)注意到 “緩存” 這個(gè)設(shè)置項(xiàng)。

代理服務(wù)器緩存

Web 代理服務(wù)器使用同樣的緩存原理，只是規(guī)模更大。代理以同樣的方式服務(wù)千萬(wàn)用戶(hù)，大公司和 ISP 經(jīng)常在他們的防火墻或者單獨(dú)的設(shè)備(也被稱(chēng)為中介 (intermediaries))上架設(shè)代理緩存。

網(wǎng)關(guān)緩存

也被稱(chēng)為 “反向代理緩存” 或 “替代緩存”。網(wǎng)關(guān)緩存同樣是起中介作用的，不過(guò)不是網(wǎng)絡(luò)管理員部署的，而多半是網(wǎng)站管理員(公司專(zhuān)門(mén)的運(yùn)維工程師、或 UED 或程序組某人 Add)部署，這樣更容易擴(kuò)展與維護(hù)。

4. 給你 256M 的內(nèi)存，統(tǒng)計(jì) 10G 文件每個(gè)關(guān)鍵字出現(xiàn)的次數(shù)如何實(shí)現(xiàn)?

思路

$handle=fopen("/tmp/uploadfile.txt","r")ordie("Couldn't get handle");if($handle){while(!feof($handle)){$buffer=fgets($handle,4096);// Process buffer here..}fclose($handle);}

5. PHP 的生命周期 / 啟動(dòng)流程

完整的生命周期為模塊初始化、請(qǐng)求初始化、請(qǐng)求處理、請(qǐng)求關(guān)閉、模塊關(guān)閉五大階段。

cli 模式下，每個(gè)腳本都會(huì)完整的執(zhí)行上面的五大階段;對(duì)于 fastcgi 模式而言，只在啟動(dòng)時(shí)會(huì)執(zhí)行模塊初始化，之后的請(qǐng)求都走了請(qǐng)求初始化、處理請(qǐng)求、請(qǐng)求關(guān)閉三大階段，在 fastcgi 關(guān)閉時(shí)執(zhí)行模塊關(guān)閉階段。各個(gè)擴(kuò)展的加載也是在模塊初始化階段完成的。

6. 說(shuō)一下 PHP 的(內(nèi)存)垃圾回收機(jī)制

每一個(gè)變量對(duì)應(yīng)一個(gè) zval 數(shù)據(jù)結(jié)構(gòu)，在該結(jié)構(gòu)內(nèi)還有一個(gè) val 結(jié)構(gòu)體，該結(jié)構(gòu)體內(nèi)有一個(gè)引用計(jì)數(shù)(php7 而言，對(duì)于 php5，這個(gè)引用計(jì)數(shù)是保存在 zval 結(jié)構(gòu)中的)，標(biāo)識(shí)該對(duì)象的引用數(shù)，當(dāng)對(duì)象的引用計(jì)數(shù)為 0 時(shí)代表這個(gè)對(duì)象可被回收。

對(duì)象的 refcount 減少的時(shí)機(jī)：修改變量、函數(shù)返回(釋放局部變量)、unset 變量

對(duì)于數(shù)組和對(duì)象而言，可能存在變量中的成員引用變量本身的情況，也就是循環(huán)引用，這樣會(huì)造成這個(gè)變量永遠(yuǎn)不會(huì)被內(nèi)存回收，而成為垃圾。

PHP 里對(duì)于這種情況給出了垃圾回收機(jī)制：如果數(shù)組、對(duì)象的引用計(jì)數(shù)減少而且不為零，則認(rèn)為他們可能是垃圾，把他們放到垃圾收集器里。等垃圾收集器到了一定的數(shù)量之后，進(jìn)行垃圾處理：對(duì)所有可能的垃圾 refcount 減 1，如果為 1，說(shuō)明是垃圾，則進(jìn)行內(nèi)存回收;如果不為 1，說(shuō)明還有其他變量在使用，refcount 重新加 1;這種對(duì)象復(fù)用以及垃圾回收機(jī)制在其他語(yǔ)言中也有體現(xiàn)：redis 中也使用了引用計(jì)數(shù)表示每個(gè)對(duì)象的引用數(shù)量。

7. PHP7 與 PHP5 的區(qū)別

改進(jìn)的性能 - 將 PHPNG 代碼合并到 PHP7 中，速度是 PHP 5 的兩倍。

降低內(nèi)存消耗 - 優(yōu)化的 PHP 7 使用較少的資源。

標(biāo)量類(lèi)型聲明 - 現(xiàn)在可以強(qiáng)制執(zhí)行參數(shù)和返回類(lèi)型。

一致的 64 位支持 - 對(duì) 64 位體系結(jié)構(gòu)機(jī)器的一致支持。

改進(jìn)了異常層次 - 異常層次得到了改進(jìn)

許多致命的錯(cuò)誤轉(zhuǎn)換為例外 - 例外范圍增加，涵蓋許多致命的錯(cuò)誤轉(zhuǎn)換為例外。

安全隨機(jī)數(shù)發(fā)生器 - 增加新的安全隨機(jī)數(shù)發(fā)生器 API。

已棄用的 SAPI 和擴(kuò)展已刪除 - 各種舊的和不受支持的 SAPI 和擴(kuò)展從最新版本中刪除。

空合并運(yùn)算符(?) - 添加了新的空合并運(yùn)算符。

返回和標(biāo)量類(lèi)型聲明 - 支持所添加的返回類(lèi)型和參數(shù)類(lèi)型。

匿名類(lèi) - 支持匿名添加。

零成本斷言 - 支持零成本斷言增加。

8. MongoDB 應(yīng)用場(chǎng)景

mongodb 支持副本集、索引、自動(dòng)分片，可以保證較高的性能和可用性。

更高的寫(xiě)入負(fù)載

默認(rèn)情況下，MongoDB 更側(cè)重高數(shù)據(jù)寫(xiě)入性能，而非事務(wù)安全，MongoDB 很適合業(yè)務(wù)系統(tǒng)中有大量 “低價(jià)值” 數(shù)據(jù)的場(chǎng)景。但是應(yīng)當(dāng)避免在高事務(wù)安全性的系統(tǒng)中使用 MongoDB，除非能從架構(gòu)設(shè)計(jì)上保證事務(wù)安全。

高可用性

MongoDB 的復(fù)副集 (Master-Slave) 配置非常簡(jiǎn)潔方便，此外，MongoDB 可以快速響應(yīng)的處理單節(jié)點(diǎn)故障，自動(dòng)、安全的完成故障轉(zhuǎn)移。這些特性使得 MongoDB 能在一個(gè)相對(duì)不穩(wěn)定(如云主機(jī))的環(huán)境中，保持高可用性。

數(shù)據(jù)量很大或者未來(lái)會(huì)變得很大

依賴(lài)數(shù)據(jù)庫(kù) (MySQL) 自身的特性，完成數(shù)據(jù)的擴(kuò)展是較困難的事，在 MySQL 中，當(dāng)一個(gè)單達(dá)表到 5-10GB 時(shí)會(huì)出現(xiàn)明顯的性能降級(jí)，此時(shí)需要通過(guò)數(shù)據(jù)的水平和垂直拆分、庫(kù)的拆分完成擴(kuò)展，使用 MySQL 通常需要借助驅(qū)動(dòng)層或代理層完成這類(lèi)需求。而 MongoDB 內(nèi)建了多種數(shù)據(jù)分片的特性，可以很好的適應(yīng)大數(shù)據(jù)量的需求。

基于位置的數(shù)據(jù)查詢(xún)

MongoDB 支持二維空間索引，因此可以快速及精確的從指定位置獲取數(shù)據(jù)。

表結(jié)構(gòu)不明確

在一些傳統(tǒng) RDBMS 中，增加一個(gè)字段會(huì)鎖住整個(gè)數(shù)據(jù)庫(kù) / 表，或者在執(zhí)行一個(gè)重負(fù)載的請(qǐng)求時(shí)會(huì)明顯造成其它請(qǐng)求的性能降級(jí)。通常發(fā)生在數(shù)據(jù)表大于 1G 的時(shí)候(當(dāng)大于 1TB 時(shí)更甚)。 因 MongoDB 是文檔型數(shù)據(jù)庫(kù)，為非結(jié)構(gòu)貨的文檔增加一個(gè)新字段是很快速的操作，并且不會(huì)影響到已有數(shù)據(jù)。另外一個(gè)好處當(dāng)業(yè)務(wù)數(shù)據(jù)發(fā)生變化時(shí)，是將不在需要由 DBA 修改表結(jié)構(gòu)。

9. PHP 短信驗(yàn)證碼防刷機(jī)制

1、時(shí)間限制：60 秒后才能再次發(fā)送

從發(fā)送驗(yàn)證碼開(kāi)始，前端(客戶(hù)端)會(huì)進(jìn)行一個(gè) 60 秒的倒數(shù)，在這一分鐘之內(nèi)，用戶(hù)是無(wú)法提交多次發(fā)送信息的請(qǐng)求的。這種方法雖然使用得比較普遍，但是卻不是非常有用，技術(shù)稍微好點(diǎn)的人完全可以繞過(guò)這個(gè)限制，直接發(fā)送短信驗(yàn)證碼。

2、手機(jī)號(hào)限制：同一個(gè)手機(jī)號(hào)，24 小時(shí)之內(nèi)不能夠超過(guò) 5 條

對(duì)使用同一個(gè)手機(jī)號(hào)碼進(jìn)行注冊(cè)或者其他發(fā)送短信驗(yàn)證碼的操作的時(shí)候，系統(tǒng)可以對(duì)這個(gè)手機(jī)號(hào)碼進(jìn)行限制，例如，24 小時(shí)只能發(fā)送 5 條短信驗(yàn)證碼，超出限制則進(jìn)行報(bào)錯(cuò)(如：系統(tǒng)繁忙，請(qǐng)稍后再試)。然而，這也只能夠避免人工手動(dòng)刷短信而已，對(duì)于批量使用不同手機(jī)號(hào)碼來(lái)刷短信的機(jī)器，這種方法也是無(wú)可奈何的。

3、短信驗(yàn)證碼限制：30 分鐘之內(nèi)發(fā)送同一個(gè)驗(yàn)證碼

網(wǎng)上還有一種方法說(shuō)：30 分鐘之內(nèi)，所有的請(qǐng)求，所發(fā)送的短信驗(yàn)證碼都是同一個(gè)驗(yàn)證碼。第一次請(qǐng)求短信接口，然后緩存短信驗(yàn)證碼結(jié)果，30 分鐘之內(nèi)再次請(qǐng)求，則直接返回緩存的內(nèi)容。對(duì)于這種方式，不是很清楚短信接口商會(huì)不會(huì)對(duì)發(fā)送緩存信息收取費(fèi)用，如果有興趣可以了解了解。

4、前后端校驗(yàn)：提交 Token 參數(shù)校驗(yàn)

這種方式比較少人說(shuō)到，個(gè)人覺(jué)得可以這種方法值得一試。前端(客戶(hù)端)在請(qǐng)求發(fā)送短信的時(shí)候，同時(shí)向服務(wù)端提交一個(gè) Token 參數(shù)，服務(wù)端對(duì)這個(gè) Token 參數(shù)進(jìn)行校驗(yàn)，校驗(yàn)通過(guò)之后，再向請(qǐng)求發(fā)送短信的接口向用戶(hù)手機(jī)發(fā)送短信。

5、唯一性限制：微信產(chǎn)品，限制同一個(gè)微信 ID 用戶(hù)的請(qǐng)求數(shù)量

如果是微信的產(chǎn)品的話，可以通過(guò)微信 ID 來(lái)進(jìn)行識(shí)別，然后對(duì)同一個(gè)微信 ID 的用戶(hù)限制，24 小時(shí)之內(nèi)最多只能夠發(fā)送一定量的短信。

6、產(chǎn)品流程限制：分步驟進(jìn)行

例如注冊(cè)的短信驗(yàn)證碼使用場(chǎng)景，我們將注冊(cè)的步驟分成 2 步，用戶(hù)在輸入手機(jī)號(hào)碼并設(shè)置了密碼之后，下一步才進(jìn)入驗(yàn)證碼的驗(yàn)證步驟。

7、圖形驗(yàn)證碼限制：圖形驗(yàn)證通過(guò)后再請(qǐng)求接口

用戶(hù)輸入圖形驗(yàn)證碼并通過(guò)之后，再請(qǐng)求短信接口獲取驗(yàn)證碼。為了有更好的用戶(hù)體驗(yàn)，也可以設(shè)計(jì)成：一開(kāi)始不需要輸入圖形驗(yàn)證碼，在操作達(dá)到一定量之后，才需要輸入圖形驗(yàn)證碼。具體情況請(qǐng)根據(jù)具體場(chǎng)景來(lái)進(jìn)行設(shè)計(jì)。

8、IP 及 Cookie 限制：限制相同的 IP/Cookie 信息最大數(shù)量

使用 Cookie 或者 IP，能夠簡(jiǎn)單識(shí)別同一個(gè)用戶(hù)，然后對(duì)相同的用戶(hù)進(jìn)行限制(如：24 小時(shí)內(nèi)最多只能夠發(fā)送 20 條短信)。然而，Cookie 能夠清理、IP 能夠模擬，而且 IP 還會(huì)出現(xiàn)局域網(wǎng)相同 IP 的情況，因此，在使用此方法的時(shí)候，應(yīng)該根據(jù)具體情況來(lái)思考。

9、短信預(yù)警機(jī)制，做好出問(wèn)題之后的防護(hù)

以上的方法并不一定能夠完全杜絕短信被刷，因此，我們也應(yīng)該做好短信的預(yù)警機(jī)制，即當(dāng)短信的使用量達(dá)到一定量之后，向管理員發(fā)送預(yù)警信息，管理員可以立刻對(duì)短信的接口情況進(jìn)行監(jiān)控和防護(hù)。

10. 如何設(shè)計(jì)一個(gè)高并發(fā)的系統(tǒng)

① 數(shù)據(jù)庫(kù)的優(yōu)化，包括合理的事務(wù)隔離級(jí)別、SQL 語(yǔ)句優(yōu)化、索引的優(yōu)化

② 使用緩存，盡量減少數(shù)據(jù)庫(kù) IO

③ 分布式數(shù)據(jù)庫(kù)、分布式緩存

④ 服務(wù)器的負(fù)載均衡

11. PHP 的控制反轉(zhuǎn) (IOC) 和依賴(lài)注入 (DI) 概念

IOC(inversion of control)控制反轉(zhuǎn)模式;控制反轉(zhuǎn)是將組件間的依賴(lài)關(guān)系從程序內(nèi)部提到外部來(lái)管理;

DI(dependency injection)依賴(lài)注入模式;依賴(lài)注入是指將組件的依賴(lài)通過(guò)外部以參數(shù)或其他形式注入;

12. mySQL 里有 2000w 數(shù)據(jù)，redis 中只存 20w 的數(shù)據(jù)，如何保證 redis 中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)

相關(guān)知識(shí)：redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)施行數(shù)據(jù)淘汰策略(回收策略)。redis 提供 6 種數(shù)據(jù)淘汰策略：

volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集(server.db [i].expires)中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集(server.db [i].expires)中挑選將要過(guò)期的數(shù)據(jù)淘汰

volatile-random：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集(server.db [i].expires)中任意選擇數(shù)據(jù)淘汰

allkeys-lru：從數(shù)據(jù)集(server.db [i].dict)中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random：從數(shù)據(jù)集(server.db [i].dict)中任意選擇數(shù)據(jù)淘汰

no-enviction(驅(qū)逐)：禁止驅(qū)逐數(shù)據(jù)

關(guān)于數(shù)據(jù)庫(kù)分表以及優(yōu)化需要注意什么就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。