无语的indexhint：手工分配哈希区，5小时不出结果，优化后20分钟-mysql教程-PHP中文網

首頁

資料庫

mysql教程

无语的indexhint：手工分配哈希区，5小时不出结果，优化后20分钟

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 04:06 PM

分配

同事发来一个语句，说5个小时不出结果，我滴个神呀，想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道，一看吓一跳，3个表关联，强制使用了2个index hint，其中一个表9g，一个表67g，还有一个小表40Mb。无知的开发人员，以为走index就是快的，

同事发来一个语句，说5个小时不出结果，我滴个神呀，想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道，一看吓一跳，3个表关联，强制使用了2个index hint，其中一个表9g，一个表67g，还有一个小表40Mb。无知的开发人员，以为走index就是快的，哎。。。
下面是同事发来的语句： 
select /*+  parallel(t,4) index(a,IDX_COMMBASUBSHIST_1) index(b,IDX_COMMCMSERVHIST_1)*/
    1,
    t.DISC_ID,
    t.DISC_LEV,
    to_date(20140117082042, &#39;yyyymmddhh24miss&#39;),
    t.MSINFO_ID,
    t.ORG_ID,
    t.SERV_ID,
    t.SUBS_ID,
    t.OBJ_GRP_ID,
    a.SUBS_CODE,
    a.SUBS_STAT,
    a.SUBS_STAT_REASON,
    a.SUBS_STAT_DATE,
    a.ACTION_ID,
    a.ACTION_TYPE,
    a.ACTION_EX_TYPE,
    a.ACT_DATE,
    a.REQ_ID,
    a.STAFF_ID,
    a.CMMS_CUST_CODE,
    a.SPEED_VALUE,
    b.ACC_NBR,
    b.CUST_ID,
    b.SERV_NBR,
    b.CONSUME_GRADE,
    b.SERV_LEV,
    b.ACCOUNT_NBR,
    b.CITY_VILLAGE_ID,
    b.SERV_CHANNEL_ID,
    b.SERV_STAT_ID,
    b.CUST_CLASS_DL,
    b.CUST_TYPE_ID,
    b.USER_TYPE,
    b.USER_CHAR,
    b.PAYMENT_TYPE,
    b.BILLING_TYPE,
    b.PROD_ID,
    b.PROD_CAT_ID,
    b.EXCHANGE_ID,
    b.SERV_COL1,
    b.SERV_COL2,
    b.AREA_ID,
    b.SUBST_ID,
    b.BRANCH_ID,
    b.STOP_TYPE,
    b.CUST_MANAGER_ID,
    b.CREATE_DATE,
    b.ADDRESS_ID,
    b.SUBS_DATE,
    b.OPEN_DATE,
    b.MODI_STAFF_ID,
    b.CMMS_CUST_ID,
    b.CUST_NAME,
    b.SALES_ID,
    b.SALES_TYPE_ID,
    b.SERV_ADDR_ID,
    t.HIST_CREATE_DATE,
    b.ARREAR_MONTH,
    b.ARREAR_MONTH_LAST,
    t.SALESTAFF_ID,
    t.EHOME_TYPE,
    t.EHOME_CLASS,
    b.strat_grp_dl,
    b.sale_org1,
    b.sale_org2,
    b.sale_org3,
    b.location_type,
    b.region_flag,
    b.terminal_id,
    b.pstn_id,
    b.fee_id,
    b.payment_id,
    b.billing_id,
    b.strat_grp_xl,
    b.fld1,
    b.fld3,
    b.cust_level,
    b.group_cust_type,
    b.cust_region,
    b.group_cust_grade,
    b.control_level,
    b.net_connect_type,
    b.trade_type_id,
    b.acc_nbr2,
    b.cdma_class_id,
    b.phone_number_id,
    b.develop_channel,
    b.online_time,
    t.wireless_type,
    b.new_serv_stat_id,
    b.is_phs_tk,
    b.serv_grp_type,
    b.state,
    t.cdma_disc_type,
    b.mix_disc,
    b.is_3g,
    t.add_disc_type,
    to_number(nvl(b.business_type, &#39;-1&#39;)),
    nvl(t.label_num, -1),
    b.is_mix_prod,
    t.price_id,
    t.disc_item_id,
    b.STD_SUBST_ID,
    b.STD_BRANCH_ID,
    t.DISC_ITEM_ID_OP,
    t.PRICE_ID_OP,
    t.business_type,
    b.new_prod_id,
    b.BOARD_SUBST_ID,
    b.BOARD_BRANCH_ID
     from RPT_COMM_BA_SUBS_HIST  a,
          RPT_COMM_CM_SERV_HIST  b,
          TB_COMM_BA_MSDISC_TEMP t
    where a.subs_id = t.subs_id
      and b.serv_id = t.serv_id



--同事说开销比较大。有450W。。下面是执行计划：
<img src="/static/imghw/default1.png"  data-src="http://img.blog.csdn.net/20141025102001913?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZ2RtemxoajE=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center"  class="lazy" alt="" />
 
/*
涉及的表大小：
OWNER	SEGMENT_NAME	SEGMENT_TYPE	Size(Mb)
SUMMARY_SJZ_GZ	TB_COMM_BA_MSDISC_TEMP	TABLE	40
SUMMARY_SJZ_GZ	RPT_COMM_CM_SERV_HIST	TABLE PARTITION	9016.1875
SUMMARY_SJZ_GZ	RPT_COMM_BA_SUBS_HIST	TABLE PARTITION	67330.25

以下是优化思路：
强制使用索引，导致其中9g的表走了index full scan，然后回表。因为除了index fast scan以外，其他索引扫描都是单块读，回表又是单块读。导致速度非常慢。优化时考虑使用哈希连接，40Mb的小表作为驱动表，连接9g的表，最后连接超大的67G的表。
优化时使用的技术：
1.	use_hash（a，b），使用哈希表关联方式
2.	/*+parallel(a 5)*/;并行处理
3.	db_file_multiblock_read_count多块读参数设置为最大
4.	workarea_size_policy设置为手工管理
5.	sort_area_size设为接近最大
6.        hash_area_size设为接近最大

<p>5小时不出结果，优化后20分钟不到出结果，就是这么神奇。</p><p>alter session enable parallel dml;
alter session set workarea_size_policy=manual;
alter session set sort_area_size=2100000000;
alter session set hash_area_size=2100000000;
alter session set db_file_multiblock_read_count=128;




select &#160;/*+parallel(a,5) parallel(b,5) parallel(t,5) leading(t) use_hash(t,b) user_hash(b,a)*/
&#160; &#160; &#160;1,
&#160; &#160; t.DISC_ID,
&#160; &#160; t.DISC_LEV,
&#160; &#160; to_date(20140117082042, &#39;yyyymmddhh24miss&#39;),
&#160; &#160; t.MSINFO_ID,
&#160; &#160; t.ORG_ID,
&#160; &#160; t.SERV_ID,
&#160; &#160; t.SUBS_ID,
&#160; &#160; t.OBJ_GRP_ID,
&#160; &#160; a.SUBS_CODE,
&#160; &#160; a.SUBS_STAT,
&#160; &#160; a.SUBS_STAT_REASON,
&#160; &#160; a.SUBS_STAT_DATE,
&#160; &#160; a.ACTION_ID,
&#160; &#160; a.ACTION_TYPE,
&#160; &#160; a.ACTION_EX_TYPE,
&#160; &#160; a.ACT_DATE,
&#160; &#160; a.REQ_ID,
&#160; &#160; a.STAFF_ID,
&#160; &#160; a.CMMS_CUST_CODE,
&#160; &#160; a.SPEED_VALUE,
&#160; &#160; b.ACC_NBR,
&#160; &#160; b.CUST_ID,
&#160; &#160; b.SERV_NBR,
&#160; &#160; b.CONSUME_GRADE,
&#160; &#160; b.SERV_LEV,
&#160; &#160; b.ACCOUNT_NBR,
&#160; &#160; b.CITY_VILLAGE_ID,
&#160; &#160; b.SERV_CHANNEL_ID,
&#160; &#160; b.SERV_STAT_ID,
&#160; &#160; b.CUST_CLASS_DL,
&#160; &#160; b.CUST_TYPE_ID,
&#160; &#160; b.USER_TYPE,
&#160; &#160; b.USER_CHAR,
&#160; &#160; b.PAYMENT_TYPE,
&#160; &#160; b.BILLING_TYPE,
&#160; &#160; b.PROD_ID,
&#160; &#160; b.PROD_CAT_ID,
&#160; &#160; b.EXCHANGE_ID,
&#160; &#160; b.SERV_COL1,
&#160; &#160; b.SERV_COL2,
&#160; &#160; b.AREA_ID,
&#160; &#160; b.SUBST_ID,
&#160; &#160; b.BRANCH_ID,
&#160; &#160; b.STOP_TYPE,
&#160; &#160; b.CUST_MANAGER_ID,
&#160; &#160; b.CREATE_DATE,
&#160; &#160; b.ADDRESS_ID,
&#160; &#160; b.SUBS_DATE,
&#160; &#160; b.OPEN_DATE,
&#160; &#160; b.MODI_STAFF_ID,
&#160; &#160; b.CMMS_CUST_ID,
&#160; &#160; b.CUST_NAME,
&#160; &#160; b.SALES_ID,
&#160; &#160; b.SALES_TYPE_ID,
&#160; &#160; b.SERV_ADDR_ID,
&#160; &#160; t.HIST_CREATE_DATE,
&#160; &#160; b.ARREAR_MONTH,
&#160; &#160; b.ARREAR_MONTH_LAST,
&#160; &#160; t.SALESTAFF_ID,
&#160; &#160; t.EHOME_TYPE,
&#160; &#160; t.EHOME_CLASS,
&#160; &#160; b.strat_grp_dl,
&#160; &#160; b.sale_org1,
&#160; &#160; b.sale_org2,
&#160; &#160; b.sale_org3,
&#160; &#160; b.location_type,
&#160; &#160; b.region_flag,
&#160; &#160; b.terminal_id,
&#160; &#160; b.pstn_id,
&#160; &#160; b.fee_id,
&#160; &#160; b.payment_id,
&#160; &#160; b.billing_id,
&#160; &#160; b.strat_grp_xl,
&#160; &#160; b.fld1,
&#160; &#160; b.fld3,
&#160; &#160; b.cust_level,
&#160; &#160; b.group_cust_type,
&#160; &#160; b.cust_region,
&#160; &#160; b.group_cust_grade,
&#160; &#160; b.control_level,
&#160; &#160; b.net_connect_type,
&#160; &#160; b.trade_type_id,
&#160; &#160; b.acc_nbr2,
&#160; &#160; b.cdma_class_id,
&#160; &#160; b.phone_number_id,
&#160; &#160; b.develop_channel,
&#160; &#160; b.online_time,
&#160; &#160; t.wireless_type,
&#160; &#160; b.new_serv_stat_id,
&#160; &#160; b.is_phs_tk,
&#160; &#160; b.serv_grp_type,
&#160; &#160; b.state,
&#160; &#160; t.cdma_disc_type,
&#160; &#160; b.mix_disc,
&#160; &#160; b.is_3g,
&#160; &#160; t.add_disc_type,
&#160; &#160; to_number(nvl(b.business_type, &#39;-1&#39;)),
&#160; &#160; nvl(t.label_num, -1),
&#160; &#160; b.is_mix_prod,
&#160; &#160; t.price_id,
&#160; &#160; t.disc_item_id,
&#160; &#160; b.STD_SUBST_ID,
&#160; &#160; b.STD_BRANCH_ID,
&#160; &#160; t.DISC_ITEM_ID_OP,
&#160; &#160; t.PRICE_ID_OP,
&#160; &#160; t.business_type,
&#160; &#160; b.new_prod_id,
&#160; &#160; b.BOARD_SUBST_ID,
&#160; &#160; b.BOARD_BRANCH_ID
&#160; &#160; &#160;from SUMMARY_SJZ_GZ.RPT_COMM_BA_SUBS_HIST &#160;a,
&#160; &#160; &#160; &#160; &#160; SUMMARY_SJZ_GZ.RPT_COMM_CM_SERV_HIST &#160;b,
&#160; &#160; &#160; &#160; &#160; SUMMARY_SJZ_GZ.TB_COMM_BA_MSDISC_TEMP t
&#160; &#160; where a.subs_id = t.subs_id
&#160; &#160; &#160; and b.serv_id = t.serv_id
</p>

登入後複製

本網站聲明

本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn

熱AI工具

熱工具

熱門話題

gmail信箱登陸入口在哪裡

7870

Java教學

1649

CakePHP 教程

1407

Laravel 教程

1301

PHP教程

1244

Related knowledge

與MySQL中使用索引相比，全表掃描何時可以更快？ Apr 09, 2025 am 12:05 AM

全表掃描在MySQL中可能比使用索引更快，具體情況包括：1)數據量較小時；2)查詢返回大量數據時；3)索引列不具備高選擇性時；4)複雜查詢時。通過分析查詢計劃、優化索引、避免過度索引和定期維護表，可以在實際應用中做出最優選擇。

可以在 Windows 7 上安裝 mysql 嗎 Apr 08, 2025 pm 03:21 PM

是的，可以在 Windows 7 上安裝 MySQL，雖然微軟已停止支持 Windows 7，但 MySQL 仍兼容它。不過，安裝過程中需要注意以下幾點：下載適用於 Windows 的 MySQL 安裝程序。選擇合適的 MySQL 版本（社區版或企業版）。安裝過程中選擇適當的安裝目錄和字符集。設置 root 用戶密碼，並妥善保管。連接數據庫進行測試。注意 Windows 7 上的兼容性問題和安全性問題，建議升級到受支持的操作系統。

說明InnoDB全文搜索功能。 Apr 02, 2025 pm 06:09 PM

InnoDB的全文搜索功能非常强大，能够显著提高数据库查询效率和处理大量文本数据的能力。1）InnoDB通过倒排索引实现全文搜索，支持基本和高级搜索查询。2）使用MATCH和AGAINST关键字进行搜索，支持布尔模式和短语搜索。3）优化方法包括使用分词技术、定期重建索引和调整缓存大小，以提升性能和准确性。

mysql：簡單的概念，用於輕鬆學習 Apr 10, 2025 am 09:29 AM

MySQL是一個開源的關係型數據庫管理系統。 1）創建數據庫和表：使用CREATEDATABASE和CREATETABLE命令。 2）基本操作：INSERT、UPDATE、DELETE和SELECT。 3）高級操作：JOIN、子查詢和事務處理。 4）調試技巧：檢查語法、數據類型和權限。 5）優化建議：使用索引、避免SELECT*和使用事務。

InnoDB中的聚類索引和非簇索引（次級索引）之間的差異。 Apr 02, 2025 pm 06:25 PM

聚集索引和非聚集索引的區別在於：1.聚集索引將數據行存儲在索引結構中，適合按主鍵查詢和範圍查詢。 2.非聚集索引存儲索引鍵值和數據行的指針，適用於非主鍵列查詢。

mysql 和 mariadb 可以共存嗎 Apr 08, 2025 pm 02:27 PM

MySQL 和 MariaDB 可以共存，但需要謹慎配置。關鍵在於為每個數據庫分配不同的端口號和數據目錄，並調整內存分配和緩存大小等參數。連接池、應用程序配置和版本差異也需要考慮，需要仔細測試和規劃以避免陷阱。在資源有限的情況下，同時運行兩個數據庫可能會導致性能問題。

mysql用戶和數據庫的關係 Apr 08, 2025 pm 07:15 PM

MySQL 數據庫中，用戶和數據庫的關係通過權限和表定義。用戶擁有用戶名和密碼，用於訪問數據庫。權限通過 GRANT 命令授予，而表由 CREATE TABLE 命令創建。要建立用戶和數據庫之間的關係，需創建數據庫、創建用戶，然後授予權限。

RDS MySQL 與 Redshift 零 ETL 集成 Apr 08, 2025 pm 07:06 PM

數據集成簡化：AmazonRDSMySQL與Redshift的零ETL集成高效的數據集成是數據驅動型組織的核心。傳統的ETL（提取、轉換、加載）流程複雜且耗時，尤其是在將數據庫（例如AmazonRDSMySQL）與數據倉庫（例如Redshift）集成時。然而，AWS提供的零ETL集成方案徹底改變了這一現狀，為從RDSMySQL到Redshift的數據遷移提供了簡化、近乎實時的解決方案。本文將深入探討RDSMySQL零ETL與Redshift集成，闡述其工作原理以及為數據工程師和開發者帶來的優勢。

See all articles

无语的indexhint：手工分配哈希区，5小时不出结果，优化后20分钟

熱AI工具

Undresser.AI Undress

AI Clothes Remover

Undress AI Tool

Clothoff.io

Video Face Swap

熱門文章

熱工具

記事本++7.3.1

SublimeText3漢化版

禪工作室 13.0.1

Dreamweaver CS6

SublimeText3 Mac版

熱門話題