色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

淺談SQL優(yōu)化小技巧

京東云 ? 來源:京東零售 王軍 ? 作者:京東零售 王軍 ? 2024-12-25 09:59 ? 次閱讀

作者:京東零售 王軍

回顧:MySQL的執(zhí)行過程回顧 MySQL的執(zhí)行過程,幫助 介紹 如何進(jìn)行sql優(yōu)化。

(1)客戶端發(fā)送一條查詢語句到服務(wù)器;

(2)服務(wù)器先查詢緩存,如果命中緩存,則立即返回存儲(chǔ)在緩存中的數(shù)據(jù);

(3)未命中緩存后,MySQL通過關(guān)鍵字將SQL語句進(jìn)行解析,并生成一顆對應(yīng)的解析樹,MySQL解析器將使用MySQL語法進(jìn)行驗(yàn)證和解析。

例如,驗(yàn)證是否使用了錯(cuò)誤的關(guān)鍵字,或者關(guān)鍵字的使用是否正確;

(4)預(yù)處理是根據(jù)一些MySQL規(guī)則檢查解析樹是否合理,比如檢查表和列是否存在,還會(huì)解析名字和別名,然后預(yù)處理器會(huì)驗(yàn)證權(quán)限;

根據(jù)執(zhí)行計(jì)劃查詢執(zhí)行引擎,調(diào)用API接口調(diào)用存儲(chǔ)引擎來查詢數(shù)據(jù);

(5)將結(jié)果返回客戶端,并進(jìn)行緩存;

SQL語句性能優(yōu)化常用策略

1、 為 WHERE 及 ORDER BY 涉及的列上建立索引

對查詢進(jìn)行優(yōu)化,應(yīng)盡量避免全表掃描,首先應(yīng)考慮在 WHERE 及 ORDER BY 涉及的列上建立索引。

2、where中使用默認(rèn)值代替null應(yīng)盡量避免在 WHERE 子句中對字段進(jìn)行 NULL 值判斷,創(chuàng)建表時(shí) NULL 是默認(rèn)值,但大多數(shù)時(shí)候應(yīng)該使用 NOT NULL,或者使用一個(gè)特殊的值,如 0,-1 作為默認(rèn)值。

為啥建議where中使用默認(rèn)值代替null,四個(gè)原因:

(1)并不是說使用了is null或者 is not null就會(huì)不走索引了,這個(gè)跟mysql版本以及查詢成本都有關(guān);

(2)如果mysql優(yōu)化器發(fā)現(xiàn),走索引比不走索引成本還要高,就會(huì)放棄索引,這些條件 !=,<>,is null,is not null經(jīng)常被認(rèn)為讓索引失效;

(3)其實(shí)是因?yàn)橐话闱闆r下,查詢的成本高,優(yōu)化器自動(dòng)放棄索引的;

(4)如果把null值,換成默認(rèn)值,很多時(shí)候讓走索引成為可能,同時(shí),表達(dá)意思也相對清晰一點(diǎn);

3、慎用 != 或 <> 操作符。MySQL 只有對以下操作符才使用索引:<,<=,=,>,>=,BETWEEN,IN,以及某些時(shí)候的 LIKE。

所以:應(yīng)盡量避免在 WHERE 子句中使用 != 或 <> 操作符, 會(huì)導(dǎo)致全表掃描。

4、慎用 OR 來連接條件使用or可能會(huì)使索引失效,從而全表掃描;

應(yīng)盡量避免在 WHERE 子句中使用 OR 來連接條件,否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描,

可以使用 UNION 合并查詢:

select id from t where num=10

union all

select id from t where num=20

一個(gè)關(guān)鍵的問題是否用到索引。他們的速度只同是否使用索引有關(guān),如果查詢需要用到聯(lián)合索引,用 UNION all 執(zhí)行的效率更高。多個(gè) OR 的字句沒有用到索引,改寫成 UNION 的形式再試圖與索引匹配。

5、慎用 IN 和 NOT IN

IN 和 NOT IN 要慎用,否則會(huì)導(dǎo)致全表掃描。對于連續(xù)的數(shù)值,能用 BETWEEN 就不要用 IN:select id from t where num between 1 and 3。

6、慎用 左模糊like ‘%…’模糊查詢,程序員最喜歡的就是使用like,like很可能讓索引失效。

比如:

select id from t where name like‘%abc%’ select id from t where name like‘%abc’ 而select id from t where name like‘a(chǎn)bc%’才用到索引。

所以:

首先盡量避免模糊查詢,如果必須使用,不采用全模糊查詢,也應(yīng)盡量采用右模糊查詢, 即like ‘…%’,是會(huì)使用索引的; 左模糊like ‘%…’無法直接使用索引,但可以利用reverse + function index的形式,變化成 like ‘…%’; 全模糊查詢是無法優(yōu)化的,一定要使用的話建議使用搜索引擎,比如 ElasticSearch。 備注:如果一定要用左模糊like ‘%…’檢索, 一般建議 ElasticSearch+Hbase架構(gòu)

7、WHERE條件使用參數(shù)會(huì)導(dǎo)致全表掃描。如下面語句將進(jìn)行全表掃描:

select id from t where num=@num

因?yàn)镾QL只有在運(yùn)行時(shí)才會(huì)解析局部變量,但優(yōu)化程序不能將訪問計(jì)劃的選擇推 遲到 運(yùn)行時(shí);

它必須在編譯時(shí)進(jìn)行選擇。然而,如果在編譯時(shí)建立訪問計(jì)劃,變量的值還是未知的,因而無法作為索引選擇的輸入項(xiàng)。

所以, 可以改為強(qiáng)制查詢使用索引:

select id from t with(index(索引名)) where num=@num

8、用 EXISTS 代替 IN 是一個(gè)好的選擇很多時(shí)候用exists 代替in 是一個(gè)好的選擇:

select num from a where num in(select num from b) 用下面的語句替換: select num from a where exists(select 1 from b where num=a.num)

9、索引并不是越多越好索引固然可以提高相應(yīng)的 SELECT 的效率,但同時(shí)也降低了 INSERT 及 UPDATE 的效。

因?yàn)?INSERT 或 UPDATE 時(shí)有可能會(huì)重建索引,所以怎樣建索引需要慎重考慮,視具體情況而定。

一個(gè)表的索引數(shù)最好不要超過 6 個(gè),若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。

10、盡量使用數(shù)字型字段(1)因?yàn)橐嬖谔幚聿樵兒瓦B接時(shí)會(huì)逐個(gè)比較字符串中每一個(gè)字符;

(2)而對于數(shù)字型而言只需要比較一次就夠了;

(3)字符會(huì)降低查詢和連接的性能,并會(huì)增加存儲(chǔ)開銷;

所以:盡量使用數(shù)字型字段,若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型,這會(huì)降低查詢和連接的性能,并會(huì)增加存儲(chǔ)開銷。

11、盡可能的使用 varchar, nvarchar 代替 char, nchar(1)varchar變長字段按數(shù)據(jù)內(nèi)容實(shí)際長度存儲(chǔ),存儲(chǔ)空間小,可以節(jié)省存儲(chǔ)空間;

(2)char按聲明大小存儲(chǔ),不足補(bǔ)空格;

(3)其次對于查詢來說,在一個(gè)相對較小的字段內(nèi)搜索,效率更高;

因?yàn)槭紫茸冮L字段存儲(chǔ)空間小,可以節(jié)省存儲(chǔ)空間,其次對于查詢來說,在一個(gè)相對較小的字段內(nèi)搜索效率顯然要高些。

14、查詢SQL盡量不要使用select ,而是具體字段 最好不要使用返回所有:select * from t ,用具體的字段列表代替 “”,不要返回用不到的任何字段。

select *的弊端:

(1)增加很多不必要的消耗,比如CPU、IO、內(nèi)存、網(wǎng)絡(luò)帶寬;

(2)增加了使用覆蓋索引的可能性;

(3)增加了回表的可能性;

(4)當(dāng)表結(jié)構(gòu)發(fā)生變化時(shí),前端也需要更改;

(5)查詢效率低;

15、將需要查詢的結(jié)果預(yù)先計(jì)算好將需要查詢的結(jié)果預(yù)先計(jì)算好放在表中,查詢的時(shí)候再Select,而不是查詢的時(shí)候進(jìn)行計(jì)算。

16、IN后出現(xiàn)最頻繁的值放在最前面如果一定用IN,那么:

在IN后面值的列表中,將出現(xiàn)最頻繁的值放在最前面,出現(xiàn)得最少的放在最后面,減少判斷的次數(shù)。

17、盡量使用 EXISTS 代替 select count(1) 來判斷是否存在記錄。count 函數(shù)只有在統(tǒng)計(jì)表中所有行數(shù)時(shí)使用,而且 count(1) 比 count(*) 更有效率。

18、用批量插入或批量更新當(dāng)有一批處理的插入或更新時(shí),用批量插入或批量更新,絕不會(huì)一條條記錄的去更新。

(1)多條提交

INSERT INTO user (id,username) VALUES(1,'xx'); INSERT INTO user (id,username) VALUES(2,'yy');

(2)批量提交

INSERT INTO user (id,username) VALUES(1,'xx'),(2,'yy'); 默認(rèn)新增SQL有事務(wù)控制,導(dǎo)致每條都需要事務(wù)開啟和事務(wù)提交,而批量處理是一次事務(wù)開啟和提交,效率提升明顯,達(dá)到一定量級,效果顯著,平時(shí)看不出來。

19、將不需要的記錄在 GROUP BY 之前過濾掉提高 GROUP BY 語句的效率,可以通過將不需要的記錄在 GROUP BY 之前過濾掉。

下面兩個(gè)查詢返回相同結(jié)果,但第二個(gè)明顯就快了許多。

低效:

SELECT JOB, AVG(SAL) FROM EMP GROUP BY JOB HAVING JOB = 'PRESIDENT' OR JOB = 'MANAGER' 高效:

SELECT JOB, AVG(SAL) FROM EMP WHERE JOB = 'PRESIDENT' OR JOB = 'MANAGER' GROUP BY JOB

20、避免死鎖,在你的存儲(chǔ)過程和觸發(fā)器中訪問同一個(gè)表時(shí)總是以相同的順序;事務(wù)應(yīng)經(jīng)可能地縮短,在一個(gè)事務(wù)中應(yīng)盡可能減少涉及到的數(shù)據(jù)量;永遠(yuǎn)不要在事務(wù)中等待用戶輸入。

21、索引創(chuàng)建規(guī)則:表的主鍵、外鍵必須有索引; 數(shù)據(jù)量超過 300 的表應(yīng)該有索引; 經(jīng)常與其他表進(jìn)行連接的表,在連接字段上應(yīng)該建立索引; 經(jīng)常出現(xiàn)在 WHERE 子句中的字段,特別是大表的字段,應(yīng)該建立索引; 索引應(yīng)該建在選擇性高的字段上; 索引應(yīng)該建在小字段上,對于大的文本字段甚至超長字段,不要建索引; 復(fù)合索引的建立需要進(jìn)行仔細(xì)分析,盡量考慮用單字段索引代替; 正確選擇復(fù)合索引中的主列字段,一般是選擇性較好的字段; 復(fù)合索引的幾個(gè)字段是否經(jīng)常同時(shí)以 AND 方式出現(xiàn)在 WHERE 子句中?單字段查詢是否極少甚至沒有?如果是,則可以建立復(fù)合索引;否則考慮單字段索引; 如果復(fù)合索引中包含的字段經(jīng)常單獨(dú)出現(xiàn)在 WHERE 子句中,則分解為多個(gè)單字段索引; 如果復(fù)合索引所包含的字段超過 3 個(gè),那么仔細(xì)考慮其必要性,考慮減少復(fù)合的字段; 如果既有單字段索引,又有這幾個(gè)字段上的復(fù)合索引,一般可以刪除復(fù)合索引; 頻繁進(jìn)行數(shù)據(jù)操作的表,不要建立太多的索引; 刪除無用的索引,避免對執(zhí)行計(jì)劃造成負(fù)面影響; 表上建立的每個(gè)索引都會(huì)增加存儲(chǔ)開銷,索引對于插入、刪除、更新操作也會(huì)增加處理上的開銷。另外,過多的復(fù)合索引,在有單字段索引的情況下,一般都是沒有存在價(jià)值的;相反,還會(huì)降低數(shù)據(jù)增加刪除時(shí)的性能,特別是對頻繁更新的表來說,負(fù)面影響更大。 盡量不要對數(shù)據(jù)庫中某個(gè)含有大量重復(fù)的值的字段建立索引。

22、在寫 SQL 語句時(shí),應(yīng)盡量減少空格的使用查詢緩沖并不自動(dòng)處理空格,因此,在寫 SQL 語句時(shí),應(yīng)盡量減少空格的使用,尤其是在 SQL 首和尾的空格(因?yàn)椴樵兙彌_并不自動(dòng)截取首尾空格)。

23、每張表都設(shè)置一個(gè) ID 做為其主鍵我們應(yīng)該為數(shù)據(jù)庫里的每張表都設(shè)置一個(gè) ID 做為其主鍵,而且最好的是一個(gè) INT 型的(推薦使用 UNSIGNED),并設(shè)置上自動(dòng)增加的 AUTO_INCREMENT 標(biāo)志。

24、使用explain分析你SQL執(zhí)行計(jì)劃(1)type

system:表僅有一行,基本用不到; const:表最多一行數(shù)據(jù)配合,主鍵查詢時(shí)觸發(fā)較多; eq_ref:對于每個(gè)來自于前面的表的行組合,從該表中讀取一行。這可能是最好的聯(lián)接類型,除了const類型; ref:對于每個(gè)來自于前面的表的行組合,所有有匹配索引值的行將從這張表中讀取; range:只檢索給定范圍的行,使用一個(gè)索引來選擇行。當(dāng)使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符,用常量比較關(guān)鍵字列時(shí),可以使用range; index:該聯(lián)接類型與ALL相同,除了只有索引樹被掃描。這通常比ALL快,因?yàn)樗饕募ǔ1葦?shù)據(jù)文件小; all:全表掃描; 性能排名:system > const > eq_ref > ref > range > index > all。 實(shí)際sql優(yōu)化中,最后達(dá)到ref或range級別。 (2)Extra常用關(guān)鍵字

Using index:只從索引樹中獲取信息,而不需要回表查詢; Using where:WHERE子句用于限制哪一個(gè)行匹配下一個(gè)表或發(fā)送到客戶。除非你專門從表中索取或檢查所有行,如果Extra值不為Using where并且表聯(lián)接類型為ALL或index,查詢可能會(huì)有一些錯(cuò)誤。需要回表查詢。 Using temporary:mysql常建一個(gè)臨時(shí)表來容納結(jié)果,典型情況如查詢包含可以按不同情況列出列的GROUP BY和ORDER BY子句時(shí);

25、當(dāng)只要一行數(shù)據(jù)時(shí)使用 LIMIT 1 :當(dāng)你查詢表的有些時(shí)候,你已經(jīng)知道結(jié)果只會(huì)有一條結(jié)果,但因?yàn)槟憧赡苄枰etch游標(biāo),或是你也許會(huì)去檢查返回的記錄數(shù)。

在這種情況下,加上 LIMIT 1 可以增加性能。

這樣一來,MySQL 數(shù)據(jù)庫引擎會(huì)在找到一條數(shù)據(jù)后停止搜索,而不是繼續(xù)往后查少下一條符合記錄的數(shù)據(jù)。

26、將大的DELETE,UPDATE、INSERT 查詢變成多個(gè)小查詢能寫一個(gè)幾十行、幾百行的SQL語句是不是顯得逼格很高?然而,為了達(dá)到更好的性能以及更好的數(shù)據(jù)控制,你可以將他們變成多個(gè)小查詢。

27、合理分表 盡量控制單表數(shù)據(jù)量的大小,建議控制在500萬以內(nèi)500萬并不是MySQL數(shù)據(jù)庫的限制,過大會(huì)造成修改表結(jié)構(gòu),備份,恢復(fù)都會(huì)有很大的問題。

可以用歷史數(shù)據(jù)歸檔(應(yīng)用于日志數(shù)據(jù)),分庫分表(應(yīng)用于業(yè)務(wù)數(shù)據(jù))等手段來控制數(shù)據(jù)量大小。

審核編輯 黃宇

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • SQL
    SQL
    +關(guān)注

    關(guān)注

    1

    文章

    763

    瀏覽量

    44124
  • MySQL
    +關(guān)注

    關(guān)注

    1

    文章

    809

    瀏覽量

    26552
收藏 人收藏

    評論

    相關(guān)推薦

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

    數(shù)據(jù)庫執(zhí)行SQL都會(huì)先進(jìn)行語義解析,然后將SQL分成一步一步可執(zhí)行的計(jì)劃,然后逐步執(zhí)行。通過分析執(zhí)行計(jì)劃,我們可以清晰的看到數(shù)據(jù)庫執(zhí)行的操作,這對于數(shù)據(jù)庫SQL優(yōu)化具有重大意義。 1
    的頭像 發(fā)表于 10-09 15:43 ?1045次閱讀
    數(shù)據(jù)庫<b class='flag-5'>SQL</b>的<b class='flag-5'>優(yōu)化</b>

    MySQL的執(zhí)行過程 SQL語句性能優(yōu)化常用策略

    回顧 MySQL 的執(zhí)行過程,幫助介紹如何進(jìn)行 sql 優(yōu)化
    的頭像 發(fā)表于 12-12 10:26 ?658次閱讀
    MySQL的執(zhí)行過程 <b class='flag-5'>SQL</b>語句性能<b class='flag-5'>優(yōu)化</b>常用策略

    Spark SQL的工作原理和性能優(yōu)化

    Spark SQL(九):工作原理和性能優(yōu)化
    發(fā)表于 06-12 16:21

    30種SQL語句優(yōu)化總結(jié)

    必須掌握的30種SQL語句優(yōu)化
    發(fā)表于 04-21 11:38

    數(shù)據(jù)庫設(shè)計(jì)及開發(fā)規(guī)范之sql性能優(yōu)化

    數(shù)據(jù)庫設(shè)計(jì)及開發(fā)規(guī)范,sql性能優(yōu)化
    發(fā)表于 05-08 10:58

    SQL語句怎么優(yōu)化

    SQL語句優(yōu)化——結(jié)合書籍論壇小結(jié)
    發(fā)表于 06-14 14:46

    內(nèi)存條配置優(yōu)化SQL Server服務(wù)器性能

    內(nèi)存條配置優(yōu)化SQL Server服務(wù)器性能  Microsoft SQL Server 2000 的 內(nèi)存管理組件消除了對 SQL Server 可用的內(nèi)存進(jìn)行手工管理的需要。
    發(fā)表于 01-11 11:00 ?1063次閱讀

    PCB優(yōu)化設(shè)計(jì)淺談

    PCB優(yōu)化設(shè)計(jì)淺談,如題。
    發(fā)表于 12-16 21:20 ?0次下載

    SQL后悔藥,SQL性能優(yōu)化SQL規(guī)范優(yōu)雅

    每一個(gè)好習(xí)慣都是一筆財(cái)富,本文基于MySQL,分SQL后悔藥, SQL性能優(yōu)化SQL規(guī)范優(yōu)雅三個(gè)方向,分享寫SQL的21個(gè)好習(xí)慣,謝謝閱讀
    的頭像 發(fā)表于 11-14 09:54 ?1824次閱讀

    30種SQL語句優(yōu)化方法

    SQL查詢中為了提高查詢效率,我們常常會(huì)采取一些措施對查詢語句進(jìn)行SQL優(yōu)化,下面總結(jié)一些方法,供大家參考。 01 對查詢進(jìn)行優(yōu)化,應(yīng)盡量避免全表掃描,首先應(yīng)考慮在 where 及
    的頭像 發(fā)表于 11-19 16:05 ?1996次閱讀

    SQL子查詢優(yōu)化是怎么回事

    子查詢 (Subquery)的優(yōu)化一直以來都是 SQL 查詢優(yōu)化中的難點(diǎn)之一。 關(guān)聯(lián)子查詢的基本執(zhí)行方式類似于 Nested-Loop,但是這種執(zhí)行方式的效率常常低到難以忍受。 當(dāng)數(shù)據(jù)量稍大時(shí),必須
    的頭像 發(fā)表于 02-01 13:55 ?2045次閱讀
    <b class='flag-5'>SQL</b>子查詢<b class='flag-5'>優(yōu)化</b>是怎么回事

    SQL優(yōu)化技巧分享

    一、查詢SQL盡量不要使用select *,而是具體字段
    的頭像 發(fā)表于 09-06 10:24 ?1410次閱讀

    sql優(yōu)化常用的幾種方法

    前言 1.慢SQL優(yōu)化思路。 1.1 慢查詢?nèi)罩居涗浡?b class='flag-5'>SQL 1.2 explain查看分析SQL的執(zhí)行計(jì)劃 1.3 profile 分析執(zhí)行耗時(shí) 1.4 Optimizer Trac
    的頭像 發(fā)表于 11-14 15:04 ?5058次閱讀

    一文終結(jié)SQL子查詢優(yōu)化

    子查詢(Subquery)的優(yōu)化一直以來都是 SQL 查詢優(yōu)化中的難點(diǎn)之一。關(guān)聯(lián)子查詢的基本執(zhí)行方式類似于 Nested-Loop,但是這種執(zhí)行方式的效率常常低到難以忍受。
    的頭像 發(fā)表于 04-28 14:19 ?755次閱讀
    一文終結(jié)<b class='flag-5'>SQL</b>子查詢<b class='flag-5'>優(yōu)化</b>

    Oracle長耗時(shí)SQL優(yōu)化案例

    最近在生產(chǎn)客服平臺(tái),運(yùn)營崗老師反饋,一個(gè)2w人的企業(yè),在信息詳情查詢時(shí),加載時(shí)間過長,越70s左右出結(jié)果,需要后臺(tái)優(yōu)化SQL
    的頭像 發(fā)表于 05-19 15:02 ?1023次閱讀
    主站蜘蛛池模板: 成电影人免费网站| 老师你下面好紧夹死了| 人妖干美女| 在线视频中文字幕| 国产在线视频分类精品| 日本内射精品一区二区视频| 19十主播福利视频| 红桃视频国产AV| 无人区日本电影在线观看高清| qvod电影网| 麻豆精品传媒2021网站入口| 亚洲影院在线播放| 国产欧美无码亚洲| 色欲午夜无码久久久久久| md2.pud 麻豆传媒官网| 麻豆精品一区二正一三区| 一本大道无码AV天堂欧美| 国产亚洲精品久久精品6| 双手绑在床头调教乳尖| 被老头下药玩好爽| 欧美成人免费一区二区三区不卡| 与子敌伦刺激对白亂輪亂性| 精品水蜜桃久久久久久久| 亚洲精品不卡视频| 国产品无码一区二区三区在线| 色综合五月激情综合色一区| 草草久久久亚洲AV成人片| 欧美性狂猛bbbbbbxxxx| 99re热精品视频国产免费| 毛片手机在线观看| 7723手机游戏破解版下载 | 消息称老熟妇乱视频一区二区| 超碰98人人插| 欧美亚洲精品午夜福利AV| ai换脸女明星被躁在线观看免费| 蜜桃传媒在线观看入口| 最近最新中文字幕MV高清在线| 老女老肥熟国产在线视频| 607080老太太AW| 免费啪视频观试看视频| 99国产在线精品观看二区|