怎么優(yōu)化SQL數(shù)據(jù)庫

怎么優(yōu)化SQL數(shù)據(jù)庫？這篇文章詳細(xì)介紹了SQL數(shù)據(jù)庫的優(yōu)化原因和優(yōu)化方案，閱讀完整文相信大家對(duì)SQL數(shù)據(jù)庫的優(yōu)化有了一定的認(rèn)識(shí)。

一：優(yōu)化說明
A：有數(shù)據(jù)表明，用戶可以承受的最大等待時(shí)間為8秒。數(shù)據(jù)庫優(yōu)化策略有很多，設(shè)計(jì)初期，建立好的數(shù)據(jù)結(jié)構(gòu)對(duì)于后期性能優(yōu)化至關(guān)重要。因?yàn)閿?shù)據(jù)庫結(jié)構(gòu)是系統(tǒng)的基石，基礎(chǔ)打不好，使用各種優(yōu)化策略，也不能達(dá)到很完美的效果。

B：數(shù)據(jù)庫優(yōu)化的幾個(gè)方面 
 
 可以看出來，數(shù)據(jù)結(jié)構(gòu)、SQL、索引是成本最低，且效果最好的優(yōu)化手段。

C：性能優(yōu)化是無止境的，當(dāng)性能可以滿足需求時(shí)即可，不要過度優(yōu)化。

二：優(yōu)化方向
1. SQL以及索引的優(yōu)化
首先要根據(jù)需求寫出結(jié)構(gòu)良好的SQL，然后根據(jù)SQL在表中建立有效的索引。但是如果索引太多，不但會(huì)影響寫入的效率，對(duì)查詢也有一定的影響。

2. 合理的數(shù)據(jù)庫是設(shè)計(jì)
根據(jù)數(shù)據(jù)庫三范式來進(jìn)行表結(jié)構(gòu)的設(shè)計(jì)。設(shè)計(jì)表結(jié)構(gòu)時(shí)，就需要考慮如何設(shè)計(jì)才能更有效的查詢。

數(shù)據(jù)庫三范式： 
第一范式：數(shù)據(jù)表中每個(gè)字段都必須是不可拆分的最小單元，也就是確保每一列的原子性； 
第二范式：滿足一范式后，表中每一列必須有唯一性，都必須依賴于主鍵； 
第三范式：滿足二范式后，表中的每一列只與主鍵直接相關(guān)而不是間接相關(guān)(外鍵也是直接相關(guān))，字段沒有冗余。

注意：沒有最好的設(shè)計(jì)，只有最合適的設(shè)計(jì)，所以不要過分注重理論。三范式可以作為一個(gè)基本依據(jù)，不要生搬硬套。

有時(shí)候可以根據(jù)場(chǎng)景合理地反規(guī)范化： 
A：分割表。 
B：保留冗余字段。當(dāng)兩個(gè)或多個(gè)表在查詢中經(jīng)常需要連接時(shí)，可以在其中一個(gè)表上增加若干冗余的字段，以 避免表之間的連接過于頻繁，一般在冗余列的數(shù)據(jù)不經(jīng)常變動(dòng)的情況下使用。 
C：增加派生列。派生列是由表中的其它多個(gè)列的計(jì)算所得，增加派生列可以減少統(tǒng)計(jì)運(yùn)算，在數(shù)據(jù)匯總時(shí)可以大大縮短運(yùn)算時(shí)間。

數(shù)據(jù)庫五大約束： 
A：PRIMARY key:設(shè)置主鍵約束； 
B：UNIQUE：設(shè)置唯一性約束，不能有重復(fù)值； 
C：DEFAULT 默認(rèn)值約束 
D：NOT NULL：設(shè)置非空約束，該字段不能為空； 
E：FOREIGN key :設(shè)置外鍵約束。

字段類型選擇： 
A：盡量使用TINYINT、SMALLINT、MEDIUM_INT作為整數(shù)類型而非INT，如果非負(fù)則加上UNSIGNED 
B：VARCHAR的長(zhǎng)度只分配真正需要的空間 
C：使用枚舉或整數(shù)代替字符串類型 
D：盡量使用TIMESTAMP而非DATETIME 
E：?jiǎn)伪聿灰刑嘧侄危ㄗh在20以內(nèi) 
F：避免使用NULL字段，很難查詢優(yōu)化且占用額外索引空間

3. 系統(tǒng)配置的優(yōu)化
例如：MySQL數(shù)據(jù)庫my.cnf

4. 硬件優(yōu)化
更快的IO、更多的內(nèi)存。一般來說內(nèi)存越大，對(duì)于數(shù)據(jù)庫的操作越好。但是CPU多就不一定了，因?yàn)樗⒉粫?huì)用到太多的CPU數(shù)量，有很多的查詢都是單CPU。另外使用高的IO（SSD、RAID），但是IO并不能減少數(shù)據(jù)庫鎖的機(jī)制。所以說如果查詢緩慢是因?yàn)閿?shù)據(jù)庫內(nèi)部的一些鎖引起的，那么硬件優(yōu)化就沒有什么意義。

三：優(yōu)化方案
代碼優(yōu)化
之所以把代碼放到第一位，是因?yàn)檫@一點(diǎn)最容易引起技術(shù)人員的忽視。很多技術(shù)人員拿到一個(gè)性能優(yōu)化的需求以后，言必稱緩存、異步、JVM等。實(shí)際上，第一步就應(yīng)該是分析相關(guān)的代碼，找出相應(yīng)的瓶頸，再來考慮具體的優(yōu)化策略。有一些性能問題，完全是由于代碼寫的不合理，通過直接修改一下代碼就能解決問題的，比如for循環(huán)次數(shù)過多、作了很多無謂的條件判斷、相同邏輯重復(fù)多次等。

舉個(gè)例子： 
一個(gè)update操作，先查詢出entity，再執(zhí)行update，這樣無疑多了一次數(shù)據(jù)庫交互。還有一個(gè)問題，update語句可能會(huì)操作一些無需更新的字段。 
 
我們可以將表單中涉及到的屬性，以及updateTime，updateUser等賦值到entity，直接通過pdateByPrimaryKeySelective，去update特定字段。

定位慢SQL，并優(yōu)化
這是最常用、每一個(gè)技術(shù)人員都應(yīng)該掌握基本的SQL調(diào)優(yōu)手段（包括方法、工具、輔助系統(tǒng)等）。這里以MySQL為例，最常見的方式是，由自帶的慢查詢?nèi)罩净蛘唛_源的慢查詢系統(tǒng)定位到具體的出問題的SQL，然后使用explain、profile等工具來逐步調(diào)優(yōu)，最后經(jīng)過測(cè)試達(dá)到效果后上線。

SqlServer執(zhí)行計(jì)劃：
通過執(zhí)行計(jì)劃，我們能得到哪些信息： 
A：哪些步驟花費(fèi)的成本比較高 
B：哪些步驟產(chǎn)生的數(shù)據(jù)量多，數(shù)據(jù)量的多少用線條的粗細(xì)表示，很直觀 
C：每一步執(zhí)行了什么動(dòng)作

具體優(yōu)化手段：
A：盡量少用（或者不用）sqlserver 自帶的函數(shù) 
select id from t where substring(name,1,3) = ’abc’ 
select id from t where datediff(day,createdate,’2005-11-30′) = 0 
可以這樣查詢： 
select id from t where name like ‘a(chǎn)bc%’ 
select id from t where createdate >= ‘2005-11-30’ and createdate < ‘2005-12-1’

B：連續(xù)數(shù)值條件，用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5 
C：Update 語句，如果只更改1、2個(gè)字段，不要Update全部字段，否則頻繁調(diào)用會(huì)引起明顯的性能消耗 
D：盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型 
E：不建議使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。盡量避免向客戶 端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理 
F：表與表之間通過一個(gè)冗余字段來關(guān)聯(lián)，要比直接使用JOIN有更好的性能 
G：select count(*) from table；這樣不帶任何條件的count會(huì)引起全表掃描 
連接池調(diào)優(yōu) 
我們的應(yīng)用為了實(shí)現(xiàn)數(shù)據(jù)庫連接的高效獲取、對(duì)數(shù)據(jù)庫連接的限流等目的，通常會(huì)采用連接池類的方案，即每一個(gè)應(yīng)用節(jié)點(diǎn)都管理了一個(gè)到各個(gè)數(shù)據(jù)庫的連接池。隨著業(yè)務(wù)訪問量或者數(shù)據(jù)量的增長(zhǎng)，原有的連接池參數(shù)可能不能很好地滿足需求，這個(gè)時(shí)候就需要結(jié)合當(dāng)前使用連接池的原理、具體的連接池監(jiān)控?cái)?shù)據(jù)和當(dāng)前的業(yè)務(wù)量作一個(gè)綜合的判斷，通過反復(fù)的幾次調(diào)試得到最終的調(diào)優(yōu)參數(shù)。

合理使用索引
索引一般情況下都是高效的。但是由于索引是以空間換時(shí)間的一種策略，索引本身在提高查詢效率的同時(shí)會(huì)影響插入、更新、刪除的效率，頻繁寫的表不宜建索引。

選擇合適的索引列，選擇在where，group by，order by，on從句中出現(xiàn)的列作為索引項(xiàng)，對(duì)于離散度不大的列沒有必要?jiǎng)?chuàng)建索引。 
主鍵已經(jīng)是索引了，所以primay key 的主鍵不用再設(shè)置unique唯一索引

索引類型 
主鍵索引 （PRIMARY KEY） 
唯一索引 （UNIQUE） 
普通索引 （INDEX） 
組合索引 （INDEX） 
全文索引 （FULLTEXT）

可以應(yīng)用索引的操作符 
大于等于 
Between 
IN 
LIKE 不以 % 開頭

不能應(yīng)用索引的操作符 
NOT IN 
LIKE %_ 開頭

如何選擇索引字段 
A：字段出現(xiàn)在查詢條件中，并且查詢條件可以使用索引 
B：通常對(duì)數(shù)字的索引和檢索要比對(duì)字符串的索引和檢索效率更高 
C：語句執(zhí)行頻率高，一天會(huì)有幾千次以上 
D：通過字段條件可篩選的記錄集很小 
無效索引 
A：盡量不要在 where 子句中對(duì)字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描 
B：應(yīng)盡量避免在 where 子句中使用 != 或 <> 操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。 
C：應(yīng)盡量避免在 where 子句中使用 or 來連接條件，如果一個(gè)字段有索引，一個(gè)字段沒有索引，將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描 
select id from t where num=10 or Name = ‘a(chǎn)dmin’ 
可以這樣查詢： 
select id from t where num = 10 
union 
select id from t where Name = ‘a(chǎn)dmin’ 
union all 返回所有數(shù)據(jù)，不管是不是重復(fù)。 union會(huì)自動(dòng)壓縮，去除重復(fù)數(shù)據(jù)。

D：不做列運(yùn)算 
where age + 1 = 10，任何對(duì)列的操作都將導(dǎo)致表掃描，它包括數(shù)據(jù)庫教程函數(shù)、計(jì)算表達(dá)式等 
E：查詢like，如果是 ‘%aaa’ 不會(huì)使用到索引

分表
分表方式 
水平分割（按行）、垂直分割(按列)

分表場(chǎng)景 
A： 根據(jù)經(jīng)驗(yàn)，mysql表數(shù)據(jù)一般達(dá)到百萬級(jí)別，查詢效率就會(huì)很低。 
B： 一張表的某些字段值比較大并且很少使用?？梢詫⑦@些字段隔離成單獨(dú)一張表，通過外鍵關(guān)聯(lián)，例如考試成績(jī)，我們通常關(guān)注分?jǐn)?shù)，不關(guān)注考試詳情。

水平分表策略 
按時(shí)間分表：當(dāng)數(shù)據(jù)有很強(qiáng)的實(shí)效性，例如微博的數(shù)據(jù)，可以按月分割。 
按區(qū)間分表：例如用戶表 1到一百萬用一張表，一百萬到兩百萬用一張表。 
hash分表：通過一個(gè)原始目標(biāo)id或者是名稱按照一定的hash算法計(jì)算出數(shù)據(jù)存儲(chǔ)的表名。

讀寫分離
當(dāng)一臺(tái)服務(wù)器不能滿足需求時(shí)，采用讀寫分離【寫: update/delete/add】的方式進(jìn)行集群。 
一臺(tái)數(shù)據(jù)庫支持最大連接數(shù)是有限的，如果用戶的并發(fā)訪問很多，一臺(tái)服務(wù)器無法滿足需求，可以集群處理。mysql集群處理技術(shù)最常用的就是讀寫分離。

主從同步：數(shù)據(jù)庫最終會(huì)把數(shù)據(jù)持久化到磁盤，集群必須確保每個(gè)數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)是一致的。從庫讀主庫寫，從庫從主庫上同步數(shù)據(jù)。 
讀寫分離：使用負(fù)載均衡實(shí)現(xiàn)，寫操作都往主庫上寫，讀操作往從服務(wù)器上讀。

緩存
緩存分類 
本地緩存：HashMap/ConcurrentHashMap、Ehcache、Guava Cache等 
緩存服務(wù)：Redis/Tair/Memcache等

使用場(chǎng)景 
短時(shí)間內(nèi)相同數(shù)據(jù)重復(fù)查詢多次且數(shù)據(jù)更新不頻繁，這個(gè)時(shí)候可以選擇先從緩存查詢，查詢不到再從數(shù)據(jù)庫加載并回設(shè)到緩存的方式。此種場(chǎng)景較適合用單機(jī)緩存。 
高并發(fā)查詢熱點(diǎn)數(shù)據(jù)，后端數(shù)據(jù)庫不堪重負(fù)，可以用緩存來扛。

緩存作用 
減輕數(shù)據(jù)庫的壓力，減少訪問時(shí)間。

緩存選擇 
如果數(shù)據(jù)量小，并且不會(huì)頻繁地增長(zhǎng)又清空（這會(huì)導(dǎo)致頻繁地垃圾回收），那么可以選擇本地緩存。具體的話，如果需要一些策略的支持（比如緩存滿的逐出策略），可以考慮Ehcache；如不需要，可以考慮HashMap；如需要考慮多線程并發(fā)的場(chǎng)景，可以考慮ConcurentHashMap。 
其他情況，可以考慮緩存服務(wù)。目前從資源的投入度、可運(yùn)維性、是否能動(dòng)態(tài)擴(kuò)容以及配套設(shè)施來考慮，我們優(yōu)先考慮Tair。除非目前Tair還不能支持的場(chǎng)合（比如分布式鎖、Hash類型的value），我們考慮用Redis。

緩存穿透 
一般的緩存系統(tǒng)，都是按照key去緩存查詢，如果不存在對(duì)應(yīng)的value，就應(yīng)該去后端系統(tǒng)查找（比 
如DB）。如果key對(duì)應(yīng)的value是一定不存在的，并且對(duì)該key并發(fā)請(qǐng)求量很大，就會(huì)對(duì)后端系統(tǒng)造 
成很大的壓力。這就叫做緩存穿透。

對(duì)查詢結(jié)果為空的情況也進(jìn)行緩存，緩存時(shí)間設(shè)置短點(diǎn)，或者該key對(duì)應(yīng)的數(shù)據(jù)insert了之后清理緩存。

緩存并發(fā) 
有時(shí)候如果網(wǎng)站并發(fā)訪問高，一個(gè)緩存如果失效，可能出現(xiàn)多個(gè)進(jìn)程同時(shí)查詢DB，同時(shí)設(shè)置緩存的情況， 
如果并發(fā)確實(shí)很大，這也可能造成DB壓力過大，還有緩存頻繁更新的問題。

對(duì)緩存查詢加鎖，如果KEY不存在，就加鎖，然后查DB入緩存，然后解鎖；其他進(jìn)程如果發(fā)現(xiàn)有鎖就 
等待，然后等解鎖后返回?cái)?shù)據(jù)或者進(jìn)入DB查詢。

緩存雪崩(失效) 
當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段失效，這樣在失效的時(shí)候，也會(huì)給后端系統(tǒng)(比如DB) 
帶來很大壓力。 
不同的key，設(shè)置不同的過期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻.

防止緩存空間不夠用 
① 給緩存服務(wù)，選擇合適的緩存逐出算法，比如最常見的LRU。 
② 針對(duì)當(dāng)前設(shè)置的容量，設(shè)置適當(dāng)?shù)木渲?，比?0G的緩存，當(dāng)緩存數(shù)據(jù)達(dá)到8G的時(shí)候，就開始發(fā)出報(bào)警，提前排查問題或者擴(kuò)容。 
③ 給一些沒有必要長(zhǎng)期保存的key，盡量設(shè)置過期時(shí)間。

我們看下圖，在WebServer（Dao層）和DB之間加一層cache，這層cache一般選取的介質(zhì)是內(nèi)存，因?yàn)槲覀兌贾来嫒霐?shù)據(jù)庫的數(shù)據(jù)都具有持久化的特點(diǎn)，那么讀寫會(huì)有磁盤IO的操作，內(nèi)存的讀寫速度遠(yuǎn)比磁盤快得多。（選用存儲(chǔ)介質(zhì)，提高訪問速度：內(nèi)存>>磁盤；減少磁盤IO的操作，減少重復(fù)查詢，提高吞吐量）

常用開源的緩存工具有：ehcache、memcache、redis。

ehcache 是一個(gè)純Java的進(jìn)程內(nèi)緩存框架，hibernate使用其做二級(jí)緩存。同時(shí)，ehcache可以通過多播的方式實(shí)現(xiàn)集群。本人主要用于本地的緩存，數(shù)據(jù)庫上層的緩存。 
memcache是一套分布式的高速緩存系統(tǒng)，提供key-value這樣簡(jiǎn)單的數(shù)據(jù)儲(chǔ)存，可充分利用CPU多核，無持久化功能。在做web集群中可以用做session共享，頁面對(duì)象緩存。 
redis高性能的key-value系統(tǒng)，提供豐富的數(shù)據(jù)類型，單核CPU有抗并發(fā)能力，有持久化和主從復(fù)制的功能。本人主要使用redis的redis sentinel，根據(jù)不同業(yè)務(wù)分為多組。

redis注意事項(xiàng) 
A：在增加 key 的時(shí)候盡量設(shè)置過期時(shí)間，不然 Redis Server 的內(nèi)存使用會(huì)達(dá)到系統(tǒng)物理內(nèi)存的最大值，導(dǎo)致 Redis 使用 VM 降低系統(tǒng)性能； 
B：Redis Key 設(shè)計(jì)時(shí)應(yīng)該盡可能短,Value 盡量不要使用復(fù)雜對(duì)象； 
C：將對(duì)象轉(zhuǎn)換成 JSON 對(duì)象（利用現(xiàn)成的 JSON 庫）后存入 Redis； 
D：將對(duì)象轉(zhuǎn)換成 Google 開源二進(jìn)制協(xié)議對(duì)象（Google Protobuf，和 JSON 數(shù)據(jù)格式類似，但是因?yàn)槭嵌M(jìn)制表現(xiàn)，所以性能效率以及空間占用都比 JSON 要??；缺點(diǎn)是 Protobuf 的學(xué)習(xí)曲線比 JSON 大得多）； 
E：Redis 使用完以后一定要釋放連接。

讀取緩存中是否有相關(guān)數(shù)據(jù)，如果緩存中有相關(guān)數(shù)據(jù)，則直接返回，這就是所謂的數(shù)據(jù)命中“hit” 
如果緩存中沒有相關(guān)數(shù)據(jù)，則從數(shù)據(jù)庫讀取相關(guān)數(shù)據(jù)，放入緩存中，再返回。這就是所謂的數(shù)據(jù)未命中“miss”

緩存的命中率 = 命中緩存請(qǐng)求個(gè)數(shù)/總緩存訪問請(qǐng)求個(gè)數(shù) = hit/(hit+miss) 
/*java框架項(xiàng)目案例 www.1b23.com*/

NoSQL
與緩存的區(qū)別 
先說明一下，這里介紹的和緩存不一樣，雖然redis等也可以用來做數(shù)據(jù)存儲(chǔ)方案（比如Redis或者Tair），但NoSql是把它作為DB來用。如果當(dāng)作DB來用，需要有效保證數(shù)據(jù)存儲(chǔ)方案的可用性、可靠性。

使用場(chǎng)景 
需要結(jié)合具體的業(yè)務(wù)場(chǎng)景，看這塊業(yè)務(wù)涉及的數(shù)據(jù)是否適合用NoSQL來存儲(chǔ)，對(duì)數(shù)據(jù)的操作方式是否適合用NoSQL的方式來操作，或者是否需要用到NoSQL的一些額外特性（比如原子加減等）。 
如果業(yè)務(wù)數(shù)據(jù)不需要和其他數(shù)據(jù)作關(guān)聯(lián)，不需要事務(wù)或者外鍵之類的支持，而且有可能寫入會(huì)異常頻繁，這個(gè)時(shí)候就比較適合用NoSQL（比如HBase）。 
比如，美團(tuán)點(diǎn)評(píng)內(nèi)部有一個(gè)對(duì)exception做的監(jiān)控系統(tǒng)，如果在應(yīng)用系統(tǒng)發(fā)生嚴(yán)重故障的時(shí)候，可能會(huì)短時(shí)間產(chǎn)生大量exception數(shù)據(jù)，這個(gè)時(shí)候如果選用MySQL，會(huì)造成MySQL的瞬間寫壓力飆升，容易導(dǎo)致MySQL服務(wù)器的性能急劇惡化以及主從同步延遲之類的問題，這種場(chǎng)景就比較適合用Hbase類似的NoSQL來存儲(chǔ)。 
視圖/存儲(chǔ)過程 
普通業(yè)務(wù)邏輯盡量不要使用存儲(chǔ)過程，定時(shí)任務(wù)或報(bào)表統(tǒng)計(jì)函數(shù)可以根據(jù)團(tuán)隊(duì)資源情況采用存儲(chǔ)過程處理。

GVM調(diào)優(yōu)
通過監(jiān)控系統(tǒng)（如沒有現(xiàn)成的系統(tǒng)，自己做一個(gè)簡(jiǎn)單的上報(bào)監(jiān)控的系統(tǒng)也很容易）上對(duì)一些機(jī)器關(guān)鍵指標(biāo)（gc time、gc count、各個(gè)分代的內(nèi)存大小變化、機(jī)器的Load值與CPU使用率、JVM的線程數(shù)等）的監(jiān)控報(bào)警，也可以看gc log和jstat等命令的輸出，再結(jié)合線上JVM進(jìn)程服務(wù)的一些關(guān)鍵接口的性能數(shù)據(jù)和請(qǐng)求體驗(yàn)，基本上就能定位出當(dāng)前的JVM是否有問題，以及是否需要調(diào)優(yōu)。

異步/多線程
針對(duì)某些客戶端的請(qǐng)求，在服務(wù)端可能需要針對(duì)這些請(qǐng)求做一些附屬的事情，這些事情其實(shí)用戶并不關(guān)心或者用戶不需要立即拿到這些事情的處理結(jié)果，這種情況就比較適合用異步的方式處理這些事情。

異步作用 
A：縮短接口響應(yīng)時(shí)間，使用戶的請(qǐng)求快速返回，用戶體驗(yàn)更好。 
B：避免線程長(zhǎng)時(shí)間處于運(yùn)行狀態(tài)，這樣會(huì)引起服務(wù)線程池的可用線程長(zhǎng)時(shí)間不夠用，進(jìn)而引起線程池任務(wù)隊(duì)列長(zhǎng)度增大，從而阻塞更多請(qǐng)求任務(wù)，使得更多請(qǐng)求得不到技術(shù)處理。 
C：線程長(zhǎng)時(shí)間處于運(yùn)行狀態(tài)，可能還會(huì)引起系統(tǒng)Load、CPU使用率、機(jī)器整體性能下降等一系列問題，甚至引發(fā)雪崩。異步的思路可以在不增加機(jī)器數(shù)和CPU數(shù)的情況下，有效解決這個(gè)問題。

異步實(shí)現(xiàn) 
A：額外開辟線程，這里可以采用額外開辟一個(gè)線程或者使用線程池的做法，在IO線程（處理請(qǐng)求響應(yīng)）之外的線程來處理相應(yīng)的任務(wù)，在IO線程中讓response先返回。 
B：使用消息隊(duì)列（MQ）中間件服務(wù)

關(guān)于SQL數(shù)據(jù)庫的優(yōu)化就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。