亚洲精品一区二区黄美女和男,亚洲AV无码秘牛牛影视,无码国产玉足脚交久久2022

程序員該如何進(jìn)行 SQL 數(shù)據(jù)庫(kù)的優(yōu)化？

作者 | 單一色調(diào)

責(zé)編 | Elle

出品 | CSDN 博客

之前的文章是從實(shí)例的角度進(jìn)行數(shù)據(jù)庫(kù)優(yōu)化，通過(guò)配置一些參數(shù)讓數(shù)據(jù)庫(kù)性能達(dá)到最優(yōu)。但是一些“不好”的SQL也會(huì)導(dǎo)致數(shù)據(jù)庫(kù)查詢變慢，影響業(yè)務(wù)流程。本文從SQL角度進(jìn)行數(shù)據(jù)庫(kù)優(yōu)化，提升SQL運(yùn)行效率。

1.判斷問(wèn)題SQL

判斷SQL是否有問(wèn)題時(shí)可以通過(guò)兩個(gè)表象進(jìn)行判斷：

系統(tǒng)級(jí)別表象
- CPU消耗嚴(yán)重
- IO等待嚴(yán)重
- 頁(yè)面響應(yīng)時(shí)間過(guò)長(zhǎng)
- 應(yīng)用的日志出現(xiàn)超時(shí)等錯(cuò)誤

可以使用sar命令，top命令查看當(dāng)前系統(tǒng)狀態(tài)。

也可以通過(guò)Prometheus、Grafana等監(jiān)控工具觀察系統(tǒng)狀態(tài)。（感興趣的可以翻看我之前的文章）

程序員該如何進(jìn)行 SQL 數(shù)據(jù)庫(kù)的優(yōu)化？

SQL語(yǔ)句表象
- 冗長(zhǎng)
- 執(zhí)行時(shí)間過(guò)長(zhǎng)
- 從全表掃描獲取數(shù)據(jù)
- 執(zhí)行計(jì)劃中的rows、cost很大

冗長(zhǎng)的SQL都好理解，一段SQL太長(zhǎng)閱讀性肯定會(huì)差，而且出現(xiàn)問(wèn)題的頻率肯定會(huì)更高。更進(jìn)一步判斷SQL問(wèn)題就得從執(zhí)行計(jì)劃入手，如下所示：

執(zhí)行計(jì)劃告訴我們本次查詢走了全表掃描Type=ALL，rows很大(9950400)基本可以判斷這是一段"有味道"的SQL。

2.獲取問(wèn)題SQL

不同數(shù)據(jù)庫(kù)有不同的獲取方法，以下為目前主流數(shù)據(jù)庫(kù)的慢查詢SQL獲取工具

MySQL
- 慢查詢?nèi)罩?/p>
- 測(cè)試工具loadrunner
- Percona公司的ptquery等工具
Oracle
- AWR報(bào)告
- 測(cè)試工具loadrunner等
- 相關(guān)內(nèi)部視圖如v$
- GRID CONTROL監(jiān)控工具
達(dá)夢(mèng)數(shù)據(jù)庫(kù)
- AWR報(bào)告
- 測(cè)試工具loadrunner等
- 達(dá)夢(mèng)性能監(jiān)控工具（dem）
- 相關(guān)內(nèi)部視圖如v$

3.SQL編寫技巧

SQL編寫有以下幾個(gè)通用的技巧：

• 合理使用索引

索引少了查詢慢；索引多了占用空間大，執(zhí)行增刪改語(yǔ)句的時(shí)候需要?jiǎng)討B(tài)維護(hù)索引，影響性能選擇率高（重復(fù)值少）且被where頻繁引用需要建立B樹(shù)索引；

一般join列需要建立索引；復(fù)雜文檔類型查詢采用全文索引效率更好；索引的建立要在查詢和DML性能之間取得平衡；復(fù)合索引創(chuàng)建時(shí)要注意基于非前導(dǎo)列查詢的情況

• 使用UNION ALL替代UNION

UNION ALL的執(zhí)行效率比UNION高，UNION執(zhí)行時(shí)需要排重；UNION需要對(duì)數(shù)據(jù)進(jìn)行排序

• 避免select * 寫法

執(zhí)行SQL時(shí)優(yōu)化器需要將 * 轉(zhuǎn)成具體的列；每次查詢都要回表，不能走覆蓋索引。

• JOIN字段建議建立索引

一般JOIN字段都提前加上索引

• 避免復(fù)雜SQL語(yǔ)句

提升可閱讀性；避免慢查詢的概率；可以轉(zhuǎn)換成多個(gè)短查詢，用業(yè)務(wù)端處理

• 避免where 1=1寫法

• 避免order by rand類似寫法

RAND導(dǎo)致數(shù)據(jù)列被多次掃描

4.SQL優(yōu)化

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

完成SQL優(yōu)化一定要先讀執(zhí)行計(jì)劃，執(zhí)行計(jì)劃會(huì)告訴你哪些地方效率低，哪里可以需要優(yōu)化。我們以MYSQL為例，看看執(zhí)行計(jì)劃是什么。（每個(gè)數(shù)據(jù)庫(kù)的執(zhí)行計(jì)劃都不一樣，需要自行了解）

explain sql

接下來(lái)我們用一段實(shí)際優(yōu)化案例來(lái)說(shuō)明SQL優(yōu)化的過(guò)程及優(yōu)化技巧。

優(yōu)化案例

表結(jié)構(gòu)

CREATE TABLE `a`
(
`id` int(11) NOT AUTO_INCREMENT,
`seller_id` bigint(20) DEFAULT ,
`seller_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT ,
`gmt_create` varchar(30) DEFAULT ,
PRIMARY KEY (`id`)
);
CREATE TABLE `b`
(
`id` int(11) NOT AUTO_INCREMENT,
`seller_name` varchar(100) DEFAULT ,
`user_id` varchar(50) DEFAULT ,
`user_name` varchar(100) DEFAULT ,
`sales` bigint(20) DEFAULT ,
`gmt_create` varchar(30) DEFAULT ,
PRIMARY KEY (`id`)
);
CREATE TABLE `c`
(
`id` int(11) NOT AUTO_INCREMENT,
`user_id` varchar(50) DEFAULT ,
`order_id` varchar(100) DEFAULT ,
`state` bigint(20) DEFAULT ,
`gmt_create` varchar(30) DEFAULT ,
PRIMARY KEY (`id`)
)

三張表關(guān)聯(lián)，查詢當(dāng)前用戶在當(dāng)前時(shí)間前后10個(gè)小時(shí)的訂單情況，并根據(jù)訂單創(chuàng)建時(shí)間升序排列，具體SQL如下

select a.seller_id,
a.seller_name,
b.user_name,
c.state
from a,
b,
c
where a.seller_name = b.seller_name
and b.user_id = c.user_id
and c.user_id = 17
and a.gmt_create
BETWEEN DATE_ADD(NOW, INTERVAL – 600 MINUTE)
AND DATE_ADD(NOW, INTERVAL 600 MINUTE)
order by a.gmt_create；

查看數(shù)據(jù)量

原執(zhí)行時(shí)間

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

初步優(yōu)化思路

SQL中 where條件字段類型要跟表結(jié)構(gòu)一致，表中user_id 為varchar(50)類型，實(shí)際SQL用的int類型，存在隱式轉(zhuǎn)換，也未添加索引。將b和c表user_id 字段改成int類型；
因存在b表和c表關(guān)聯(lián)，將b和c表user_id創(chuàng)建索引；
因存在a表和b表關(guān)聯(lián)，將a和b表seller_name字段創(chuàng)建索引；
利用復(fù)合索引消除臨時(shí)表和排序。

初步優(yōu)化SQL

alter table b modify `user_id` int(10) DEFAULT ;
alter table c modify `user_id` int(10) DEFAULT ;
alter table c add index `idx_user_id`(`user_id`);
alter table b add index `idx_user_id_sell_name`(`user_id`,`seller_name`);
alter table a add index `idx_sellname_gmt_sellid`(`gmt_create`,`seller_name`,`seller_id`);

查看優(yōu)化后執(zhí)行時(shí)間