無論是做PHP開發(fā)還是做JAVA開發(fā)甚至前端開發(fā)，只要是開發(fā)，面試的時(shí)候都必考數(shù)據(jù)庫。為什么前端也要考數(shù)據(jù)庫？因?yàn)閿?shù)據(jù)庫課程是計(jì)算機(jī)的基礎(chǔ)課程，同樣的基礎(chǔ)課程還有操作系統(tǒng)，數(shù)據(jù)結(jié)構(gòu)。只要寫代碼就永遠(yuǎn)跳不出這三門基礎(chǔ)課。
面試官和面試者都知道要考數(shù)據(jù)庫，都會(huì)去刷題，數(shù)據(jù)庫的知識(shí)點(diǎn)其實(shí)很少，一天就能刷完。長久以往面試流程會(huì)變成背書流程，面試官題目沒說完，答題者已經(jīng)了然于心，這樣根本選不出合適的CRUD boy。很多大廠意識(shí)到了這點(diǎn)，所以一直在改革，比如宇宙大廠字節(jié)跳動(dòng)就需要手寫算法（紅黑樹是必背題）。怎么改呢？可以參考高考，拿高考數(shù)學(xué)來說，每年考察的知識(shí)點(diǎn)都差不多，這就會(huì)導(dǎo)致考滿分的人逐年遞增（優(yōu)秀的人和更優(yōu)秀的人無法拉開差距）。和機(jī)器學(xué)習(xí)很像，樣本量越大，考生越不需要靠「運(yùn)氣」做出「好」的結(jié)果。所以出題人要想辦法考察答題人的解題思路。
面試談到數(shù)據(jù)庫肯定會(huì)談到數(shù)據(jù)庫引擎，不同索引的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)，SQL優(yōu)化等。如果面試官直接問這幾個(gè)問題，面試者肯定對(duì)答如流。因?yàn)榫W(wǎng)上的面試寶典早已把這些問題分析的入木三分，配上一些形象的例子，比讀修仙小說還精彩。但優(yōu)秀的面試官從不按套路出牌。
正常來說程序員是不會(huì)關(guān)心自增ID用完的，阿里的編程規(guī)范廣為流傳，里面嚴(yán)格要求自增ID為unsigned bigint，程序員和DBA都默認(rèn)遵守這個(gè)規(guī)范。unsigned bigint到底有多大？The unsigned range is 0 to 18446744073709551615，想把這個(gè)值用完太難了。
那面試官到底想了解什么？
一. 自增ID用完了會(huì)報(bào)什么錯(cuò)？
具體報(bào)錯(cuò)信息是什么？面試官自己都不一定知道。不同的數(shù)據(jù)庫底層實(shí)現(xiàn)不一樣，不同版本也有差異。我測(cè)試不同版本的MySQL就有兩個(gè)答案
1. Duplicate entry '*****' for key 'PRIMARY'
2. SQL Error (167): Out of range value for column 'id'.
大家都知道會(huì)報(bào)錯(cuò)，但是沒人能肯定具體報(bào)錯(cuò)信息是什么?？赡苁菙?shù)據(jù)越界，也可能是主鍵沖突，那就沒有了標(biāo)準(zhǔn)答案，最后看誰的知識(shí)儲(chǔ)備更多。一般來說一面面試官的技術(shù)不一定比面試者強(qiáng)。
二. 自增ID為什么用不完？
第一個(gè)問題是為了引出第二個(gè)問題。因?yàn)樽栽鲋麈I通常會(huì)設(shè)置為unsigned bigint，最大值為18446744073709551615，假設(shè)我們的項(xiàng)目需要每秒記錄100萬條數(shù)據(jù)，這個(gè)自增ID使用100萬年后都用不完。全球也沒幾家公司能達(dá)到這個(gè)量級(jí)。
如果面試官問200萬年后不會(huì)用完嗎？這是個(gè)好問題。
參照當(dāng)前的數(shù)據(jù)庫軟件和服務(wù)器硬件來說，MySQL單機(jī)單表的處理能力是千萬級(jí)別。意思是當(dāng)單表數(shù)據(jù)達(dá)到1千萬時(shí)，MySQL性能就會(huì)開始下降，需要著手優(yōu)化，這里的瓶頸主要是查詢耗時(shí)。我們可以通過分區(qū)再撐一段時(shí)間，當(dāng)數(shù)據(jù)量到10億時(shí)，基本到了MySQL的極限，不分表分庫的話，業(yè)務(wù)難以持續(xù)。如果分表分庫的話自增ID很難保證唯一性，這時(shí)候必須棄用自增ID，采用其他算法。最后從業(yè)務(wù)的角度來講自增ID不可能用完，單表支撐不了那么大的數(shù)據(jù)量。
三. 自增ID如何優(yōu)化
當(dāng)數(shù)據(jù)量達(dá)到千萬時(shí)，數(shù)據(jù)庫的單表性能會(huì)開始下降。這時(shí)為了優(yōu)化性能，同時(shí)保證數(shù)據(jù)有唯一ID，又要考察另一個(gè)知識(shí)點(diǎn)了，這里不展開講，大家看下這篇文章。
最后
感謝有朋友監(jiān)督我更新文章，明天會(huì)再發(fā)一篇，分享我近期挖到的一個(gè)CSS漏洞，特別有意思，可以劫持很多網(wǎng)站的流量。
