堆棧內存溢出
  簡體   English   中英

如何在MySQL中使用LEFT JOIN優化SELECT INTO OUTFILE查詢

[英]How to Optimize SELECT INTO OUTFILE query with LEFT JOIN in MySQL

 原文  2018-02-21 19:33:46  0   2    mysql/ innodb/ myisam/ into-outfile

問題描述

我在具有445萬行的表上的查詢下方運行，查詢需要15到20分鍾才能完成操作。 我也嘗試過將引擎從Innodb更改為MyISAM，但沒有任何效果。 我也嘗試添加多個具有正常和唯一類型的索引，但是仍然需要花費相同的時間。

這是我的查詢： 

SELECT 
a.source, a.destination, a.forward_to, a.start_epoch, a.end_epoch, a.duration, a.billsec, a.outbound_billsec, a.pool_id, a.group_id, a.cost, a.outbound_cost, a.net, a.keep, a.payin, a.payout, a.campaign_id, a.buyer, a.hangup_cause, a.endpoint_disposition, a.uuid, a.agreement, a.agreement_type, a.contract, a.contract_type, a.sip_received_ip,a.termination_ip, 
REPLACE(REPLACE(ifnull(b.line_type,''),'\n',' '),'\r',' ') AS line_type, 
REPLACE(REPLACE(ifnull(b.ocn,''),'\n',' '),'\r',' ') AS ocn, 
REPLACE(REPLACE(ifnull(b.spid_carrier_name,''),'\n',' '),'\r',' ') AS spid_carrier_name 
INTO OUTFILE '/tmp/test-husnain01' 
FIELDS TERMINATED BY ',' FROM inbound_022018 a 
LEFT JOIN wireless_checks b ON (a.uuid = b.uuid) 
WHERE date(a.start_epoch)='2018-02-19' AND 
a.endpoint_disposition='ANSWER' AND 
a.direction='inbound' AND 
a.billed=1;

以下是我的表結構（inbound_022018）： 

      CREATE TABLE `inbound_022018` (
        `id` int(11) NOT NULL AUTO_INCREMENT,
        `source` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `destination` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `prefix` int(22) NOT NULL,
        `forward_to` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `supplier` varchar(32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `agreement` int(11) NOT NULL,
        `agreement_type` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `payout` float(11,4) NOT NULL,
        `pool_id` int(11) NOT NULL,
        `group_id` int(11) NOT NULL,
        `campaign_id` bigint(22) NOT NULL,
        `lead` int(1) NOT NULL,
        `cpl` float(11,4) NOT NULL,
        `buyer` varchar(32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `contract` int(11) NOT NULL,
        `contract_type` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `payin` float(11,4) NOT NULL,
        `gross` float(11,4) NOT NULL,
        `cost` float(11,4) NOT NULL,
        `outbound_cost` float(11,4) NOT NULL,
        `net` float(11,4) NOT NULL,
        `keep` float(11,4) NOT NULL,
        `direction` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `session_id` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `uuid` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `sip_from_uri` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `sip_received_ip` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `domain_name` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `sip_req_uri` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `endpoint_disposition` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `hangup_cause` varchar(80) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `hangup_cause_q850` varchar(80) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
        `start_epoch` datetime DEFAULT NULL,
        `answer_epoch` datetime DEFAULT NULL,
        `bridge_epoch` datetime DEFAULT NULL,
        `progress_epoch` datetime DEFAULT NULL,
        `progress_media_epoch` datetime NOT NULL,
        `end_epoch` datetime NOT NULL,
        `digits_dialed` varchar(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `last_app` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `last_arg` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `duration` int(11) NOT NULL,
        `g30` int(1) DEFAULT NULL,
        `billsec` int(11) NOT NULL,
        `outbound_duration` int(11) NOT NULL,
        `outbound_billsec` int(11) NOT NULL,
        `progresssec` int(11) NOT NULL,
        `answersec` int(11) NOT NULL,
        `waitsec` int(11) NOT NULL,
        `progress_mediasec` int(11) NOT NULL,
        `flow_billsec` int(11) NOT NULL,
        `sip_hangup_disposition` int(11) NOT NULL,
        `callForwarded` varchar(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `forwardUuid` varchar(40) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `call_type` enum('s','v') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 's',
        `billed` int(1) NOT NULL,
        `uc` int(1) NOT NULL,
        `suc` int(1) NOT NULL,
        `callinfo` varchar(250) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `termination_ip` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `switchname` varchar(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
        `org_charges` float(11,4) NOT NULL,
        `call_summary` text,
        PRIMARY KEY (`id`),
        UNIQUE KEY `index_inbound_0717` (`id`) USING BTREE,
        UNIQUE KEY `index_uuid` (`uuid`) USING BTREE,
        UNIQUE KEY `index_all` (`id`,`campaign_id`,`session_id`,`uuid`) USING BTREE,
        KEY `index_source` (`source`) USING BTREE,
        KEY `index_destination` (`destination`) USING BTREE,
        KEY `index_endpoint` (`endpoint_disposition`) USING BTREE,
        KEY `index_build` (`billed`) USING BTREE,
        KEY `index_campainid` (`campaign_id`) USING BTREE
      ) ENGINE=MyISAM AUTO_INCREMENT=4457485 DEFAULT CHARSET=latin1

這是第二張表（wireless_checks）： 

         CREATE TABLE `wireless_checks` (
        `id` int(22) NOT NULL AUTO_INCREMENT,
        `date` varchar(10) NOT NULL,
        `uuid` varchar(100) NOT NULL,
        `tn` varchar(11) NOT NULL,
        `lrn` varchar(11) NOT NULL,
        `ported_status` varchar(2) NOT NULL,
        `ported_date` varchar(11) NOT NULL,
        `ocn` varchar(10) NOT NULL,
        `line_type` int(1) NOT NULL,
        `spid` varchar(10) NOT NULL,
        `spid_carrier_name` varchar(100) NOT NULL,
        `spid_carrier_type` varchar(10) NOT NULL,
        `altspid_carrier_name` varchar(10) NOT NULL,
        `altspid_carrier_type` varchar(10) NOT NULL,
        PRIMARY KEY (`id`),
        UNIQUE KEY `index_uuid` (`uuid`) USING BTREE
      ) ENGINE=MyISAM AUTO_INCREMENT=36175 DEFAULT CHARSET=latin1

請指導我如何優化此查詢以減少執行時間。 如果還有其他方法可以解決此問題，我也很樂意解決。 任何幫助將不勝感激。

謝謝

侯賽因

2 個解決方案

解決方案1
 0  2018-02-21 19:48:57

應該有所作為的一個技巧是 

WHERE date(a.start_epoch)='2018-02-19'

您應該考慮預先計算，然后使用實際值，即1518998400

這是一個危險信號，原因是通過將一個函數放在比較的左側，您將迫使數據庫執行全表掃描，在所有4.45m行上運行該函數，僅用於處理WHERE子句。 相反，如果不使用DATE函數就將列本身與實際值進行比較，則MySQL可以更有效地優化查詢，並且將在a.start_epoch上使用索引（如果有）。

要創建該索引，只需 

CREATE INDEX epoch_idx on inbound_022018(start_epoch)

更廣泛地講，您應該針對值分布范圍較大（不僅有1或2種可能性）的列創建索引，並且多列索引可以幫助優化復雜的查詢。

將EXPLAIN放在查詢的前面，並查看特別大的行號的結果，是確定成本在查詢中的位置的好方法。 通常，有效的索引編制可以解決此問題。

解決方案2
 0  2018-03-04 00:06:24

SELECT INTO OUTFILE不是問題。 許多其他因素正在減慢查詢速度。

以下是我需要討論的片段： 

    FROM  inbound_022018 a
    LEFT JOIN  wireless_checks b  ON (a.uuid = b.uuid)
    WHERE  date(a.start_epoch)='2018-02-19'
      AND  a.endpoint_disposition='ANSWER'
      AND  a.direction='inbound'
      AND  a.billed=1;

    `uuid` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,

    `uuid` varchar(100) NOT NULL ... DEFAULT CHARSET=latin1

    float(11,4)

    `date` varchar(10) NOT NULL, ...
    `ported_date` varchar(11) NOT NULL,

    PRIMARY KEY (`id`),
    UNIQUE KEY `index_inbound_0717` (`id`) USING BTREE,

    PRIMARY KEY (`id`), ...
    UNIQUE KEY `index_all` (`id`,`campaign_id`,`session_id`,`uuid`) USING BTREE,

很多問題：

  • UUID眾所周知是“隨機的”。 您的桌子有多大？ 如果它們大於緩存在RAM中的內存，則該查詢注定會非常緩慢。
  • 比較兩個字符串（ a.uuid = b.uuid ）時，如果字符集或排序規則不同，則不能使用索引。 解決這個。
  • 從字符串轉換為BINARY(16)甚至更小。 （代碼可在其他地方獲得。）
  • 除非有特殊之處，否則UUID可以是`CHAR（26）CHARSET ascii。 這清理了幾件事。
  • 表a需要復合INDEX(billed, direction, endpoint_disposition, start_epoch) ，以提高WHERE效率。 前3列可以按任何順序排列。
  • 如下所述更改日期測試。
  • PRIMARY KEY是UNIQUE鍵； 刪除后者。
  • FLOAT(m,n)是無用的構造，因為它涉及兩個舍入。 對於貨幣值，請使用DECIMAL(m,n) ； 對於“科學”值，請使用不帶(m,n) FLOAT 。
  • 從PK的所有列開始都有輔助鍵幾乎是無效的。 （好的，MyISAM可能會受益，但是InnoDB很少受益。）
  • 如果您在任何地方都不需要b.id ，請擺脫它並把uuid升級為PK。 這將加速InnoDB的JOIN 。
  • 除非您有充分的理由，否則不要將日期放在VARCHAR 。
  • 不要使用MyISAM； 解決我在這里討論的問題。 然后，如有需要，請返回進行進一步討論。

當某個列在函數（例如DATE() ）中被“隱藏”時，對該列進行索引將無濟於事。 改成 

WHERE  a.start_epoch >= '2018-02-19'
  AND  a.start_epoch  < '2018-02-19' + INTERVAL 1 DAY

進行此更改后，我建議的INDEX的第4列將可用。

暫無
暫無

聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

相關問題 如何使用主查詢中的LEFT JOIN和子查詢中的INNER JOIN優化MySQL SELECT查詢？ MySQL優化平均，求和查詢已離開聯接嵌套選擇 如何優化左連接查詢？ Mysql left join with nested select 慢，如何優化 如何優化這個mysql查詢（max，replace，left join）？ 如何在左連接上使用大數據優化MySQL查詢？ MySQL-Left Join需要太長時間，如何優化查詢？ 嘗試使用LEFT OUTER JOIN優化MySQL查詢 在INSERT MySQL查詢中選擇INOUT OUTFILE MySQL選擇與左聯接查詢
相關標簽
 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM