優(yōu)化思路

作為架構(gòu)師或者開(kāi)發(fā)人員,說(shuō)到數(shù)據(jù)庫(kù)性能優(yōu)化,你的思路是什么樣的?
或者具體一點(diǎn),如果在面試的時(shí)候遇到這個(gè)問(wèn)題:你會(huì)從哪些維度來(lái)優(yōu)化數(shù)據(jù)庫(kù),你會(huì)怎么回答?
我們?cè)诘谝还?jié)課開(kāi)始的時(shí)候講了,這四節(jié)課的目標(biāo)是為了讓大家建立數(shù)據(jù)庫(kù)的知識(shí)體系,和正確的調(diào)優(yōu)的思路
我們說(shuō)到性能調(diào)優(yōu),大部分時(shí)候想要實(shí)現(xiàn)的目標(biāo)是讓我們的查詢更快.一個(gè)查詢的動(dòng)作又是由很多個(gè)環(huán)節(jié)組成的,每個(gè)環(huán)節(jié)都會(huì)消耗時(shí)間,我們?cè)诘谝还?jié)課講 SQL 語(yǔ)句的執(zhí)行流程的時(shí)候已經(jīng)分析過(guò)了
我們要減少查詢所消耗的時(shí)間,就要從每一個(gè)環(huán)節(jié)入手.

連接——配置優(yōu)化

第一個(gè)環(huán)節(jié)是客戶端連接到服務(wù)端,連接這一塊有可能會(huì)出現(xiàn)什么樣的性能問(wèn)題?有可能是服務(wù)端連接數(shù)不夠?qū)е聭?yīng)用程序獲取不到連接.比如報(bào)了一個(gè) Mysql:error1040:Toomanyconnections 的錯(cuò)誤
我們可以從兩個(gè)方面來(lái)解決連接數(shù)不夠的問(wèn)題:

• 從服務(wù)端來(lái)說(shuō),我們可以增加服務(wù)端的可用連接數(shù),如果有多個(gè)應(yīng)用或者很多請(qǐng)求同時(shí)訪問(wèn)數(shù)據(jù)庫(kù),連接數(shù)不夠的時(shí)候,我們可以:

*修改配置參數(shù)增加可用連接數(shù),修改 max_connections 的大小:

show variables like 'max_connections'; -- 修改最大連接數(shù)枢劝，當(dāng)有多個(gè)應(yīng)用連接的時(shí)候

*或者,或者及時(shí)釋放不活動(dòng)的連接.交互式和非交互式的客戶端的默認(rèn)超時(shí)時(shí)間都是28800秒,8小時(shí),我們可以把這個(gè)值調(diào)小

show global variables like 'wait_timeout'; --及時(shí)釋放不活動(dòng)的連接，注意不要釋放連接池還在使用的連接

• 從客戶端來(lái)說(shuō),可以減少?gòu)姆?wù)端獲取的連接數(shù),如果我們想要不是每一次執(zhí)行 SQL 都創(chuàng)建一個(gè)新的連接,應(yīng)該怎么做?
  這個(gè)時(shí)候我們可以引入連接池,實(shí)現(xiàn)連接的重用
  我們可以在哪些層面使用連接池?ORM 層面(MyBatis 自帶了一個(gè)連接池)；或者使用專用的連接池工具(阿里的 Druid,SpringBoot2.x 版本默認(rèn)的連接池 Hikari,老牌的 DBCP 和 C3P0)
  當(dāng)客戶端改成從連接池獲取連接之后,連接池的大小應(yīng)該怎么設(shè)置呢?大家可能會(huì)有一個(gè)誤解,覺(jué)得連接池的最大連接數(shù)越大越好,這樣在高并發(fā)的情況下客戶端可以獲取的連接數(shù)更多,不需要排隊(duì)
  實(shí)際情況并不是這樣.連接池并不是越大越好,只要維護(hù)一定數(shù)量大小的連接池,其他的客戶端排隊(duì)等待獲取連接就可以了.有的時(shí)候連接池越大,效率反而越低
  Druid 的默認(rèn)最大連接池大小是 8.Hikari 的默認(rèn)最大連接池大小是 10
  為什么默認(rèn)值都是這么小呢?
  在 Hikari 的 github 文檔中,給出了一個(gè) PostgreSQL 數(shù)據(jù)庫(kù)建議的設(shè)置連接池大小的公式:
  https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
  它的建議是機(jī)器核數(shù)乘以2加1.也就是說(shuō),4核的機(jī)器,連接池維護(hù)9個(gè)連接就夠了.這個(gè)公式從一定程度上來(lái)說(shuō)對(duì)其他數(shù)據(jù)庫(kù)也是適用的.這里面還有一個(gè)減少連接池大小實(shí)現(xiàn)提升并發(fā)度和吞吐量的案例

為什么有的情況下,減少連接數(shù)反而會(huì)提升吞吐量呢?為什么建議設(shè)置的連接池大小要跟 CPU 的核數(shù)相關(guān)呢?
每一個(gè)連接,服務(wù)端都需要?jiǎng)?chuàng)建一個(gè)線程去處理它.連接數(shù)越多,服務(wù)端創(chuàng)建的線程數(shù)就會(huì)越多
問(wèn)題:CPU 是怎么同時(shí)執(zhí)行遠(yuǎn)遠(yuǎn)超過(guò)它的核數(shù)大小的任務(wù)的?時(shí)間片.上下文切換
而 CPU 的核數(shù)是有限的,頻繁的上下文切換會(huì)造成比較大的性能開(kāi)銷
我們這里說(shuō)到了從數(shù)據(jù)庫(kù)配置的層面去優(yōu)化數(shù)據(jù)庫(kù).不管是數(shù)據(jù)庫(kù)本身的配置,還是安裝這個(gè)數(shù)據(jù)庫(kù)服務(wù)的操作系統(tǒng)的配置,對(duì)于配置進(jìn)行優(yōu)化,最終的目標(biāo)都是為了更好地發(fā)揮硬件本身的性能,包括 CPU,內(nèi)存,磁盤,網(wǎng)絡(luò)
在不同的硬件環(huán)境下,操作系統(tǒng)和 MySQL 的參數(shù)的配置是不同的,沒(méi)有標(biāo)準(zhǔn)的配置
在我們這幾天的課程里面也接觸了很多的 MySQL 和 InnoDB 的配置參數(shù),包括各種開(kāi)關(guān)和數(shù)值的配置,大多數(shù)參數(shù)都提供了一個(gè)默認(rèn)值,比如默認(rèn)的 buffer_pool_size,默認(rèn)的頁(yè)大小,InnoDB 并發(fā)線程數(shù)等等
這些默認(rèn)配置可以滿足大部分情況的需求,除非有特殊的需求,在清楚參數(shù)的含義的情況下再去修改它.修改配置的工作一般由專業(yè)的 DBA 完成

至于硬件本身的選擇,比如使用固態(tài)硬盤,搭建磁盤陣列,選擇特定的 CPU 型號(hào)這些,更不是我們開(kāi)發(fā)人員關(guān)注的重點(diǎn),這個(gè)我們就不做過(guò)多的介紹了
如果想要了解一些特定的參數(shù)的含義,官網(wǎng)有一份系統(tǒng)的參數(shù)列表可以參考:
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
除了合理設(shè)置服務(wù)端的連接數(shù)和客戶端的連接池大小之外,我們還有哪些減少客戶端跟數(shù)據(jù)庫(kù)服務(wù)端的連接數(shù)的方案呢?
我們可以引入緩存

緩存——架構(gòu)優(yōu)化

緩存

在應(yīng)用系統(tǒng)的并發(fā)數(shù)非常大的情況下,如果沒(méi)有緩存,會(huì)造成兩個(gè)問(wèn)題:一方面是會(huì)給數(shù)據(jù)庫(kù)帶來(lái)很大的壓力.另一方面,從應(yīng)用的層面來(lái)說(shuō),操作數(shù)據(jù)的速度也會(huì)受到影響
我們可以用第三方的緩存服務(wù)來(lái)解決這個(gè)問(wèn)題,例如 Redis

運(yùn)行獨(dú)立的緩存服務(wù),屬于架構(gòu)層面的優(yōu)化
為了減少單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的讀寫(xiě)壓力,在架構(gòu)層面我們還可以做其他哪些優(yōu)化措施?

主從復(fù)制

如果單臺(tái)數(shù)據(jù)庫(kù)服務(wù)滿足不了訪問(wèn)需求,那我們可以做數(shù)據(jù)庫(kù)的集群方案
集群的話必然會(huì)面臨一個(gè)問(wèn)題,就是不同的節(jié)點(diǎn)之間數(shù)據(jù)一致性的問(wèn)題.如果同時(shí)讀寫(xiě)多臺(tái)數(shù)據(jù)庫(kù)節(jié)點(diǎn),怎么讓所有的節(jié)點(diǎn)數(shù)據(jù)保持一致?
這個(gè)時(shí)候我們需要用到復(fù)制技術(shù)(replication),被復(fù)制的節(jié)點(diǎn)稱為 master,復(fù)制的節(jié)點(diǎn)稱為 slave.slave 本身也可以作為其他節(jié)點(diǎn)的數(shù)據(jù)來(lái)源,這個(gè)叫做級(jí)聯(lián)復(fù)制

主從復(fù)制是怎么實(shí)現(xiàn)的呢?更新語(yǔ)句會(huì)記錄 binlog,它是一種邏輯日志
有了這個(gè) binlog,從服務(wù)器會(huì)獲取主服務(wù)器的 binlog 文件,然后解析里面的 SQL 語(yǔ)句,在從服務(wù)器上面執(zhí)行一遍,保持主從的數(shù)據(jù)一致
這里面涉及到三個(gè)線程,連接到 master 獲取 binlog,并且解析 binlog 寫(xiě)入中繼日志,這個(gè)線程叫做 I/O 線程
Master 節(jié)點(diǎn)上有一個(gè) logdump 線程,是用來(lái)發(fā)送 binlog 給 slave 的
從庫(kù)的 SQL 線程,是用來(lái)讀取 relaylog,把數(shù)據(jù)寫(xiě)入到數(shù)據(jù)庫(kù)的

做了主從復(fù)制的方案之后,我們只把數(shù)據(jù)寫(xiě)入 master 節(jié)點(diǎn),而讀的請(qǐng)求可以分擔(dān)到 slave 節(jié)點(diǎn).我們把這種方案叫做讀寫(xiě)分離

讀寫(xiě)分離可以一定程度低減輕數(shù)據(jù)庫(kù)服務(wù)器的訪問(wèn)壓力,但是需要特別注意主從數(shù)據(jù)一致性的問(wèn)題.如果我們?cè)?master 寫(xiě)入了,馬上到 slave 查詢,而這個(gè)時(shí)候 slave 的數(shù)據(jù)還沒(méi)有同步過(guò)來(lái),怎么辦?
所以,基于主從復(fù)制的原理,我們需要弄明白,主從復(fù)制到底慢在哪里

單線程

在早期的 MySQL 中,slave 的 SQL 線程是單線程.master 可以支持 SQL 語(yǔ)句的并行執(zhí)行,配置了多少的最大連接數(shù)就是最多同時(shí)多少個(gè) SQL 并行執(zhí)行
而 slave 的 SQL 卻只能單線程排隊(duì)執(zhí)行,在主庫(kù)并發(fā)量很大的情況下,同步數(shù)據(jù)肯定會(huì)出現(xiàn)延遲
為什么從庫(kù)上的 SQLThread 不能并行執(zhí)行呢?舉個(gè)例子,主庫(kù)執(zhí)行了多條 SQL 語(yǔ)句,首先用戶發(fā)表了一條評(píng)論,然后修改了內(nèi)容,最后把這條評(píng)論刪除了.這三條語(yǔ)句在從庫(kù)上的執(zhí)行順序肯定是不能顛倒的

insert into user_comments (10000009,'nice');
update user_comments set content ='very good' where id =10000009;
delete from user_comments where id =10000009;

怎么解決這個(gè)問(wèn)題呢?怎么減少主從復(fù)制的延遲?

異步與全同步

首先我們需要知道,在主從復(fù)制的過(guò)程中,MySQL 默認(rèn)是異步復(fù)制的.也就是說(shuō),對(duì)于主節(jié)點(diǎn)來(lái)說(shuō),寫(xiě)入 binlog,事務(wù)結(jié)束,就返回給客戶端了.對(duì)于 slave 來(lái)說(shuō),接收到 binlog,就完事兒了,master 不關(guān)心 slave 的數(shù)據(jù)有沒(méi)有寫(xiě)入成功

如果要減少延遲,是不是可以等待全部從庫(kù)的事務(wù)執(zhí)行完畢,才返回給客戶端呢?這樣的方式叫做全同步復(fù)制.從庫(kù)寫(xiě)完數(shù)據(jù),主庫(kù)才返會(huì)給客戶端

這種方式雖然可以保證在讀之前,數(shù)據(jù)已經(jīng)同步成功了,但是帶來(lái)的副作用大家應(yīng)該能想到,事務(wù)執(zhí)行的時(shí)間會(huì)變長(zhǎng),它會(huì)導(dǎo)致 master 節(jié)點(diǎn)性能下降
有沒(méi)有更好的辦法呢?既減少 slave 寫(xiě)入的延遲,又不會(huì)明顯增加 master 返回給客戶端的時(shí)間

半同步復(fù)制

介于異步復(fù)制和全同步復(fù)制之間,還有一種半同步復(fù)制的方式
半同步復(fù)制是什么樣的呢?
主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端,而是等待至少一個(gè)從庫(kù)接收到 binlog 并寫(xiě)到 relaylog 中才返回給客戶端.master 不會(huì)等待很長(zhǎng)的時(shí)間,但是返回給客戶端的時(shí)候,數(shù)據(jù)就即將寫(xiě)入成功了,因?yàn)樗皇Ｗ詈笠徊搅?就是讀取 relaylog,寫(xiě)入從庫(kù)

如果我們要在數(shù)據(jù)庫(kù)里面用半同步復(fù)制,必須安裝一個(gè)插件,這個(gè)是谷歌的一位工程師貢獻(xiàn)的.這個(gè)插件在 mysql 的插件目錄下已經(jīng)有提供:

cd /usr/lib64/mysql/plugin/

主庫(kù)和從庫(kù)是不同的插件,安裝之后需要啟用:

-- 主庫(kù)執(zhí)行
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=1;
show variables like '%semi_sync%';

-- 從庫(kù)執(zhí)行
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
set global rpl_semi_sync_slave_enabled=1;
show global variables like '%semi%';

相對(duì)于異步復(fù)制,半同步復(fù)制提高了數(shù)據(jù)的安全性,同時(shí)它也造成了一定程度的延遲,它需要等待一個(gè) slave 寫(xiě)入中繼日志,這里多了一個(gè)網(wǎng)絡(luò)交互的過(guò)程,所以,半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用
這個(gè)是從主庫(kù)和從庫(kù)連接的角度,來(lái)保證 slave 數(shù)據(jù)的寫(xiě)入
另一個(gè)思路,如果要減少主從同步的延遲,減少 SQL 執(zhí)行造成的等待的時(shí)間,那有沒(méi)有辦法在從庫(kù)上,讓多個(gè) SQL 語(yǔ)句可以并行執(zhí)行,而不是排隊(duì)執(zhí)行呢?

多庫(kù)并行復(fù)制

怎么實(shí)現(xiàn)并行復(fù)制呢?設(shè)想一下,如果 3 條語(yǔ)句是在三個(gè)數(shù)據(jù)庫(kù)執(zhí)行,操作各自的數(shù)據(jù)庫(kù),是不是肯定不會(huì)產(chǎn)生并發(fā)的問(wèn)題呢?執(zhí)行的順序也沒(méi)有要求.當(dāng)然是,所以如果是操作三個(gè)數(shù)據(jù)庫(kù),這三個(gè)數(shù)據(jù)庫(kù)的從庫(kù)的 SQL 線程可以并發(fā)執(zhí)行.這是 MySQL5.6 版本里面支持的多庫(kù)并行復(fù)制

但是在大部分的情況下,我們都是單庫(kù)多表的情況,在一個(gè)數(shù)據(jù)庫(kù)里面怎么實(shí)現(xiàn)并行復(fù)制呢?或者說(shuō),我們知道,數(shù)據(jù)庫(kù)本身就是支持多個(gè)事務(wù)同時(shí)操作的；為什么這些事務(wù)在主庫(kù)上面可以并行執(zhí)行,卻不會(huì)出現(xiàn)問(wèn)題呢?
因?yàn)樗麄儽旧砭褪腔ハ嗖桓蓴_的,比如這些事務(wù)是操作不同的表,或者操作不同的行,不存在資源的競(jìng)爭(zhēng)和數(shù)據(jù)的干擾.那在主庫(kù)上并行執(zhí)行的事務(wù),在從庫(kù)上肯定也是可以并行執(zhí)行,是不是?比如在 master 上有三個(gè)事務(wù)同時(shí)分別操作三張表,這三個(gè)事務(wù)是不是在 slave 上面也可以并行執(zhí)行呢

異步復(fù)制之 GTID 復(fù)制

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html
所以,我們可以把那些在主庫(kù)上并行執(zhí)行的事務(wù),分為一個(gè)組,并且給他們編號(hào),這一個(gè)組的事務(wù)在從庫(kù)上面也可以并行執(zhí)行.這個(gè)編號(hào),我們把它叫做 GTID(GlobalTransactionIdentifiers),這種主從復(fù)制的方式,我們把它叫做基于 GTID 的復(fù)制

如果我們要使用 GTID 復(fù)制,我們可以通過(guò)修改配置參數(shù)打開(kāi)它,默認(rèn)是關(guān)閉的:

show global variables like 'gtid_mode';

無(wú)論是優(yōu)化 master 和 slave 的連接方式,還是讓從庫(kù)可以并行執(zhí)行 SQL,都是從數(shù)據(jù)庫(kù)的層面去解決主從復(fù)制延遲的問(wèn)題
除了數(shù)據(jù)庫(kù)本身的層面之外,在應(yīng)用層面,我們也有一些減少主從同步延遲的方法
我們?cè)谧隽酥鲝膹?fù)制之后,如果單個(gè) master 節(jié)點(diǎn)或者單張表存儲(chǔ)的數(shù)據(jù)過(guò)大的時(shí)候,比如一張表有上億的數(shù)據(jù),單表的查詢性能還是會(huì)下降,我們要進(jìn)一步對(duì)單臺(tái)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的數(shù)據(jù)分型拆分,這個(gè)就是分庫(kù)分表

分庫(kù)分表

垂直分庫(kù),減少并發(fā)壓力.水平分表,解決存儲(chǔ)瓶頸
垂直分庫(kù)的做法,把一個(gè)數(shù)據(jù)庫(kù)按照業(yè)務(wù)拆分成不同的數(shù)據(jù)庫(kù):

水平分庫(kù)分表的做法,把單張表的數(shù)據(jù)按照一定的規(guī)則分布到多個(gè)數(shù)據(jù)庫(kù)

通過(guò)主從或者分庫(kù)分表可以減少單個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的訪問(wèn)壓力和存儲(chǔ)壓力,達(dá)到提升數(shù)據(jù)庫(kù)性能的目的,但是如果 master 節(jié)點(diǎn)掛了,怎么辦?
所以,高可用(HighAvailable)也是高性能的基礎(chǔ)

高可用方案

https://dev.mysql.com/doc/mysql-ha-scalability/en/ha-overview.html

主從復(fù)制

傳統(tǒng)的 HAProxy+keepalived 的方案,基于主從復(fù)制

NDB Cluster

https://dev.mysql.com/doc/mysql-cluster-excerpt/5.7/en/mysql-cluster-overview.html
基于 NDB 集群存儲(chǔ)引擎的 MySQLCluster

Galera

https://galeracluster.com/
一種多主同步復(fù)制的集群方案

MHA/MMM

https://tech.meituan.com/2017/06/29/database-availability-architecture.html
MMM(Master-MasterreplicationmanagerforMySQL),一種多主的高可用架構(gòu),是一個(gè)日本人開(kāi)發(fā)的,像美團(tuán)這樣的公司早期也有大量使用 MMM
MHA(MySQLMasterHighAvailable)
MMM 和 MHA 都是對(duì)外提供一個(gè)虛擬 IP,并且監(jiān)控主節(jié)點(diǎn)和從節(jié)點(diǎn),當(dāng)主節(jié)點(diǎn)發(fā)生故障的時(shí)候,需要把一個(gè)從節(jié)點(diǎn)提升為主節(jié)點(diǎn),并且把從節(jié)點(diǎn)里面比主節(jié)點(diǎn)缺少的數(shù)據(jù)補(bǔ)上,把 VIP 指向新的主節(jié)點(diǎn)

MGR

https://dev.mysql.com/doc/refman/5.7/en/group-replication.html
https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html

MySQL5.7.17 版本推出的 InnoDBCluster,也叫 MySQLGroupReplicatioin(MGR),這個(gè)套件里面包括了 mysqlshell 和 mysql-route

總結(jié)一下:
高可用 HA 方案需要解決的問(wèn)題都是當(dāng)一個(gè) master 節(jié)點(diǎn)宕機(jī)的時(shí)候,如何提升一個(gè)數(shù)據(jù)最新的 slave 成為 master.如果同時(shí)運(yùn)行多個(gè) master,又必須要解決 master 之間數(shù)據(jù)復(fù)制,以及對(duì)于客戶端來(lái)說(shuō)連接路由的問(wèn)題
不同的方案,實(shí)施難度不一樣,運(yùn)維管理的成本也不一樣
以上是架構(gòu)層面的優(yōu)化,可以用緩存,主從,分庫(kù)分表

第三個(gè)環(huán)節(jié):解析器,詞法和語(yǔ)法分析,主要保證語(yǔ)句的正確性,語(yǔ)句不出錯(cuò)就沒(méi)問(wèn)題.由 Sever 自己處理,跳過(guò)
第四步:優(yōu)化器

優(yōu)化器--SQL 語(yǔ)句分析與優(yōu)化

優(yōu)化器就是對(duì)我們的 SQL 語(yǔ)句進(jìn)行分析,生成執(zhí)行計(jì)劃
問(wèn)題:在我們做項(xiàng)目的時(shí)候,有時(shí)會(huì)收到 DBA 的郵件,里面列出了我們項(xiàng)目上幾個(gè)耗時(shí)比較長(zhǎng)的查詢語(yǔ)句,讓我們?nèi)?yōu)化,這些語(yǔ)句是從哪里來(lái)的呢?
我們的服務(wù)層每天執(zhí)行了這么多 SQL 語(yǔ)句,它怎么知道哪些 SQL 語(yǔ)句比較慢呢?
第一步,我們要把 SQL 執(zhí)行情況記錄下來(lái)

慢查詢?nèi)罩?slow query log

https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html

打開(kāi)慢日志開(kāi)關(guān)

因?yàn)殚_(kāi)啟慢查詢?nèi)罩臼怯写鷥r(jià)的(跟 binlog,optimizer-trace 一樣),所以它默認(rèn)是關(guān)閉的:

show variables like 'slow_query%';

除了這個(gè)開(kāi)關(guān),還有一個(gè)參數(shù),控制執(zhí)行超過(guò)多長(zhǎng)時(shí)間的 SQL 才記錄到慢日志,默認(rèn)是 10 秒

show variables like '%slow_query%';

可以直接動(dòng)態(tài)修改參數(shù)(重啟后失效)

set @@global.slow_query_log=1; -- 1 開(kāi)啟,0 關(guān)閉,重啟后失效
set @@global.long_query_time=3; -- mysql 默認(rèn)的慢查詢時(shí)間是 10 秒,另開(kāi)一個(gè)窗口后才會(huì)查到最新值
show variables like '%long_query%';
show variables like '%slow_query%';

或者修改配置文件 my.cnf
以下配置定義了慢查詢?nèi)罩镜拈_(kāi)關(guān),慢查詢的時(shí)間,日志文件的存放路徑

slow_query_log = ON
long_query_time=2
slow_query_log_file =/var/lib/mysql/localhost-slow.log

模擬慢查詢:

select sleep(10);

查詢 user_innodb 表的 500 萬(wàn)數(shù)據(jù)(檢查是不是沒(méi)有索引)

SELECT * FROM `user_innodb` where phone = '136';

慢日志分析

日志內(nèi)容

show global status like 'slow_queries'; -- 查看有多少慢查詢
show variables like '%slow_query%'; -- 獲取慢日志目錄

cat /var/lib/mysql/ localhost-slow.log

有了慢查詢?nèi)罩?怎么去分析統(tǒng)計(jì)呢?比如 SQL 語(yǔ)句的出現(xiàn)的慢查詢次數(shù)最多,平均每次執(zhí)行了多久?

mysqldumpslow

https://dev.mysql.com/doc/refman/5.7/en/mysqldumpslow.html
MySQL 提供了 mysqldumpslow 的工具,在 MySQL 的 bin 目錄下

mysqldumpslow --help

例如:查詢用時(shí)最多的 20 條慢 SQL:

mysqldumpslow -s t -t 20 -g 'select' /var/lib/mysql/localhost-slow.log

• Count 代表這個(gè) SQL 執(zhí)行了多少次
• Time 代表執(zhí)行的時(shí)間,括號(hào)里面是累計(jì)時(shí)間
• Lock 表示鎖定的時(shí)間,括號(hào)是累計(jì)
• Rows 表示返回的記錄數(shù),括號(hào)是累計(jì)

除了慢查詢?nèi)罩局?還有一個(gè) SHOWPROFILE 工具可以使用

SHOW PROFILE

https://dev.mysql.com/doc/refman/5.7/en/show-profile.html

SHOWPROFILE 是谷歌高級(jí)架構(gòu)師 JeremyCole 貢獻(xiàn)給 MySQL 社區(qū)的,可以查看 SQL 語(yǔ)句執(zhí)行的時(shí)候使用的資源,比如 CPU,IO 的消耗情況
在 SQL 中輸入 helpprofile 可以得到詳細(xì)的幫助信息

查看是否開(kāi)啟

select @@profiling;
set @@profiling=1;

查看 profile 統(tǒng)計(jì)

(命令最后帶一個(gè) s)

show profiles;

查看最后一個(gè) SQL 的執(zhí)行詳細(xì)信息,從中找出耗時(shí)較多的環(huán)節(jié)(沒(méi)有 s)

show profile;

6.2E-5,小數(shù)點(diǎn)左移 5 位,代表 0.000062 秒

也可以根據(jù) ID 查看執(zhí)行詳細(xì)信息,在后面帶上 forquery+ID

show profile for query 1;

除了慢日志和 showprofile,如果要分析出當(dāng)前數(shù)據(jù)庫(kù)中執(zhí)行的慢的 SQL,還可以通過(guò)查看運(yùn)行線程狀態(tài)和服務(wù)器運(yùn)行信息,存儲(chǔ)引擎信息來(lái)分析

其他系統(tǒng)命令

show processlist 運(yùn)行線程

https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html

show processlist;

這是很重要的一個(gè)命令,用于顯示用戶運(yùn)行線程.可以根據(jù) id 號(hào) kill 線程,也可以查表,效果一樣:

select * from information_schema.processlist;

show status 服務(wù)器運(yùn)行狀態(tài)

https://dev.mysql.com/doc/refman/5.7/en/show-status.html

SHOWSTATUS 用于查看 MySQL 服務(wù)器運(yùn)行狀態(tài)(重啟后會(huì)清空),有 session 和 global 兩種作用域,格式:參數(shù)-值
可以用 like 帶通配符過(guò)濾

SHOW GLOBAL STATUS LIKE 'com_select'; -- 查看 select 次數(shù)

show engine 存儲(chǔ)引擎運(yùn)行信息

https://dev.mysql.com/doc/refman/5.7/en/show-engine.html

showengine 用來(lái)顯示存儲(chǔ)引擎的當(dāng)前運(yùn)行信息,包括事務(wù)持有的表鎖,行鎖信息嘴纺；事務(wù)的鎖等待情況冗荸；線程信號(hào)量等待；文件 IO 請(qǐng)求愈涩；bufferpool 統(tǒng)計(jì)信息
例如:

show engine innodb status;

如果需要將監(jiān)控信息輸出到錯(cuò)誤信息 errorlog 中(15 秒鐘一次),可以開(kāi)啟輸出

show variables like 'innodb_status_output%';

-- 開(kāi)啟輸出：
SET GLOBAL innodb_status_output=ON;
SET GLOBAL innodb_status_output_locks=ON;

我們現(xiàn)在已經(jīng)知道了這么多分析服務(wù)器狀態(tài),存儲(chǔ)引擎狀態(tài),線程運(yùn)行信息的命令,如果讓你去寫(xiě)一個(gè)數(shù)據(jù)庫(kù)監(jiān)控系統(tǒng),你會(huì)怎么做?
其實(shí)很多開(kāi)源的慢查詢?nèi)罩颈O(jiān)控工具,他們的原理其實(shí)也都是讀取的系統(tǒng)的變量和狀態(tài)
現(xiàn)在我們已經(jīng)知道哪些 SQL 慢了,為什么慢呢?慢在哪里?
MySQL 提供了一個(gè)執(zhí)行計(jì)劃的工具(在架構(gòu)中我們有講到,優(yōu)化器最終生成的就是一個(gè)執(zhí)行計(jì)劃),其他數(shù)據(jù)庫(kù),例如 Oracle 也有類似的功能
通過(guò) EXPLAIN 我們可以模擬優(yōu)化器執(zhí)行 SQL 查詢語(yǔ)句的過(guò)程,來(lái)知道 MySQL 是怎么處理一條 SQL 語(yǔ)句的.通過(guò)這種方式我們可以分析語(yǔ)句或者表的性能瓶頸

explain 可以分析 update,delete,insert 么?
MySQL5.6.3 以前只能分析 SELECT;MySQL5.6.3 以后就可以分析 update,delete,insert 了

EXPLAIN 執(zhí)行計(jì)劃

官方鏈接:https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

我們先創(chuàng)建三張表.一張課程表,一張老師表,一張老師聯(lián)系方式表(沒(méi)有任何索引)

DROP TABLE IF EXISTS course;
CREATE TABLE `course` (
    `cid` int(3)DEFAULT NULL,
    `cname` varchar(20)DEFAULT NULL,
    `tid` int(3)DEFAULT NULL 23
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DROP TABLE IF EXISTS teacher;
CREATE TABLE `teacher` (
    `tid` int(3)DEFAULT NULL,
    `tname` varchar(20)DEFAULT NULL,
    `tcid` int(3)DEFAULT NULL
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DROP TABLE IF EXISTS teacher_contact;
CREATE TABLE `teacher_contact` (
    `tcid` int(3)DEFAULT NULL,
    `phone` varchar(200)DEFAULT NULL
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO `course` VALUES ('1', 'mysql', '1');
INSERT INTO `course` VALUES ('2', 'jvm', '1');
INSERT INTO `course` VALUES ('3', 'juc', '2');
INSERT INTO `course` VALUES ('4', 'spring', '3');
INSERT INTO `teacher` VALUES ('1', 'qingshan', '1');
INSERT INTO `teacher` VALUES ('2', 'jack', '2');
INSERT INTO `teacher` VALUES ('3', 'mic', '3');
INSERT INTO `teacher_contact` VALUES ('1', '13688888888');
INSERT INTO `teacher_contact` VALUES ('2', '18166669999');
INSERT INTO `teacher_contact` VALUES ('3', '17722225555');

explain 的結(jié)果有很多的字段,我們?cè)敿?xì)地分析一下.先確認(rèn)一下環(huán)境:

select version();
show variables like '%engine%';

id

id 是查詢序列編號(hào)

id 值不同

id 值不同的時(shí)候,先查詢 id 值大的(先大后小)

-- 查詢 mysql 課程的老師手機(jī)號(hào)
EXPLAIN SELECT tc.phone
FROM teacher_contact tc
WHERE tcid = (
    SELECT tcid FROM teacher t
    WHERE t.tid = (
        SELECT c.tid FROM course c
        WHERE c.cname = 'mysql'
    )
);

查詢順序:coursec——teachert——teacher_contacttc

先查課程表,再查老師表,最后查老師聯(lián)系方式表.子查詢只能以這種方式進(jìn)行,只有拿到內(nèi)層的結(jié)果之后才能進(jìn)行外層的查詢

id 值相同

-- 查詢課程 ID 為 2，或者聯(lián)系表 ID 為 3 的老師
EXPLAIN SELECT t.tname,c.cname,tc.phone
FROM teacher t, course c, teacher_contact tc
WHERE t.tid = c.tid AND t.tcid = tc.tcid AND (c.cid = 2 OR tc.tcid = 3);

id 值相同時(shí),表的查詢順序是從上往下順序執(zhí)行.例如這次查詢的 id 都是 1,查詢的順序是 teachert(3 條)——coursec(4 條)——teacher_contacttc(3 條)
teacher 表插入 3 條數(shù)據(jù)后:

INSERT INTO `teacher` VALUES (4, 'james', 4);
INSERT INTO `teacher` VALUES (5, 'tom', 5);
INSERT INTO `teacher` VALUES (6, 'seven', 6);
COMMIT;

-- （備份）恢復(fù)語(yǔ)句
DELETE FROM teacher where tid in (4,5,6);
COMMIT;

id 也都是 1,但是從上往下查詢順序變成了:teacher_contacttc(3 條)——teachert(6 條)——coursec(4 條)

為什么數(shù)據(jù)量不同的時(shí)候順序會(huì)發(fā)生變化呢?這個(gè)是由笛卡爾積決定的
舉例:假如有 a,b,c 三張表,分別有 2,3,4 條數(shù)據(jù),如果做三張表的聯(lián)合查詢,當(dāng)查詢順序是 a→b→c 的時(shí)候,它的笛卡爾積是:2*3*4=24.如果查詢順序是 c→b→a,它的笛卡爾積是 4*3*2=24
因?yàn)?MySQL 要把查詢的結(jié)果,包括中間結(jié)果和最終結(jié)果都保存到內(nèi)存,所以 MySQL 會(huì)優(yōu)先選擇中間結(jié)果數(shù)據(jù)量比較小的順序進(jìn)行查詢.所以最終聯(lián)表查詢的順序是 a→b→c.這個(gè)就是為什么 teacher 表插入數(shù)據(jù)以后查詢順序會(huì)發(fā)生變化
(小標(biāo)驅(qū)動(dòng)大表的思想)

既有相同也有不同

如果 ID 有相同也有不同,就是 ID 不同的先大后小,ID 相同的從上往下

select type 查詢類型

這里并沒(méi)有列舉全部(其它:DEPENDENTUNION,DEPENDENTSUBQUERY,MATERIALIZED,UNCACHEABLESUBQUERY,UNCACHEABLEUNION)
下面列舉了一些常見(jiàn)的查詢類型:

SIMPLE

簡(jiǎn)單查詢,不包含子查詢,不包含關(guān)聯(lián)查詢 union

EXPLAIN SELECT * FROM teacher;

再看一個(gè)包含子查詢的案例:

-- 查詢 mysql 課程的老師手機(jī)號(hào)
EXPLAIN SELECT tc.phone FROM teacher_contact tc
WHERE tcid = (
    SELECT tcid FROM teacher t
    WHERE t.tid = (
        SELECT c.tid FROM course c WHERE c.cname = 'mysql'
    )
);

PRIMARY

子查詢 SQL 語(yǔ)句中的主查詢,也就是最外面的那層查詢

SUBQUERY

子查詢中所有的內(nèi)層查詢都是 SUBQUERY 類型的

DERIVED

衍生查詢,表示在得到最終查詢結(jié)果之前會(huì)用到臨時(shí)表.例如:

-- 查詢 ID 為 1 或 2 的老師教授的課程
EXPLAIN SELECT cr.cname FROM (
    SELECT * FROM course WHERE tid = 1
    UNION SELECT * FROM course WHERE tid = 2
)cr;

對(duì)于關(guān)聯(lián)查詢,先執(zhí)行右邊的 table(UNION),再執(zhí)行左邊的 table,類型是 DERIVED

UNION

用到了 UNION 查詢.同上例

UNION RESULT

主要是顯示哪些表之間存在 UNION 查詢.<union2,3>代表 id=2 和 id=3 的查詢存在 UNION.同上例

type 連接類型

https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-join-types

所有的連接類型中,上面的最好,越往下越差
在常用的鏈接類型中:system>const>eq_ref>ref>range>index>all
這里并沒(méi)有列舉全部(其他:fulltext,ref_or_null,index_merger,unique_subquery,index_subquery)
以上訪問(wèn)類型除了 all,都能用到索引

const

主鍵索引或者唯一索引,只能查到一條數(shù)據(jù)的 SQL

DROP TABLE IF EXISTS single_data;
CREATE TABLE single_data(
id int(3)PRIMARY KEY,
content varchar(20)
);

insert into single_data values(1,'a');
EXPLAIN SELECT * FROM single_data a where id = 1;

system

system 是 const 的一種特例,只有一行滿足條件.例如:只有一條數(shù)據(jù)的系統(tǒng)表

EXPLAIN SELECT * FROM mysql.proxies_priv;

eq_ref

通常出現(xiàn)在多表的 join 查詢,表示對(duì)于前表的每一個(gè)結(jié)果,都只能匹配到后表的一行結(jié)果.一般是唯一性索引的查詢(UNIQUE 或 PRIMARYKEY)
eq_ref 是除 const 之外最好的訪問(wèn)類型
先刪除 teacher 表中多余的數(shù)據(jù),teacher_contact 有 3 條數(shù)據(jù),teacher 表有 3 條數(shù)據(jù)

DELETE FROM teacher where tid in (4,5,6);
commit;

-- 備份
INSERT INTO `teacher` VALUES (4, 'james', 4);
INSERT INTO `teacher` VALUES (5, 'tom', 5);
INSERT INTO `teacher` VALUES (6, 'seven', 6);

commit;

為 teacher_contact 表的 tcid(第一個(gè)字段)創(chuàng)建主鍵索引

-- ALTER TABLE teacher_contact DROP PRIMARY KEY;
ALTER TABLE teacher_contact ADD PRIMARY KEY(tcid);

為 teacher 表的 tcid(第三個(gè)字段)創(chuàng)建普通索引

-- ALTER TABLE teacher DROP INDEX idx_tcid;
ALTER TABLE teacher ADD INDEX idx_tcid (tcid);

執(zhí)行以下 SQL 語(yǔ)句:

select t.tcid from teacher t,teacher_contact tc where t.tcid = tc.tcid;

此時(shí)的執(zhí)行計(jì)劃(teacher_contact 表是 eq_ref):

小結(jié):
以上三種 system,const,eq_ref,都是可遇而不可求的,基本上很難優(yōu)化到這個(gè)狀態(tài)

ref

查詢用到了非唯一性索引,或者關(guān)聯(lián)操作只使用了索引的最左前綴
例如:使用 tcid 上的普通索引查詢:

explain SELECT * FROM teacher where tcid = 3;

range

索引范圍掃描
如果 where 后面是 betweenand 或<或>或>=或<=或 in 這些,type 類型就為 range
不走索引一定是全表掃描(ALL),所以先加上普通索引

-- ALTER TABLE teacher DROP INDEX idx_tid;
ALTER TABLE teacher ADD INDEX idx_tid (tid);

執(zhí)行范圍查詢(字段上有普通索引):

EXPLAIN SELECT * FROM teacher t WHERE t.tid <3;
-- 或
EXPLAIN SELECT * FROM teacher t WHERE tid BETWEEN 1 AND 2;

IN 查詢也是 range(字段有主鍵索引)

EXPLAIN SELECT * FROM teacher_contact t WHERE tcid in (1,2,3);

index

FullIndexScan,查詢?nèi)克饕械臄?shù)據(jù)(比不走索引要快)

EXPLAIN SELECT tid FROM teacher;

all

FullTableScan,如果沒(méi)有索引或者沒(méi)有用到索引,type 就是 ALL.代表全表掃描

NULL

不用訪問(wèn)表或者索引就能得到結(jié)果,例如:

EXPLAIN select 1 from dual where 1=1;

小結(jié):
一般來(lái)說(shuō),需要保證查詢至少達(dá)到 range 級(jí)別,最好能達(dá)到 ref
ALL(全表掃描)和 index(查詢?nèi)克饕?都是需要優(yōu)化的

possible_key,key

可能用到的索引和實(shí)際用到的索引.如果是 NULL 就代表沒(méi)有用到索引
possible_key 可以有一個(gè)或者多個(gè),可能用到索引不代表一定用到索引
反過(guò)來(lái),possible_key 為空,key 可能有值嗎?
表上創(chuàng)建聯(lián)合索引:

ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

執(zhí)行計(jì)劃(改成 selectname 也能用到索引):

explain select phone from user_innodb where phone='126';

結(jié)論:是有可能的(這里是覆蓋索引的情況)
如果通過(guò)分析發(fā)現(xiàn)沒(méi)有用到索引,就要檢查 SQL 或者創(chuàng)建索引

key_len

索引的長(zhǎng)度(使用的字節(jié)數(shù)).跟索引字段的類型,長(zhǎng)度有關(guān)

rows

MySQL 認(rèn)為掃描多少行才能返回請(qǐng)求的數(shù)據(jù),是一個(gè)預(yù)估值.一般來(lái)說(shuō)行數(shù)越少越好

filtered

這個(gè)字段表示存儲(chǔ)引擎返回的數(shù)據(jù)在 server 層過(guò)濾后,剩下多少滿足查詢的記錄數(shù)量的比例,它是一個(gè)百分比

ref

使用哪個(gè)列或者常數(shù)和索引一起從表中篩選數(shù)據(jù)

Extra

執(zhí)行計(jì)劃給出的額外的信息說(shuō)明

using index

用到了覆蓋索引,不需要回表

EXPLAIN SELECT tid FROM teacher;

using where

使用了 where 過(guò)濾,表示存儲(chǔ)引擎返回的記錄并不是所有的都滿足查詢條件,需要在 server 層進(jìn)行過(guò)濾(跟是否使用索引沒(méi)有關(guān)系)

EXPLAIN select * from user_innodb where phone ='13866667777';

Using index condition(索引條件下推)

索引下推,在第二節(jié)課中已經(jīng)講解過(guò)了
https://dev.mysql.com/doc/refman/5.7/en/index-condition-pushdown-optimization.html

using filesort

不能使用索引來(lái)排序,用到了額外的排序(跟磁盤或文件沒(méi)有關(guān)系).需要優(yōu)化(復(fù)合索引的前提)

ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

EXPLAIN select * from user_innodb where name ='青山' order by id;

(orderbyid 引起)

using temporary

用到了臨時(shí)表.例如(以下不是全部的情況):

• distinct 非索引列

EXPLAIN select DISTINCT(tid)from teacher t;

• groupby 非索引列

EXPLAIN select tname from teacher group by tname;

• 使用 join 的時(shí)候,group 任意列

EXPLAIN select t.tid from teacher t join course c on t.tid = c.tid group by t.tid;

需要優(yōu)化,例如創(chuàng)建復(fù)合索引

總結(jié)一下:
模擬優(yōu)化器執(zhí)行 SQL 查詢語(yǔ)句的過(guò)程,來(lái)知道 MySQL 是怎么處理一條 SQL 語(yǔ)句的.通過(guò)這種方式我們可以分析語(yǔ)句或者表的性能瓶頸
分析出問(wèn)題之后,就是對(duì) SQL 語(yǔ)句的具體優(yōu)化
比如怎么用到索引,怎么減少鎖的阻塞等待,在前面兩次課已經(jīng)講過(guò)

SQL 與索引優(yōu)化

當(dāng)我們的 SQL 語(yǔ)句比較復(fù)雜,有多個(gè)關(guān)聯(lián)和子查詢的時(shí)候,就要分析 SQL 語(yǔ)句有沒(méi)有改寫(xiě)的方法
舉個(gè)簡(jiǎn)單的例子,一模一樣的數(shù)據(jù):

-- 大偏移量的 limit
select * from user_innodb limit 900000,10;
-- 改成先過(guò)濾 ID加矛，再 limit
SELECT * FROM user_innodb WHERE id >= 900000 LIMIT 10;

對(duì)于具體的 SQL 語(yǔ)句的優(yōu)化,MySQL 官網(wǎng)也提供了很多建議,這個(gè)是我們?cè)诜治鼍唧w的 SQL 語(yǔ)句的時(shí)候需要注意的,也是大家在以后的工作里面要去慢慢地積累的(這里我們就不一一地分析了)

https://dev.mysql.com/doc/refman/5.7/en/optimization.html

存儲(chǔ)引擎

存儲(chǔ)引擎的選擇

為不同的業(yè)務(wù)表選擇不同的存儲(chǔ)引擎,例如:查詢插入操作多的業(yè)務(wù)表,用 MyISAM.臨時(shí)數(shù)據(jù)用 Memeroy.常規(guī)的并發(fā)大更新多的表用 InnoDB.

分區(qū)或者分表

分區(qū)不推薦
交易歷史表:在年底為下一年度建立12個(gè)分區(qū),每個(gè)月一個(gè)分區(qū)
渠道交易表:分成當(dāng)日表履婉；當(dāng)月表；歷史表,歷史表再做分區(qū)

字段定義

原則:使用可以正確存儲(chǔ)數(shù)據(jù)的最小數(shù)據(jù)類型
為每一列選擇合適的字段類型:

整數(shù)類型

INT 有 8 種類型,不同的類型的最大存儲(chǔ)范圍是不一樣的
性別?用 TINYINT,因?yàn)?ENUM 也是整型存儲(chǔ)

字符類型

變長(zhǎng)情況下,varchar 更節(jié)省空間,但是對(duì)于 varchar 字段,需要一個(gè)字節(jié)來(lái)記錄長(zhǎng)度
固定長(zhǎng)度的用 char,不要用 varchar

非空

非空字段盡量定義成 NOTNULL,提供默認(rèn)值,或者使用特殊值,空串代替 null
NULL 類型的存儲(chǔ),優(yōu)化,使用都會(huì)存在問(wèn)題

不要用外鍵,觸發(fā)器,視圖

降低了可讀性
影響數(shù)據(jù)庫(kù)性能,應(yīng)該把把計(jì)算的事情交給程序,數(shù)據(jù)庫(kù)專心做存儲(chǔ)
數(shù)據(jù)的完整性應(yīng)該在程序中檢查

大文件存儲(chǔ)

不要用數(shù)據(jù)庫(kù)存儲(chǔ)圖片(比如 base64 編碼)或者大文件
把文件放在 NAS 上,數(shù)據(jù)庫(kù)只需要存儲(chǔ) URI(相對(duì)路徑),在應(yīng)用中配置 NAS 服務(wù)器地址

表拆分

將不常用的字段拆分出去,避免列數(shù)過(guò)多和數(shù)據(jù)量過(guò)大
比如在業(yè)務(wù)系統(tǒng)中,要記錄所有接收和發(fā)送的消息,這個(gè)消息是 XML 格式的,用 blob 或者 text 存儲(chǔ),用來(lái)追蹤和判斷重復(fù),可以建立一張表專門用來(lái)存儲(chǔ)報(bào)文

總結(jié):優(yōu)化體系

除了對(duì)于代碼,SQL 語(yǔ)句,表定義,架構(gòu),配置優(yōu)化之外,業(yè)務(wù)層面的優(yōu)化也不能忽視.舉幾個(gè)例子:

• 在某一年的雙十一,為什么會(huì)做一個(gè)充值到余額寶和余額有獎(jiǎng)金的活動(dòng)(充300送50)?

因?yàn)槭褂糜囝~或者余額寶付款是記錄本地或者內(nèi)部數(shù)據(jù)庫(kù),而使用銀行卡付款,需要調(diào)用接口,操作內(nèi)部數(shù)據(jù)庫(kù)肯定更快

• 在去年的雙十一,為什么在凌晨禁止查詢今天之外的賬單?

這是一種降級(jí)措施,用來(lái)保證當(dāng)前最核心的業(yè)務(wù)

• 最近幾年的雙十一,為什么提前一個(gè)多星期就已經(jīng)有雙十一當(dāng)天的價(jià)格了?

預(yù)售分流

在應(yīng)用層面同樣有很多其他的方案來(lái)優(yōu)化,達(dá)到盡量減輕數(shù)據(jù)庫(kù)的壓力的目的,比如限流,或者引入 MQ 削峰,等等等等
為什么同樣用 MySQL,有的公司可以扛住百萬(wàn)千萬(wàn)級(jí)別的并發(fā),而有的公司幾百個(gè)并發(fā)都扛不住,關(guān)鍵在于怎么用.所以,用數(shù)據(jù)庫(kù)慢,不代表數(shù)據(jù)庫(kù)本身慢,有的時(shí)候還要往上層去優(yōu)化
當(dāng)然,如果關(guān)系型數(shù)據(jù)庫(kù)解決不了的問(wèn)題,我們可能需要用到搜索引擎或者大數(shù)據(jù)的方案了,并不是所有的數(shù)據(jù)都要放到關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)