无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟
同事发来一个语句,说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, 'yyyymmddhh24miss'), 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, '-1')), 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  /*+parallel(a,5) parallel(b,5) parallel(t,5) leading(t) use_hash(t,b) user_hash(b,a)*/      1,     t.DISC_ID,     t.DISC_LEV,     to_date(20140117082042, 'yyyymmddhh24miss'),     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, '-1')),     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 SUMMARY_SJZ_GZ.RPT_COMM_BA_SUBS_HIST  a,           SUMMARY_SJZ_GZ.RPT_COMM_CM_SERV_HIST  b,           SUMMARY_SJZ_GZ.TB_COMM_BA_MSDISC_TEMP t     where a.subs_id = t.subs_id       and b.serv_id = t.serv_id </p>

热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

Video Face Swap
使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸!

热门文章

热工具

记事本++7.3.1
好用且免费的代码编辑器

SublimeText3汉化版
中文版,非常好用

禅工作室 13.0.1
功能强大的PHP集成开发环境

Dreamweaver CS6
视觉化网页开发工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

全表扫描在MySQL中可能比使用索引更快,具体情况包括:1)数据量较小时;2)查询返回大量数据时;3)索引列不具备高选择性时;4)复杂查询时。通过分析查询计划、优化索引、避免过度索引和定期维护表,可以在实际应用中做出最优选择。

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

是的,可以在 Windows 7 上安装 MySQL,虽然微软已停止支持 Windows 7,但 MySQL 仍兼容它。不过,安装过程中需要注意以下几点:下载适用于 Windows 的 MySQL 安装程序。选择合适的 MySQL 版本(社区版或企业版)。安装过程中选择适当的安装目录和字符集。设置 root 用户密码,并妥善保管。连接数据库进行测试。注意 Windows 7 上的兼容性问题和安全性问题,建议升级到受支持的操作系统。

MySQL是一个开源的关系型数据库管理系统。1)创建数据库和表:使用CREATEDATABASE和CREATETABLE命令。2)基本操作:INSERT、UPDATE、DELETE和SELECT。3)高级操作:JOIN、子查询和事务处理。4)调试技巧:检查语法、数据类型和权限。5)优化建议:使用索引、避免SELECT*和使用事务。

聚集索引和非聚集索引的区别在于:1.聚集索引将数据行存储在索引结构中,适合按主键查询和范围查询。2.非聚集索引存储索引键值和数据行的指针,适用于非主键列查询。

MySQL 和 MariaDB 可以共存,但需要谨慎配置。关键在于为每个数据库分配不同的端口号和数据目录,并调整内存分配和缓存大小等参数。连接池、应用程序配置和版本差异也需要考虑,需要仔细测试和规划以避免陷阱。在资源有限的情况下,同时运行两个数据库可能会导致性能问题。

MySQL 数据库中,用户和数据库的关系通过权限和表定义。用户拥有用户名和密码,用于访问数据库。权限通过 GRANT 命令授予,而表由 CREATE TABLE 命令创建。要建立用户和数据库之间的关系,需创建数据库、创建用户,然后授予权限。

MySQL支持四种索引类型:B-Tree、Hash、Full-text和Spatial。1.B-Tree索引适用于等值查找、范围查询和排序。2.Hash索引适用于等值查找,但不支持范围查询和排序。3.Full-text索引用于全文搜索,适合处理大量文本数据。4.Spatial索引用于地理空间数据查询,适用于GIS应用。
