婷婷久久综合九色综合,欧美成色婷婷在线观看视频,偷窥视频一区,欧美日本一道道一区二区

<tt id="bu9ss"></tt>
  • <span id="bu9ss"></span>
  • <pre id="bu9ss"><tt id="bu9ss"></tt></pre>
    <label id="bu9ss"></label>

    當(dāng)前位置:首頁 >  站長 >  數(shù)據(jù)庫 >  正文

    分區(qū)表場景下的 SQL 優(yōu)化

     2020-10-19 11:02  來源: 腳本之家   我來投稿 撤稿糾錯(cuò)

      阿里云優(yōu)惠券 先領(lǐng)券再下單

    這篇文章主要介紹了分區(qū)表場景下的 SQL 優(yōu)化,幫助大家更好的理解和學(xué)習(xí)SQL,感興趣的朋友可以了解下

    導(dǎo)讀

    有個(gè)表做了分區(qū),每天一個(gè)分區(qū)。

    該表上有個(gè)查詢,經(jīng)常只查詢表中某一天數(shù)據(jù),但每次都幾乎要掃描整個(gè)分區(qū)的所有數(shù)據(jù),有什么辦法進(jìn)行優(yōu)化嗎?

    待優(yōu)化場景

    有一個(gè)大表,每天產(chǎn)生的數(shù)據(jù)量約100萬,所以就采用表分區(qū)方案,每天一個(gè)分區(qū)。

    下面是該表的DDL:

    CREATE TABLE `t1` (
     `id` bigint(20) NOT NULL AUTO_INCREMENT,
     `date` date NOT NULL,
     `kid` int(11) DEFAULT '0',
     `uid` int(11) NOT NULL,
     `iid` int(11) DEFAULT '0',
     `icnt` int(8) DEFAULT '0',
     `tst` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
     `countp` smallint(11) DEFAULT '1',
     `isr` int(2) NOT NULL DEFAULT '0',
     `clv` int(5) NOT NULL DEFAULT '1',
     PRIMARY KEY (`id`,`date`),
     UNIQUE KEY `date` (`date`,`uid`,`iid`),
     KEY `date_2` (`date`,`kid`)
    ) ENGINE=InnoDB AUTO_INCREMENT=3180686682 DEFAULT CHARSET=utf8mb4
    /*!50500 PARTITION BY RANGE COLUMNS(`date`)
    (PARTITION p20161201 VALUES LESS THAN ('2016-12-02') ENGINE = InnoDB,
     PARTITION p20161202 VALUES LESS THAN ('2016-12-03') ENGINE = InnoDB,
     PARTITION p20161203 VALUES LESS THAN ('2016-12-04') ENGINE = InnoDB,

    該表上經(jīng)常發(fā)生下面的慢查詢:

    SELECT ... FROM `t1` WHERE `date` = '2017-04-01' AND `icnt` > 300 AND `id` = '801301';

    SQL優(yōu)化之路

    SQL優(yōu)化思路

    想要優(yōu)化一個(gè)SQL,一般來說就是先看執(zhí)行計(jì)劃,觀察是否盡可能用到索引,同時(shí)要關(guān)注預(yù)計(jì)掃描的行數(shù),以及是否產(chǎn)生了臨時(shí)表(Using temporary) 或者 是否需要進(jìn)行排序(Using filesort),想辦法消除這些情況。

    更進(jìn)一步的優(yōu)化策略則可能需要調(diào)整程序代碼邏輯,甚至技術(shù)架構(gòu)或者業(yè)務(wù)需求,這個(gè)動(dòng)作比較大,一般非核心系統(tǒng)上的核心問題,不會(huì)這么大動(dòng)干戈,絕大多數(shù)情況,還是需要靠DBA盡可能發(fā)揮聰明才智來解決。

    SQL性能瓶頸定位

    yejr@imysql.com[myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` WHERE
     `date` = '2017-03-02' AND `icnt` > 100 AND `iid` = '502302'\G
    *************************** 1. row ***************************
       id: 1
     select_type: SIMPLE
      table: t1
     partitions: p20170302
       type: range
    possible_keys: date,date_2
       key: date
      key_len: 3
       ref: const
       rows: 9384602
      Extra: Using where

    現(xiàn)在,我們來看下這個(gè)SQL的執(zhí)行計(jì)劃:

    這個(gè)執(zhí)行計(jì)劃看起來還好,有索引可用,也沒臨時(shí)表,也沒filesort。不過,我們也注意到,預(yù)計(jì)要掃描的行數(shù)還是挺多的 rows: 9384602,而且要掃描zheng整個(gè)分區(qū)的所有數(shù)據(jù),難怪效率不高,總是SLOW QUERY。

    優(yōu)化思考

    我們注意到這個(gè)SQL總是要查詢某一天的數(shù)據(jù),這個(gè)表已經(jīng)做了按天分區(qū),那是不是可以忽略 WHERE 子句中的 時(shí)間條件呢?

    還有,既然去掉了 date 條件,反觀表DDL,剩下的條件貌似就沒有合適的索引了吧?

    所以,我們嘗試新建一個(gè)索引:

    yejr@imysql.com[myDB]> ALTER TABLE t1 ADD INDEX iid (iid, icnt);

    然后,把SQL改造成下面這樣,再看下執(zhí)行計(jì)劃:

    yejr@imysql.com[myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` partition(p2017030) WHERE
     `icnt` > 100 AND `iid` = '502302'\G
    *************************** 1. row ***************************
       id: 1
     select_type: SIMPLE
      table: t1
     partitions: p20170302
       type: ref
    possible_keys: date,date_2,iid
       key: iid
      key_len: 10
       ref: const
       rows: 7800
      Extra: Using where
    這優(yōu)化效果,杠杠滴。

    事實(shí)上,如果不強(qiáng)制指定分區(qū)的話,也是可以達(dá)到優(yōu)化效果的:

    yejr@imysql.com[myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` WHERE
     `date` = '2017-03-02' AND `icnt` > 100 AND `iid` = '502302'\G
    *************************** 1. row ***************************
       id: 1
     select_type: SIMPLE
      table: t1
     partitions: p20170302
       type: ref
    possible_keys: date,date_2,iid
       key: iid
      key_len: 10
       ref: NULL
       rows: 7800
      Extra: Using where

    后記

    絕大多數(shù)的SQL通過添加索引、適當(dāng)調(diào)整SQL代碼(例如調(diào)整驅(qū)動(dòng)表順序)等簡單手法來完成。

    多說幾句,遇到SQL優(yōu)化性能瓶頸問題想要在技術(shù)群里請教時(shí),麻煩先提供幾個(gè)必要的信息:

    表DDL

    表常規(guī)統(tǒng)計(jì)信息,可執(zhí)行 SHOW TABLE STATUS LIKE ‘t1' 查看

    表索引分布信息,可執(zhí)行 SHOW INDEX FROM t1 查看

    有問題的SQL及相應(yīng)的執(zhí)行計(jì)劃 沒有這些信息的話,就別去麻煩別人了吧。

    以上就是分區(qū)表場景下的 SQL 優(yōu)化的詳細(xì)內(nèi)容,更多關(guān)于sql分區(qū)表優(yōu)化的資料請關(guān)注腳本之家其它相關(guān)文章!

    來源:腳本之家

    鏈接:https://www.jb51.net/article/193531.htm

    申請創(chuàng)業(yè)報(bào)道,分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處,共同探討創(chuàng)業(yè)新機(jī)遇!

    相關(guān)標(biāo)簽
    sql優(yōu)化

    相關(guān)文章

    • UCloud高可用數(shù)據(jù)庫UDB主從復(fù)制延時(shí)的解決

      MySQL主從復(fù)制的延時(shí)一直是業(yè)界困擾已久的問題。延時(shí)的出現(xiàn)會(huì)降低主從讀寫分離的價(jià)值,不利于數(shù)據(jù)實(shí)時(shí)性較高的業(yè)務(wù)使用MySQL。UDB是UCloud推出的云數(shù)據(jù)庫服務(wù),上線已達(dá)六年,運(yùn)營了數(shù)以萬計(jì)的UDBMySQL實(shí)例

    • 如何修復(fù)網(wǎng)站漏洞之metinfo遠(yuǎn)程SQL注入漏洞

      2018年11月23日SINE網(wǎng)站安全檢測平臺(tái),檢測到MetInfo最新版本爆出高危漏洞,危害性較大,影響目前MetInfo5.3版本到最新的MetInfo6.1.3版本,該網(wǎng)站漏洞產(chǎn)生的主要原因是MetInfo的上傳代碼里的參數(shù)值沒有進(jìn)行安全過濾,導(dǎo)致上傳路徑這里進(jìn)行偽造路徑,并可以插入惡意的代碼

    • 虛擬主機(jī)mysql數(shù)據(jù)庫三種導(dǎo)入方法

      在導(dǎo)入mysql數(shù)據(jù)庫操作時(shí)通常會(huì)出現(xiàn)一些錯(cuò)誤導(dǎo)致數(shù)據(jù)庫導(dǎo)入失敗,這里以老牌虛擬主機(jī)提供商第一主機(jī)(http://www.5778.com)的虛擬空間為例,演示介紹三種mysql數(shù)據(jù)庫的正確導(dǎo)入方法。1、采用phpmyadmin導(dǎo)入:虛擬主機(jī)接入商在提供mysql數(shù)據(jù)庫的同時(shí)都會(huì)配備phpmyadm

      標(biāo)簽:
      sql優(yōu)化
    • MySQL技術(shù)嘉年華會(huì)2016即將召開

      會(huì)議通知大會(huì)簡介2016年MySQL技術(shù)嘉年華將于2016年04月24日在上海舉行,本次大會(huì)由IMG(InsideMySQLGroup)社區(qū)主辦,專注于MySQL數(shù)據(jù)庫最佳應(yīng)用與實(shí)踐的技術(shù)分享,將為數(shù)據(jù)庫技術(shù)愛好者、應(yīng)用開發(fā)人員、企業(yè)架構(gòu)師們帶來最具技術(shù)價(jià)值的饕餮大餐。毫無疑問,MySQL是最為流行

      標(biāo)簽:
      sql優(yōu)化
    • linux下配置開發(fā)環(huán)境,mysql+jdk+tomcat教程全解

      linux下配置開發(fā)環(huán)境,mysql+jdk+tomcat教程全解最近由于自己開發(fā)需要,就下手租了一臺(tái)服務(wù)器,系統(tǒng)版本是centos6.5,64位機(jī)器。在配置環(huán)境的時(shí)候在網(wǎng)上找了半天也沒有發(fā)現(xiàn)比較全的開發(fā)環(huán)境配置方法,于是把自己的配置方法發(fā)上來以供大家交流學(xué)習(xí)。首先安裝JDK:在oracle網(wǎng)站下載

      標(biāo)簽:
      sql優(yōu)化

    熱門排行

    信息推薦