如果表字段太多,如果表中有些字段比较大,即便是你只查有限的几个字段,在做表关联和全表扫的时候,由于扫描的数据块多,性能方面还是会不理想。因为oracle扫描的时候是按照块为单位扫描,读取的时候也是按块为单位读取,所以这种功能无法在SQL层面上优化的
如果表字段太多,如果表中有些字段比较大,即便是你只查有限的几个字段,在做表关联和全表扫的时候,由于扫描的数据块多,性能方面还是会不理想。因为oracle扫描的时候是按照块为单位扫描,读取的时候也是按块为单位读取,所以这种功能无法在SQL层面上优化的时候,可以考虑做数据的垂直切分,下面来做个试验:--制造数据不做垂直切分
create table test(
a number,
b varchar2(4000),
c varchar2(4000),
d varchar2(4000),
e varchar2(4000),
f varchar2(4000),
g varchar2(4000),
h varchar2(4000)
);
INSERT INTO test
SELECT ROWNUM,
rpad('*', 4000, 1),
rpad('*', 4000, 1),
rpad('*', 4000, 1),
rpad('*', 4000, 1),
rpad('*', 4000, 1),
rpad('*', 4000, 1),
rpad('*', 4000, 1)
FROM DUAL
CONNECT BY ROWNUM commit;
create table test1 as select * from test;
--制造数据做垂直切分
create table test_cuizhi(
a number
);
INSERT INTO test_cuizhi
SELECT ROWNUM
FROM DUAL
CONNECT BY ROWNUM commit;
create table test_cuizhi1 as select * from test_cuizhi;
--开始测试,只是取两个最小的字段
SQL> set timing on
SQL> set autotrace traceonly
SQL> select t.a,t1.a from test t, test1 t1 where t.a=t1.a;
已选择100000行。
已用时间: 00: 00: 53.17
执行计划
----------------------------------------------------------
Plan hash value: 2400077556
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 44504 | 1129K| 173K (1)| 00:34:38 |
|* 1 | HASH JOIN | | 44504 | 1129K| 173K (1)| 00:34:38 |
| 2 | TABLE ACCESS FULL| TEST | 44504 | 564K| 87801 (1)| 00:17:34 |
| 3 | TABLE ACCESS FULL| TEST1 | 117K| 1490K| 85344 (1)| 00:17:05 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T"."A"="T1"."A")
Note
-----
- dynamic sampling used for this statement
统计信息
----------------------------------------------------------
52 recursive calls
0 db block gets
795627 consistent gets
534917 physical reads
0 redo size
1664840 bytes sent via SQL*Net to client
73664 bytes received via SQL*Net from client
6668 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
100000 rows processed
SQL> /
已选择100000行。
已用时间: 00: 00: 33.36
执行计划
----------------------------------------------------------
Plan hash value: 2400077556
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 44504 | 1129K| 173K (1)| 00:34:38 |
|* 1 | HASH JOIN | | 44504 | 1129K| 173K (1)| 00:34:38 |
| 2 | TABLE ACCESS FULL| TEST | 44504 | 564K| 87801 (1)| 00:17:34 |
| 3 | TABLE ACCESS FULL| TEST1 | 117K| 1490K| 85344 (1)| 00:17:05 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T"."A"="T1"."A")
Note
-----
- dynamic sampling used for this statement
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
795446 consistent gets
552087 physical reads
0 redo size
1664840 bytes sent via SQL*Net to client
73664 bytes received via SQL*Net from client
6668 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
100000 rows processed
SQL> select t.a,t1.a from test_cuizhi t, test_cuizhi1 t1 where t.a=t1.a;
已选择100000行。
已用时间: 00: 00: 06.17
执行计划
----------------------------------------------------------
Plan hash value: 2501302817
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 88629 | 2250K| | 310 (2)| 00:00:04 |
|* 1 | HASH JOIN | | 88629 | 2250K| 2168K| 310 (2)| 00:00:04 |
| 2 | TABLE ACCESS FULL| TEST_CUIZHI | 88629 | 1125K| | 42 (3)| 00:00:01 |
| 3 | TABLE ACCESS FULL| TEST_CUIZHI1 | 101K| 1288K| | 39 (3)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T"."A"="T1"."A")
Note
-----
- dynamic sampling used for this statement
统计信息
----------------------------------------------------------
52 recursive calls
0 db block gets
7139 consistent gets
153 physical reads
0 redo size
1664840 bytes sent via SQL*Net to client
73664 bytes received via SQL*Net from client
6668 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
100000 rows processed
SQL> /
已选择100000行。
已用时间: 00: 00: 06.06
执行计划
----------------------------------------------------------
Plan hash value: 2501302817
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 88629 | 2250K| | 310 (2)| 00:00:04 |
|* 1 | HASH JOIN | | 88629 | 2250K| 2168K| 310 (2)| 00:00:04 |
| 2 | TABLE ACCESS FULL| TEST_CUIZHI | 88629 | 1125K| | 42 (3)| 00:00:01 |
| 3 | TABLE ACCESS FULL| TEST_CUIZHI1 | 101K| 1288K| | 39 (3)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T"."A"="T1"."A")
Note
-----
- dynamic sampling used for this statement
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
7008 consistent gets
0 physical reads
0 redo size
1664840 bytes sent via SQL*Net to client
73664 bytes received via SQL*Net from client
6668 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
100000 rows processed

本篇文章给大家带来了关于mysql的相关知识,其中主要介绍了关于索引优化器工作原理的相关内容,其中包括了MySQL Server的组成,MySQL优化器选择索引额原理以及SQL成本分析,最后通过 select 查询总结整个查询过程,下面一起来看一下,希望对大家有帮助。

sybase是基于客户/服务器体系结构的数据库,是一个开放的、高性能的、可编程的数据库,可使用事件驱动的触发器、多线索化等来提高性能。

visual foxpro数据库文件是管理数据库对象的系统文件。在VFP中,用户数据是存放在“.DBF”表文件中;VFP的数据库文件(“.DBC”)中不存放用户数据,它只起将属于某一数据库的 数据库表与视图、连接、存储过程等关联起来的作用。

数据库系统由4个部分构成:1、数据库,是指长期存储在计算机内的,有组织,可共享的数据的集合;2、硬件,是指构成计算机系统的各种物理设备,包括存储所需的外部设备;3、软件,包括操作系统、数据库管理系统及应用程序;4、人员,包括系统分析员和数据库设计人员、应用程序员(负责编写使用数据库的应用程序)、最终用户(利用接口或查询语言访问数据库)、数据库管理员(负责数据库的总体信息控制)。

microsoft sql server是Microsoft公司推出的关系型数据库管理系统,是一个全面的数据库平台,使用集成的商业智能(BI)工具提供了企业级的数据管理,具有使用方便可伸缩性好与相关软件集成程度高等优点。SQL Server数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能,使用户可以构建和管理用于业务的高可用和高性能的数据应用程序。

数据库的“完整性”是指数据的正确性和相容性。完整性是指数据库中数据在逻辑上的一致性、正确性、有效性和相容性。完整性对于数据库系统的重要性:1、数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合语义的数据;2、合理的数据库完整性设计,能够同时兼顾数据库的完整性和系统的效能;3、完善的数据库完整性有助于尽早发现应用软件的错误。

结构层次是“数据库→数据表→记录→字段”;字段构成记录,记录构成数据表,数据表构成了数据库。数据库是一个完整的数据的记录的整体,一个数据库包含0到N个表,一个表包含0到N个字段,记录是表中的行。

mysql查询为什么会慢,关于这个问题,在实际开发经常会遇到,而面试中,也是个高频题。遇到这种问题,我们一般也会想到是因为索引。那除开索引之外,还有哪些因素会导致数据库查询变慢呢?


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

드림위버 CS6
시각적 웹 개발 도구

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

에디트플러스 중국어 크랙 버전
작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음

SublimeText3 영어 버전
권장 사항: Win 버전, 코드 프롬프트 지원!

ZendStudio 13.5.1 맥
강력한 PHP 통합 개발 환경
