問(wèn)題:MySQL單表最大記錄數(shù)不能超過(guò)多少?
以前沒(méi)有想過(guò)MySQL數(shù)據(jù)庫(kù)的單表最大行數(shù),直到最近interview時(shí)被問(wèn)到C語(yǔ)言中int類(lèi)型的最大值是多少時(shí)才想到Mysql單表最大行數(shù)的問(wèn)題。
一開(kāi)始被問(wèn)到C語(yǔ)言中int類(lèi)型的最大值有點(diǎn)懵逼,一般這種問(wèn)題都是在校招時(shí)候會(huì)被問(wèn)到,對(duì)于工作多年的人不會(huì)問(wèn)這個(gè)問(wèn)題。被問(wèn)到這個(gè)問(wèn)題的時(shí)候,大腦中思考的不是int類(lèi)型最大值到底是多少?而是為什么這個(gè)問(wèn)題很經(jīng)典,經(jīng)常被問(wèn),了解這個(gè)東西能用到什么地方呢?于是很快想到了MySql單表的最大記錄數(shù)是多少,因?yàn)楸淼膇d一般是自增長(zhǎng)的int類(lèi)型。
MySQL單表最大記錄數(shù)超過(guò)多少時(shí)性能會(huì)嚴(yán)重下降?
曾經(jīng)在中國(guó)互聯(lián)網(wǎng)技術(shù)圈廣為流傳著這么一個(gè)說(shuō)法:MySQL 單表數(shù)據(jù)量大于 2000 萬(wàn)行,性能會(huì)明顯下降。事實(shí)上,這個(gè)傳聞?chuàng)f(shuō)最早起源于百度。具體情況大概是這樣的,當(dāng)年的 DBA 測(cè)試 MySQL性能時(shí)發(fā)現(xiàn),當(dāng)單表的量在 2000 萬(wàn)行量級(jí)的時(shí)候,SQL 操作的性能急劇下降,因此,結(jié)論由此而來(lái)。然后又據(jù)說(shuō)百度的工程師流動(dòng)到業(yè)界的其它公司,也帶去了這個(gè)信息,所以,就在業(yè)界流傳開(kāi)這么一個(gè)說(shuō)法。
再后來(lái),阿里巴巴《JAVA 開(kāi)發(fā)手冊(cè)》提出單表行數(shù)超過(guò) 500 萬(wàn)行或者單表容量超過(guò) 2GB,才推薦進(jìn)行分庫(kù)分表。對(duì)此,有阿里的黃金鐵律支撐,所以,很多人設(shè)計(jì)大數(shù)據(jù)存儲(chǔ)時(shí),多會(huì)以此為標(biāo)準(zhǔn),進(jìn)行分表操作。
那么,你覺(jué)得這個(gè)數(shù)值多少才合適呢?為什么不是 300 萬(wàn)行,或者是 800 萬(wàn)行,而是 500 萬(wàn)行?也許你會(huì)說(shuō)這個(gè)可能就是阿里的最佳實(shí)戰(zhàn)的數(shù)值吧?那么,問(wèn)題又來(lái)了,這個(gè)數(shù)值是如何評(píng)估出來(lái)的呢?稍等片刻,請(qǐng)你小小思考一會(huì)兒。
事實(shí)上,這個(gè)數(shù)值和實(shí)際記錄的條數(shù)無(wú)關(guān),而與 MySQL 的配置以及機(jī)器的硬件有關(guān)。因?yàn)椋琈ySQL 為了提高性能,會(huì)將表的索引裝載到內(nèi)存中。InnoDB buffer size 足夠的情況下,其能完成全加載進(jìn)內(nèi)存,查詢不會(huì)有問(wèn)題。但是,當(dāng)單表數(shù)據(jù)庫(kù)到達(dá)某個(gè)量級(jí)的上限時(shí),導(dǎo)致內(nèi)存無(wú)法存儲(chǔ)其索引,使得之后的 SQL 查詢會(huì)產(chǎn)生磁盤(pán) IO,從而導(dǎo)致性能下降。當(dāng)然,這個(gè)還有具體的表結(jié)構(gòu)的設(shè)計(jì)有關(guān),最終導(dǎo)致的問(wèn)題都是內(nèi)存限制。這里,增加硬件配置,可能會(huì)帶來(lái)立竿見(jiàn)影的性能提升哈。
那么,我對(duì)于分庫(kù)分表的觀點(diǎn)是,需要結(jié)合實(shí)際需求,不宜過(guò)度設(shè)計(jì),在項(xiàng)目一開(kāi)始不采用分庫(kù)與分表設(shè)計(jì),而是隨著業(yè)務(wù)的增長(zhǎng),在無(wú)法繼續(xù)優(yōu)化的情況下,再考慮分庫(kù)與分表提高系統(tǒng)的性能。
對(duì)此,阿里巴巴《Java 開(kāi)發(fā)手冊(cè)》補(bǔ)充到:如果預(yù)計(jì)三年后的數(shù)據(jù)量根本達(dá)不到這個(gè)級(jí)別,請(qǐng)不要在創(chuàng)建表時(shí)就分庫(kù)分表。那么,回到一開(kāi)始的問(wèn)題,你覺(jué)得這個(gè)數(shù)值多少才合適呢?我的建議是,根據(jù)自身的機(jī)器的情況綜合評(píng)估,如果心里沒(méi)有標(biāo)準(zhǔn),那么暫時(shí)以 500 萬(wàn)行作為一個(gè)統(tǒng)一的標(biāo)準(zhǔn),相對(duì)而言算是一個(gè)比較折中的數(shù)值。
mysql bigint auto_increment 自增長(zhǎng)值的最大數(shù)量
bigint
有符號(hào)值:-9223372036854775808 到9223373036854775807(- 2 ^ 63 到 2 ^ 63-1) 無(wú)符號(hào)值:0到18446744073709551615(0到2^64 – 1)
創(chuàng)建表時(shí) 自增長(zhǎng)字段 選擇無(wú)符號(hào)bigint,那么自增長(zhǎng)最大值是 18446744073709551615
一秒增加的記錄條數(shù) 大約多少年后才會(huì)用完
作者:codegoogle
原文鏈接:
https://juejin.cn/post/6955105392640655368






