不能?上來就說分庫分表！
MySQL數(shù)據(jù)庫性能優(yōu)化思路【面試題】
根據(jù)實(shí)際情況分析，兩個(gè)角度思考：不分庫分表、分庫分表
不分庫分表
軟優(yōu)化
- 數(shù)據(jù)庫參數(shù)調(diào)優(yōu)
- 分析慢查詢SQL語句，分析執(zhí)行計(jì)劃，進(jìn)行sql改寫和程序改寫
- 優(yōu)化數(shù)據(jù)庫索引結(jié)構(gòu)
- 優(yōu)化數(shù)據(jù)表結(jié)構(gòu)優(yōu)化
- 引入NOSQL和程序架構(gòu)調(diào)整
硬優(yōu)化
提升系統(tǒng)硬件（更快的IO、更多的內(nèi)存）：帶寬、CPU、硬盤
分庫分表
- 根據(jù)業(yè)務(wù)情況而定，選擇合適的分庫分表策略（沒有通用的策略）
外賣、物流、電商領(lǐng)域 - 先看只分表是否滿?業(yè)務(wù)的需求和未來增長
數(shù)據(jù)庫分表能夠解決單表數(shù)據(jù)量很大時(shí)，數(shù)據(jù)查詢的效率問題
無法給數(shù)據(jù)庫的并發(fā)操作帶來效率上的提高，分表的實(shí)質(zhì)還是在?個(gè)數(shù)據(jù)庫上進(jìn)行的操作，受數(shù)據(jù)庫IO性能的限制 - 如果單分表滿足不了需求，再分庫分表?起
結(jié)論
在數(shù)據(jù)量及訪問壓力不是特別大的情況，首先考慮緩存、讀寫分離、索引技術(shù)等方案
如果數(shù)據(jù)量極?，且業(yè)務(wù)持續(xù)增長快，再考慮分庫分表方案
分庫分表能解決的問題
解決數(shù)據(jù)庫本身瓶頸
連接數(shù)
連接數(shù)過多時(shí)，就會出現(xiàn)‘too many connections’的錯(cuò)誤，訪問量太大或者數(shù)據(jù)庫設(shè)置的最大連接數(shù)太小的原因
Mysql默認(rèn)的最大連接數(shù)為100可以修改，?mysql服務(wù)允許的最?連接數(shù)為16384
數(shù)據(jù)庫分表可以解決單表海量數(shù)據(jù)的查詢性能問題
數(shù)據(jù)庫分庫可以解決單臺數(shù)據(jù)庫的并發(fā)訪問壓力問題
解決系統(tǒng)本身IO、CPU瓶頸
- 磁盤讀寫IO瓶頸，熱點(diǎn)數(shù)據(jù)太多，盡管使用了數(shù)據(jù)庫本身緩存，但是依舊有?量IO，導(dǎo)致sql執(zhí)行速度慢
- 網(wǎng)絡(luò)IO瓶頸，請求的數(shù)據(jù)太多，數(shù)據(jù)傳輸大，網(wǎng)絡(luò)帶寬不夠，鏈路響應(yīng)時(shí)間變長
- CPU瓶頸，尤其在基礎(chǔ)數(shù)據(jù)量大單機(jī)復(fù)雜SQL計(jì)算，SQL語句執(zhí)行占用CPU使用率高，也有掃描行數(shù)大、鎖沖突、鎖等待等原因
可以通過 show processlist、show full processlist，發(fā)現(xiàn) CPU 使用率比較高的SQL
常見的對于查詢時(shí)間長，State 列值是 Sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，Using filesort 等都是可能有性能問題SQL，清楚相關(guān)影響問題的情況可以kill掉
也存在執(zhí)行時(shí)間短，但是CPU占用率?的SQL，通過上面命令查詢不到，這個(gè)時(shí)候最好通過執(zhí)行計(jì)劃分析explain進(jìn)行分析
分庫分表帶來的問題
問題? 跨節(jié)點(diǎn)數(shù)據(jù)庫Join關(guān)聯(lián)查詢
數(shù)據(jù)庫切分前，多表關(guān)聯(lián)查詢，可以通過sql join進(jìn)行實(shí)現(xiàn)分庫分表后，數(shù)據(jù)可能分布在不同的節(jié)點(diǎn)上，sql join帶來的問題就?較麻煩
問題二 分庫操作帶來的分布式事務(wù)問題
操作內(nèi)容同時(shí)分布在不同庫中，不可避免會帶來跨庫事務(wù)問題，即分布式事務(wù)
問題三 執(zhí)行的SQL排序、翻頁、函數(shù)計(jì)算問題
分庫后，數(shù)據(jù)分布再不同的節(jié)點(diǎn)上， 跨節(jié)點(diǎn)多庫進(jìn)行查詢時(shí)，會出現(xiàn)limit分頁、order by排序等問題
而且當(dāng)排序字段非分片字段時(shí)，更加復(fù)雜了，要在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序（也會帶來更多的CPU/IO資
源損耗）
問題四 數(shù)據(jù)庫全局主鍵重復(fù)問題
常規(guī)表的id是使用自增id進(jìn)行實(shí)現(xiàn)，分庫分表后，由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫中，如果用自增id，則會出現(xiàn)沖突問題
問題五 容量規(guī)劃,分庫分表后二次擴(kuò)容問題
業(yè)務(wù)發(fā)展快，初次分庫分表后，滿足不了數(shù)據(jù)存儲，導(dǎo)致需要多次擴(kuò)容文章來源：http://www.zghlxwxcb.cn/news/detail-418469.html
問題六 分庫分表技術(shù)選型問題
市場分庫分表中間件相對較多，框架各有各的優(yōu)勢與短板，應(yīng)該如何選擇文章來源地址http://www.zghlxwxcb.cn/news/detail-418469.html
到了這里，關(guān)于掌握MySQL分庫分表（一）數(shù)據(jù)庫性能優(yōu)化思路、分庫分表優(yōu)缺點(diǎn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
