小表为什么会很慢?

前几天,一个用户找到我,说查一个小表的时候非常慢,我问有多慢,他说最快也得半个小时才能出结果,有时干脆不出结果,我说小表多大,他说就几十兆,有点疑惑,让他帮忙获取了相关信息,一看就明白了,原来所谓的小表是“假”的,下面是分析时参照的信息及分析的步骤。

SQL语句:
select * from TEST where rec_date>trunc(sysdate-1);

SQL计划:
------------------------------------------------------------------------------------------------------------
| Id  | Operation                | Name            | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |                 |  2011 |   3118K|   892   (3)| 00:00:13 |       |    |
|   1 |  PARTITION RANGE ITERATOR|                 |  2011 |   3118K|   892   (3)| 00:00:13 |   KEY |  21 |
|*  2 |   TABLE ACCESS FULL      | TEST |  2011 |   318K|   8912   (3)| 00:00:13 |   KEY | 21 |
------------------------------------------------------------------------------------------------------------

表所占空间:
select sum(bytes)/1024/1024 "(MB)" from dba_extents where segment_name='TEST';
      (MB)
----------
    31.675

看到这里,我有点疑惑,表确实不大,但有个线索,大家注意到没有,那就是partition,如此小的表,有必要分区吗?莫非。。。

desc TEST

 名称                                      是否为空? 类型
 ----------------------------------------- -------- ----------------------------
 REC_ID                                    NOT NULL VARCHAR2(20)
 REC_NAME                                           VARCHAR2(200)
 REC_DESC                                           CLOB
 REC_DATE                                  NOT NULL DATE
 REC_CLASS                                          NUMBER
 REC_LEN                                            NUMBER

至此,真相大白了,大家明白了吧?也许有的同学还是不明白,继续。。。

select sum(bytes)/1024/1024/1024 "(GB)" from dba_extents 
where partition_name in(
select lob_partition_name from user_lob_partitions
where table_name='TEST');
      (GB)
----------
309.31425

明白了吗?呵呵,现在通过上面的信息,我们找到了”小表超慢“的原因,但这时,用户再次提出:我们怎么解决这个查询慢的问题呢?继续。。。

select index_name,table_name,column_name from user_ind_columns where table_name='TEST'

INDEX_NAME                     TABLE_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ----------------------------------------
IDX1_REC_DATE                   TEST                          REC_DATE
IDX2_REC_ID                     TEST                          REC_ID

因为该库为用户生产库,且该表较大,所以,决定先通过hint测试效率问题:
select /*+ index(t IDX1_REC_DATE)*/ * from TEST t where rec_date>trunc(sysdate-1);

加hint后计划:
---------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                 | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                      |  2011 |   318K|   912   (1)| 00:00:15 |       |       |
|   1 |  PARTITION RANGE ITERATOR          |                      |  2011 |   318K|   912   (1)| 00:00:15 |   KEY |     21 |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| TES      |  2011 |   318K|   912   (1)| 00:00:15 |   KEY |     21 |
|*  3 |    INDEX RANGE SCAN                | IDX1_REC_DATE|  20T11 |       |    14   (0)| 00:00:01 |   KEY |     21 |

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Vivado是Xilinx公司开发的一款FPGA(Field-Programmable Gate Array)设计工具,LUT(Look-Up Table)是FPGA的基本逻辑单元,用于实现数字逻辑功能。当在FPGA设计中使用过多的LUT时,可能导致以下几种情况使系统变慢: 1. **资源限制**:每个FPGA芯片都有固定的LUT数量,如果超过限制,设计可能无法实现,或者需要更高级别的FPGA才能容纳,这导致成本增加和设计时间延长。 2. **延迟增加**:更多的LUT意味着更复杂的电路,可能导致信号路径变长,从而增加延迟,影响系统性能,特别是在实时应用中,延迟敏感的算法可能受到影响。 3. **功耗和散热**:过多的LUT使用消耗更多电能,对于电源效率和热管理也是一个挑战,特别是在大型系统或对能源效率有高要求的设备中。 4. **布线复杂性**:更多的LUT通常意味着更多的连接,这可能导致布线拥挤,影响信号完整性,可能需要额外的布线资源或者增加阻抗控制。 5. **编译速度和资源优化**:Vivado在综合和布局布线阶段,处理大量LUT的设计可能需要更长时间,因为优化器需要花费更多计算资源来找到最佳的资源分配策略。 为了避免这些问题,设计师通常尝试优化代码,减少不必要的逻辑,使用更高效的算法,或者选择适当大小的FPGA,以及考虑使用查找表替换、流水线技术等高级设计技术。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值