字段类型不一致导致的全表扫描

最新推荐文章于 2021-08-13 11:02:16 发布
最新推荐文章于 2021-08-13 11:02:16 发布
阅读量877 收藏
点赞数
分类专栏： Oracle数据库 文章标签： 数据库 优化 性能
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liannoy/article/details/39152597
版权

销售订单优化报告

监控后台语句

UPDATE T_SD_SaleOrderEntry

   SET (FOrderedQty, FUnOrderedQty) =

       (SELECT (ROUND(CAST((poe.FBaseQty / NVL(FBaseConvsRate,1)) AS

                           NUMBER(28,16)),

                     mu.FQtyPrecision) + T_SD_SaleOrderEntry.FOrderedQty) FORDEREDQTY,

              (T_SD_SaleOrderEntry.FQty -

               (ROUND(CAST((poe.FBaseQty /NVL(FBaseConvsRate,1)) AS

                            NUMBER(28,16)),

                      mu.FQtyPrecision) + T_SD_SaleOrderEntry.FOrderedQty)) FUNORDEREDQTY

          FROM T_SM_PurOrderEntry POE

          LEFTOUTERJOIN T_BD_MultiMeasureUnit MU

            ON poe.FMaterialID = mu.FMaterialID

         WHERE (poe.FSourceBillEntryID =T_SD_SaleOrderEntry.FIDAND

               (((poe.FParentID IN ('LlBN+WXBSsiRN5zSo9wMfjFxv60='))AND

              T_SD_SaleOrderEntry.FMaterialID = poe.FMaterialID)AND

              T_SD_SaleOrderEntry.FUnitID = mu.FMeasureUnitID)))

 WHERE T_SD_SaleOrderEntry.FIDIN

       (SELECT T_SD_SaleOrderEntry.FID

          FROM T_SD_SaleOrderEntry,T_SM_PurOrderEntry POE

          LEFTOUTERJOIN T_BD_MultiMeasureUnit MU

            ON poe.FMaterialID = mu.FMaterialID

         WHERE (poe.FSourceBillEntryID =T_SD_SaleOrderEntry.FIDAND

               (((poe.FParentID IN ('LlBN+WXBSsiRN5zSo9wMfjFxv60='))AND

              T_SD_SaleOrderEntry.FMaterialID = poe.FMaterialID)AND

              T_SD_SaleOrderEntry.FUnitID = mu.FMeasureUnitID)))

   ANDEXISTS

 (SELECT (ROUND(CAST((poe.FBaseQty / NVL(FBaseConvsRate,1)) AS

                           NUMBER(28,16)),

                     mu.FQtyPrecision) + T_SD_SaleOrderEntry.FOrderedQty) FORDEREDQTY,

              (T_SD_SaleOrderEntry.FQty -

               (ROUND(CAST((poe.FBaseQty /NVL(FBaseConvsRate,1)) AS

                            NUMBER(28,16)),

                      mu.FQtyPrecision) + T_SD_SaleOrderEntry.FOrderedQty)) FUNORDEREDQTY

          FROM T_SM_PurOrderEntry POE

          LEFTOUTERJOIN T_BD_MultiMeasureUnit MU

            ON poe.FMaterialID = mu.FMaterialID

         WHERE (poe.FSourceBillEntryID =T_SD_SaleOrderEntry.FIDAND

               (((poe.FParentID IN ('LlBN+WXBSsiRN5zSo9wMfjFxv60='))AND

              T_SD_SaleOrderEntry.FMaterialID = poe.FMaterialID)AND

              T_SD_SaleOrderEntry.FUnitID = mu.FMeasureUnitID)))

发现IO比较高，接近5G byte。查看语句，语句本身没有问题，不应该需要这么高的IO量，进行了语句的计划分析。 

ExecutionPlan

----------------------------------------------------------

Planhash value: 4157953725

 

--------------------------------------------------------------------------------------------------------

|Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT              |                        |     1 |  231 |   171K  (1)| 00:34:23 |

|   1 | NESTED LOOPS                |                        |     1 |  231 |   171K  (1)| 00:34:23 |

|*  2 |  HASH JOIN                   |                        |     1 |  173 |   171K  (1)| 00:34:23 |

|   3 |   TABLE ACCESS BY INDEX ROWID| T_SM_PURORDERENTRY     |    8 |   688 |     6  (0)| 00:00:01 |

|*  4 |    INDEX RANGE SCAN          |IX_SM_POEPARENT        |     8 |      |     2   (0)| 00:00:01 |

|   5 |   TABLE ACCESS FULL          |T_SD_SALEORDERENTRY    |  8200K|  680M|   171K  (1)| 00:34:22 |

|*  6 |  INDEX RANGE SCAN            |IDX_MULTIMEASUREUNIT_1 |     1 |    58 |    1   (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------------

 

PredicateInformation (identified by operation id):

---------------------------------------------------

 

   2 -access("POE"."FSOURCEBILLENTRYID"=SYS_OP_C2C("T_SD_SALEORDERENTRY"."FID") AND

             "T_SD_SALEORDERENTRY"."FMATERIALID"="POE"."FMATERIALID")

   4 -access("POE"."FPARENTID"='LlBN+WXBSsiRN5zSo9wMfjFxv60=')

   6 -access("POE"."FMATERIALID"="MU"."FMATERIALID"AND

             "T_SD_SALEORDERENTRY"."FUNITID"="MU"."FMEASUREUNITID")

 

 

Statistics

----------------------------------------------------------

          0 recursive calls

          0 db block gets

          4 consistent gets

          0 physical reads

          0 redo size

        331 bytes sent via SQL*Net to client

        513 bytes received via SQL*Net from client

          1 SQL*Net roundtrips to/from client

          0 sorts (memory)

          0 sorts (disk)

0        rows processed

发现了其中一条子查询全表扫描了T_SD_SALEORDERENTRY，820万行数据量，700M的IO量。分析语句，发现执行过程中传递谓词出现系统字段转换SYS_OP_C2C access("POE"."FSOURCEBILLENTRYID"=SYS_OP_C2C("T_SD_SALEORDERENTRY"."FID")

经过对两张表的表结构进行分析，是由于FSOURCEBILLENTRYID的数据类型与"T_SD_SALEORDERENTRY"."FID"的数据类型不一致导致的。所以进行的数据类型的重新定义。优化后的语句计划如下： 

ExecutionPlan

----------------------------------------------------------

Planhash value: 2866515873

 

--------------------------------------------------------------------------------------------------------

|Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT              |                        |     1 |  227 |    11   (0)| 00:00:01 |

|   1 | NESTED LOOPS                |                        |     1 |  227 |    11   (0)| 00:00:01 |

|   2 |  NESTED LOOPS                |                        |     8 | 1352 |    10   (0)| 00:00:01 |

|   3 |   TABLE ACCESS BY INDEX ROWID| T_SM_PURORDERENTRY     |    8 |   656 |     6  (0)| 00:00:01 |

|*  4 |    INDEX RANGE SCAN          |IX_SM_POEPARENT        |     8 |      |     2   (0)| 00:00:01 |

|*  5 |   TABLE ACCESS BY INDEX ROWID| T_SD_SALEORDERENTRY    |    1 |    87 |     1  (0)| 00:00:01 |

|*  6 |    INDEX UNIQUE SCAN         |PK_SALEORDERENTRY      |     1 |      |     1   (0)| 00:00:01 |

|*  7 |  INDEX RANGE SCAN            |IDX_MULTIMEASUREUNIT_1 |     1 |    58 |    1   (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------------

 

PredicateInformation (identified by operation id):

---------------------------------------------------

 

   4 -access("POE"."FPARENTID"='LlBN+WXBSsiRN5zSo9wMfjFxv60=')

   5 - filter("T_SD_SALEORDERENTRY"."FMATERIALID"="POE"."FMATERIALID")

   6 -access("POE"."FSOURCEBILLENTRYID"="T_SD_SALEORDERENTRY"."FID")

   7 -access("POE"."FMATERIALID"="MU"."FMATERIALID"AND

             "T_SD_SALEORDERENTRY"."FUNITID"="MU"."FMEASUREUNITID")

 

 

Statistics

----------------------------------------------------------

          1 recursive calls

          0 db block gets

          4 consistent gets

          0 physical reads

          0 redo size

        331 bytes sent via SQL*Net to client

        513 bytes received via SQL*Net from client

          1 SQL*Net roundtrips to/from client

          0 sorts (memory)

          0 sorts (disk)

0        rows processed

新的执行计划只有87k的数据吞吐量。执行时间也由原来的30秒提升至0.01S。

这个为EAS数据库设计的问题。所有的表结构在存储外键的FFSOURCEBILLENTRYID的数据类型均为NVARCHAR类型，而存储主键的FID为VARCHAR。所以，在上下游单据联查，更新和删除的时候，会产生很大的效率问题。特别是供应链和财务模块相关大数据量的业务表。严重影响用户体验。需要逐一的进行表结构优化或者创建函数索引。


liannoy
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
SQL全表扫描优化基础知识
xiaochengxuyuan1的博客
01-28 895
1、模糊查询效率很低： 原因：like本身效率就比较低，应该尽量避免查询条件使用like；对于like ‘%…%’（全模糊）这样的条件，是无法使用索引的，全表扫描自然效率很低；另外，由于匹配算法的关系，模糊查询的字段长度越大，模糊查询效率越低。 解决办法：首先尽量避免模糊查询，如果因为业务需要一定要使用模糊查询，则至少保证不要使用全模糊查询，对于右模糊查询，即like ‘…%’，是会使用索引的；左模糊like ‘%…’无法直接使用索引，但可以利用reverse + function index 的形式，变化
MySQL主从不一致问题相关处理
热门推荐
企业实战系列集 ●●● https://ximenjianxue.blog.csdn.net
09-26 1万+
某业务采取mysql的主从架构，但因为存储的问题，导致备库一直无法存储，数据同步一致性问题一直也未恢复，某次安全检查要求完成主备倒换演练，必须限期恢复主备，但是在恢复过程中，同步显示正常一段时间后，便会出现sql线程异常，主备数据不一致导致的同步错误情况。主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。根据上面的NR行数，查看附近的行，定位数据不一致的地方，后续手动补全。
MYSQL 多表 LEFT JOIN 关联查询，索引失效导致全表扫描问题及解决方法
junh_422的博客
06-19 1万+
目前做商城系统二次重构，遇到原系统遗留订单到出问题，因涉及多表查询操作，原代码设计者对mysql中加了N多的索引，但是无论怎样弄，都会出现下面的情况
mySql数据库字段的类型（不全）
wojiaoliming的博客
05-01 194
bit 整型 bit 数据类型是整型，其值只能是0、1或空值。这种数据类型用于存储只有两种可能值的数据，如Yes 或No、True 或Fa lse 、On 或Offint 整型 int 数据类型可以存储从- 231(-2147483648)到231 (2147483 647)之间的整数。存储到数据库的几乎所有数值型的数据都可以用这种数据类型。这种数据类型在数据库里占用4个字节   float ...
c 结构体 字段的类型不完全
HMC20071120015的专栏
02-11 5985
struct strct{   int i;   struct strct struct1;//编译通不过，说是变量struct1类型不完全 }; 但是 struct strct{   int i;   struct strct *struct1;//完全可以 };其实多思考下就出来了，第一个结构体中引用对象，对象再引用对象，这样一直嵌套下去，编译器肯定不知道你这个结构体类型多少字节放得下；第二个就不同了，因为他是指针，存放struct strct指向
mysql 优化-数据类型不匹配导致的全表扫描
彻底拆分，一切可控！
03-08 444
一条sql执行时间特别长，很多时候页面都直接504 timeout，sql内容大致如下，其中a表的数据有2000w+数据，b表有600w+数据 SELECT a.* FROM a WHERE a.user_id = 123 AND a.id NOT IN ( SELECT b.pay_record_id AS pay_record_id FROM b WHERE b.user_id = 456 ) ORDER BY create_time DESC; 本来这2条sql语句里面
不完全类型
停止更新，迁移至ykpeng.com
09-28 912
不完全类型指“函数之外、类型的大小不能被确定的类型”
mysql 多表关联时 关联字段类型不同会导致索引失效?
最新发布
05-20
这是因为 MySQL 在进行多表关联时，需要使用到索引来进行匹配，如果关联字段的数据类型不同，MySQL 就无法使用索引进行匹配，而只能进行全表扫描，这会导致查询效率大大降低。 举个例子，假设有两张表 A 和 B，其中...
mysql导出表的字段和相关属性的步骤方法
12-16
可以通过使用索引、避免全表扫描、减少JOIN操作等方式来提升查询效率。 - **字段和属性**：字段是表中的数据单元，每个字段都有特定的数据类型（如INT、VARCHAR等）和属性（如是否可为空、默认值等）。 - **乐观锁...
库表字符集不一致导致的全表扫描问题
weixin_34375054的博客
05-10 278
背景： 当数据库的建库字符集和表不一样时，在库下针对表创建存储过程可能导致全表扫描 如下例： drop database if exists xx1; drop database if exists xx2; create database xx1 character set utf8; create database xx2 cha...
类型不一致导致索引失效全表扫描。
weixin_43031156的博客
11-09 622
起因 今天本是高高兴兴的一天，但是接到了客户的反馈，系统刚上线不到 2个月就发现一大片的功能查询很慢，甚至有的功能查找了10分钟才查出来，有的功能就直接查不出来了（我觉得有点夸张了）。经理震怒，直呼丢人。F5查看发现一片的TABLE ACCESS FULL，很多表都是走全表扫描，有很多该建索引的字段都没有建立索引。最后只得乖乖返工。 原因： tbl_key是varchar类型，goodsid是number类型。在这种情况下，Oracle会把开发者当成傻瓜，把查出来的数据先转成和条件一样的类型，然后再和条.
hive sql join 时字段类型不一致问题
weifengs 的博客
06-13 7342
在用hive sql 查询数据时会遇到 两个表通过字段join，假如两个字段类型不一样，有可能出现莫名其妙的结果。 解决方法： 将2个字段类型转成一样。比如 两个表通过id关联， 一个是 string 一个是 int，可以将 string 转成int  eg: (cast id as int) as id
HIVE关联key数据类型不一致导致数据重复
Angelina7的博客
08-13 632
结论：字段类型不一致，关联时将key转为double，导致精度丢失 示例：select cast(186994576061124660 as double)和select cast(186994576061124559 as double)结果都是1.86994576061124672E17 导致最终mapping结果重复 解决方法：需要将id转为string，修改后执行计划见图2 ...
为什么扫描枪只能扫入数字但是扫不进字母
谷歌是检验真理的唯一标准的博客
08-24 1万+
可以设置shirt 大写英文字母（比如 shift A）,shift是换档键，这么设置就表明扫码枪扫入的是大写字母，如果没有shift就只能是小写字母。
sql语句中的字段类型与sql表字段类型不一致可能引起的性能问题
xy752068432的博客
10-18 2432
今天在公司上班期间，发现一个很奇怪的问题。就是sql表中如果字段类型为字符串类型，而我们在写sql语句的时候用的确实整型的时候。在性能上会出现问题。接下来我们来看测试表结构如下:CREATE TABLE `order` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '订单ID', `order_num` varchar(256) COLLATE
mysql数据库表的字段类型对应java属性说明
shirleycyy的博客
04-24 3401
create table 表名(列名 类型(长度),列名  类型(长度));一个数据表 可以存在很多列，每列具有类型和长度  行指的是记录创建表之前 必须使用use db 指定操作数据库表中的字段类型MySQL常用数据类型数值型sqltinyintsmallintintbigintfloatdoublejavabyteshortintlongfloatdouble字符串型sqlvarchar最大为...
优化SQL：避免不匹配数据类型导致的全表扫描
如果执行 `WHERE` 子句 `account_number = 990354`，Oracle 会自动将此条件转化为 `to_number(account_number)=990354`，这将导致索引无法被有效利用，进而执行全表扫描。相反，如果写成 `account_number = '990354'...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值