?項目中使用了mysql數(shù)據(jù)庫，但數(shù)據(jù)量增長太快，不久到了百萬級，很快又到表到了千萬級，嘗試了各種優(yōu)化方式，最終效果仍難達到秒級響應，那么引發(fā)了我關(guān)于數(shù)據(jù)庫選型到一些思考。

1、mysql的單表性能瓶頸究竟是多少？

曾經(jīng)在中國互聯(lián)網(wǎng)技術(shù)圈廣為流傳著這么一個說法：MySQL 單表數(shù)據(jù)量大于 2000 萬行，性能會明顯下降。事實上，這個傳聞?chuàng)f最早起源于百度。具體情況大概是這樣的，當年的 DBA 測試 MySQL性能時發(fā)現(xiàn)，當單表的量在 2000 萬行量級的時候，SQL 操作的性能急劇下降，因此，結(jié)論由此而來。然后又據(jù)說百度的工程師流動到業(yè)界的其它公司，也帶去了這個信息，所以，就在業(yè)界流傳開這么一個說法。

再后來，阿里巴巴《Java 開發(fā)手冊》提出單表行數(shù)超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。對此，有阿里的黃金鐵律支撐，所以，很多人設計大數(shù)據(jù)存儲時，多會以此為標準，進行分表操作。

那么這個數(shù)值多少才合適呢？為什么不是 300 萬行，或者是 800 萬行，而是 500 萬行？也許你會說這個可能就是阿里的最佳實戰(zhàn)的數(shù)值吧？那么，問題又來了，這個數(shù)值是如何評估出來的呢？

事實上，這個數(shù)值和實際記錄的條數(shù)無關(guān)，而與 MySQL 的配置以及機器的硬件有關(guān)。因為，MySQL 為了提高性能，會將表的索引裝載到內(nèi)存中。InnoDB buffer size 足夠的情況下，其能完成全加載進內(nèi)存，查詢不會有問題。但是，當單表數(shù)據(jù)庫到達某個量級的上限時，導致內(nèi)存無法存儲其索引，使得之后的 SQL 查詢會產(chǎn)生磁盤 IO，從而導致性能下降。當然，這個還有具體的表結(jié)構(gòu)的設計有關(guān)，最終導致的問題都是內(nèi)存限制。這里，增加硬件配置，可能會帶來立竿見影的性能提升。

對此，阿里巴巴《Java 開發(fā)手冊》補充到：如果預計三年后的數(shù)據(jù)量根本達不到這個級別，請不要在創(chuàng)建表時就分庫分表。那么，回到一開始的問題，你覺得這個數(shù)值多少才合適呢？我的建議是，根據(jù)自身的機器的情況綜合評估，如果心里沒有標準，那么暫時以 500 萬行作為一個統(tǒng)一的標準，相對而言算是一個比較折中的數(shù)值。?

? ?上面這段經(jīng)驗之談?chuàng)褡曰ヂ?lián)網(wǎng)，但是我自己試了一下在innodb的情況下，mysql單表在800w數(shù)據(jù)的情況下count需要10s+，這肯定是一個不能接受的數(shù)字，那用MyISAM引擎呢，count會快很多，但可惜的是對于數(shù)據(jù)完整性以及事務的支持不如人意。

MyISAM速度可能超快，占用存儲空間也小，但是程序要求事務支持，故InnoDB是必須的，故該方案無法執(zhí)行，放棄！

那么分區(qū)分表呢？關(guān)于優(yōu)化方案建議看看下面的文章，或者我之前的文章也有很多描述

https://www.jianshu.com/p/e7b4b5ee8031

我最終選擇此文中的方案三，使用pgsql來代替mysql，百萬級的數(shù)據(jù)count，pgsql只需要0.1s。

那么pgsql對比mysql來講有哪些優(yōu)勢呢？

原博文：https://www.enterprisedb.com/blog/postgresql-vs-mysql-360-degree-comparison-syntax-performance-scalability-and-features

中文版：http://blog.itpub.net/31493717/viewspace-2673939/

未完待續(xù)。。。

?

總結(jié)

以上是生活随笔為你收集整理的mysql百万级性能瓶颈-数据库选型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。