찾다

“索引”实验小例

Jun 07, 2016 pm 03:59 PM
성명실험단순한색인

由索引引出简单实验几例 ***********************************************声明************************************************ 原创作品,出自 深蓝的blog 博客,欢迎转载,转载时请务必注明出处(http://blog.csdn.net/huangyanlong)。 表述有错误之处

由索引引出简单实验几例

***********************************************声明************************************************

原创作品,出自 “深蓝的blog” 博客,欢迎转载,转载时请务必注明出处(http://blog.csdn.net/huangyanlong)。

表述有错误之处,请您留言,不胜感激。

提醒:点击目录,更有助于您的查看。

*****************************************************************************************************

对之前的小例子重新归纳了一下,希望可以帮助对索引有进一步的理解。

【例1】数据量小不需建索引

//如果表的数据量很少,全表扫描和走索引成本相差很小,使用索引是不是就没有必要了。
实验操作:
SQL> SELECT ENAME,JOB,SAL FROM SCOTT.EMP;
//先找到一张小表以作实验,查看表中信息,只有14行

ENAME      JOB          SAL
---------- --------- ------
SMITH      CLERK        800
ALLEN      SALESMAN    1600
WARD       SALESMAN    1250
JONES      MANAGER     2975
MARTIN     SALESMAN    1250
BLAKE      MANAGER     2850
CLARK      MANAGER     2450
SCOTT      ANALYST     3000
KING       PRESIDENT   5000
TURNER     SALESMAN    1500
ADAMS      CLERK       1100
JAMES      CLERK        950
FORD       ANALYST     3000
MILLER     CLERK       1300

已选择14行。
SQL> SET AUTOTRACE ON
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT * FROM SCOTT.EMP WHERE ENAME='JAMES';
//全表扫描查找JAMES的信息

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    38 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EMP  |     1 |    38 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

SQL> CREATE INDEX IND_EMP_ENAME ON SCOTT.EMP(ENAME);
//为ENAME列建索引
SQL> SELECT * FROM SCOTT.EMP WHERE ENAME='JAMES';
//走列索引查找JAMES的信息
--------------------------------------------------------------------------------


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

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

|   0 | SELECT STATEMENT            |               |     1 |    38 |     2   (0)| 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID| EMP           |     1 |    38 |     2   (0)| 00:00:01 |

|*  2 |   INDEX RANGE SCAN          | IND_EMP_ENAME |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------
//全表扫描成本是3%,走索引成本是2%
//从以上实验发现,在表的数据量很小的情况下,全表扫描和走索引成本上相差不大。 

【例2】全表扫描IO成本低于使用索引情况 

**************************************************************************
举一个例子,不恰当的使用索引,比用全表扫描的的IO成本更加高。
**************************************************************************
解答:
    思路:创建一组rowid是散落在多个表数据块中的索引,这样由于索引列数据的分布情况和索引中的顺序差异很大,致使通过全表扫表比走索引更能降低IO的使用成本。
操作如下:
SQL> CREATE TABLE TAB_HYL AS SELECT * FROM DBA_OBJECTS;
//创建了一个TAB_HYL表以作实验
SQL> ANALYZE TABLE TAB_HYL COMPUTE STATISTICS;
//分析这张TAB_HYL实验表
SQL> SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME ='TAB_HYL';
//查找出实验表上的行数、块数

  NUM_ROWS     BLOCKS
---------- ----------
     72606       1033

SQL> SELECT 72606/1033 FROM DUAL;
//计算平均每个块中的行数为70行

72606/1033
----------
 70.286544

SQL> DROP TABLE TAB_HYL PURGE;
//删除这张表,这张表就是为了计算出每块所占的行数,从而对其进行构建完成实验
SQL> CREATE TABLE TAB_HYL AS SELECT * FROM DBA_OBJECTS WHERE ROWNUM<=70;
//重新创建实验表让它装入70行形成第一个块
SQL> INSERT INTO TAB_HYL SELECT * FROM TAB_HYL;
//复制相同的70行插到实验表中,即实验表中共有140行数据,两个块
SQL> /    
//再次执行相同操作,但此时基准的实验表为140行,因此第三次插入了140行数据,即现在实验表有280行数据
SQL> /    
//按照上面的方法以下连续创建,形成多个块,让每个块中都有相同的键值而形成一组实验用的ROWID
SQL> /
SQL> /
SQL> /
SQL> /
SQL> COMMIT;
SQL> CREATE INDEX IND_H1 ON TAB_HYL(OBJECT_ID);
//创建实验表中OBJECT_ID列的索引,之后通过该列值进行查询,来说明查询的成本
SQL> ANALYZE TABLE TAB_HYL COMPUTE STATISTICS; //分析一下实验表
SQL> SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME =&#39;TAB_HYL&#39;;
//查看一下此时实验表的行数、块数已经达到实验准备条件,可以开始试验了

  NUM_ROWS     BLOCKS
---------- ----------
      8960        103

SQL> SET AUTOTRACE ON
SQL> SET AUTOTRACE TRACEONLY  
//设定跟踪
SQL> SELECT * FROM TAB_HYL WHERE OBJECT_ID=70;
//通过上面创建了索引的列来查找,得到下面的分析结果,记住cpu的成本为30,并且数据库自动完成的是走全表扫描,说明数据库已经判断出什么方式查询,成本更低了。

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

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

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

|   0 | SELECT STATEMENT  |         |   128 | 10112 |    30   (0)| 00:00:01 |

|*  1 |  TABLE ACCESS FULL| TAB_HYL |   128 | 10112 |    30   (0)| 00:00:01 |

----------------------------------------------------------------------
//之后我们人为让查询走索引再看一下分析结果。
SQL> SELECT /*+INDEX(TAB_HYL IND_H1)*/ * FROM TAB_HYL WHERE OBJECT_ID=70;
//强制查询走索引,输出一下结果,看到成本是102,要远高于全表扫描的成本(全表扫描是30,见上表)。

----------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time   
----------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |   128 | 10112 |   102(0)| 00:00:02 |

|   1 |  TABLE ACCESS BY INDEX ROWID| TAB_HYL |   128 | 10112 |   102(0)| 00:00:02 |

|*  2 |   INDEX RANGE SCAN          | IND_H1  |   128 |       |     1(0)| 00:00:01 |
----------------------------------------------------------------------
通过以上实验说明,当索引列数据的分布情况和索引中的顺序差异很大这种情况出现时,做索引范围扫描效率偏低。

【例3】构造表时集簇因子数分别为接近块数、接近行数

**************************************************************************
建两张表,各建一个索引。要求A表的索引集簇因子接近表块数,B表的索引集簇因子接近表行数。
**************************************************************************
(一)、创建A表:索引集簇因子接近表块数
操作:
SQL> CREATE TABLE TAB_HYL AS SELECT * FROM DBA_OBJECTS;
//先创建了一个TAB_HYL表以作实验源表,为了通过这个表分析出表中一个块所占的行数
SQL> ANALYZE TABLE TAB_HYL COMPUTE STATISTICS;
//分析这张TAB_HYL实验表
SQL> SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME =&#39;TAB_HYL&#39;;
//查找出实验表上的行数、块数

  NUM_ROWS     BLOCKS
---------- ----------
     72606       1033

SQL> SELECT 72606/1033 FROM DUAL;
//计算平均每个块中的行数为70行

72606/1033
----------
 70.286544

SQL> DROP TABLE TAB_HYL PURGE;
//删除这张表
SQL> CREATE TABLE TAB_HYL AS SELECT * FROM DBA_OBJECTS WHERE ROWNUM<=70;
//重新创建实验表让它装入70行形成第一个块
SQL> INSERT INTO TAB_HYL SELECT * FROM TAB_HYL;
//复制相同的70行插到实验表中,即实验表中共有140行数据,两个块
SQL> /    
//再次执行相同操作,但此时基准的实验表为140行,因此第三次插入了140行数据,即现在实验表有280行数据
SQL> /    
//按照上面的方法以下连续创建,这是为了构造实验表的集簇因子
SQL> /
SQL> /
SQL> /
SQL> /
SQL> COMMIT;
SQL> CREATE TABLE TAB_A AS SELECT * FROM TAB_HYL ORDER BY OBJECT_ID;
//根据实验表创建出表A,表A是通过OBJECT_ID排序的,因此就得到了键值相同的分布较集中的块
SQL> CREATE INDEX IND_H1 ON TAB_A(OBJECT_ID);
//创建A表中OBJECT_ID列的索引
SQL> ANALYZE TABLE TAB_A COMPUTE STATISTICS;
//分析一下A表
SQL> SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME = &#39;TAB_A&#39;;

  NUM_ROWS     BLOCKS
---------- ----------
      8960        102

SQL> SELECT BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,AVG_LEAF_BLOCKS_PER_KEY,CLUSTERING_FACTOR
  2  FROM USER_INDEXES
  3  WHERE INDEX_NAME = &#39;IND_H1&#39;;
//查看A表索引列的b-tree级别、叶的块数、不同的key值、平均每个key所占的叶块的数量、聚集的因子

 BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY CLUSTERING_FACTOR
------- ----------- ------------- -----------------------  -----------------
      1          18            70                       1                102

//得到了A表索引列的集簇因子数(102)与上面的A表的块数(102)是相同的。

(二)、创建B表:索引集簇因子接近表行数
操作:
SQL> CREATE TABLE TAB_HYL AS SELECT * FROM DBA_OBJECTS;//创建了一个实验表以作实验
SQL> ANALYZE TABLE TAB_HYL COMPUTE STATISTICS;//分析这张TAB_HYL实验表
SQL> SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME =&#39;TAB_HYL&#39;;//查找出实验表上的行数、块数

  NUM_ROWS     BLOCKS
---------- ----------
     72606       1033

SQL> SELECT 72606/1033 FROM DUAL;//计算平均每个块中的行数为70行

72606/1033
----------
 70.286544

SQL> DROP TABLE TAB_HYL PURGE;//删除这张表
SQL> CREATE TABLE TAB_B AS SELECT * FROM DBA_OBJECTS WHERE ROWNUM<=70;//创建B表让它装入70行形成第一个块
SQL> INSERT INTO TAB_B SELECT * FROM TAB_B;//复制相同的70行插到B表中,即B表中共有140行数据,两个块
SQL> /    //再次执行相同操作,但此时基准的B表为140行,因此第三次插入了140行数据,即现在B表有280行数据
SQL> /    //按照上面的方法以下连续创建,这是为了构造B表的集簇因子
SQL> /
SQL> /
SQL> /
SQL> /
SQL> COMMIT;
SQL> CREATE INDEX IND_H2 ON TAB_B(OBJECT_ID);//创建B表中OBJECT_ID列的索引
SQL> ANALYZE TABLE TAB_B COMPUTE STATISTICS; //分析一下B表
SQL> SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME =&#39;TAB_B&#39;;//查看一下此时B表的行数、块数

  NUM_ROWS     BLOCKS
---------- ----------
      8960        103

SQL> SELECT BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,AVG_LEAF_BLOCKS_PER_KEY,CLUSTERING_FACTOR
  2  FROM USER_INDEXES
  3  WHERE INDEX_NAME = &#39;IND_H2&#39;;

//查看B表索引列的b-tree级别、叶的块数、不同的key值、平均每个key所占的叶块的数量、集簇因子

 BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY  CLUSTERING_FACTOR

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

      1          18            70                       1               7070

//B表索引列的集簇因子(7070)和B表中的行数(8960)相对接近.           

 【例4】有关索引监控

**************************************************************************
对一张表的索引开监控,看是否有使用到。
**************************************************************************
会话A:
SQL> ALTER INDEX IND_H1 MONITORING USAGE;

//对上面练习中用到的IND_H1索引开监控

SQL> SELECT * FROM V$OBJECT_USAGE;

//通过查看V$OBJECT_USAGE视图查看对IND_H1索引的监控信息,MON为YES代表已经开监控了,当前没有人用到

INDEX_NAME          TABLE_NAME             MON USE  START_MONITORING     END_MONITORING
------------------- ---------------------- --- ---  -------------------  -------------------
IND_H1              TAB_A	           YES NO   03/18/2014 16:54:29

会话B:
SQL> SET AUTOTRACE ON;
//开监控,确认下面的操作是走索引的

SQL> SELECT * FROM TAB_A WHERE OBJECT_ID=70;
//使用带索引列查询,分析结果如下
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |   128 | 10112 |     3   (0)| 00:0
0:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID| TAB_A  |   128 | 10112 |     3   (0)| 00:0
0:01 |

|*  2 |   INDEX RANGE SCAN          | IND_H1 |   128 |       |     1   (0)| 00:0
0:01 |
--------------------------------------------------------------------------------

会话A:
SQL> SELECT * FROM V$OBJECT_USAGE;

//再次通过V$OBJECT_USAGE视图查看对IND_H1索引的监控信息,MON为YES代表已经开监控了,USE为YES代表当前有人在使用

INDEX_NAME          TABLE_NAME             MON USE  START_MONITORING     END_MONITORING
------------------- ---------------------- --- ---  -------------------  -------------------
IND_H1              TAB_A	           YES YES  03/18/2014 16:54:29

***********************************************声明************************************************

原创作品,出自 “深蓝的blog” 博客,欢迎转载,转载时请务必注明出处(http://blog.csdn.net/huangyanlong)。

表述有错误之处,请您留言,不胜感激。

提醒:点击目录,更有助于您的查看。

*****************************************************************************************************

성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
MySQL : 세계에서 가장 인기있는 데이터베이스 소개MySQL : 세계에서 가장 인기있는 데이터베이스 소개Apr 12, 2025 am 12:18 AM

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템으로, 주로 데이터를 신속하고 안정적으로 저장하고 검색하는 데 사용됩니다. 작업 원칙에는 클라이언트 요청, 쿼리 해상도, 쿼리 실행 및 반환 결과가 포함됩니다. 사용의 예로는 테이블 작성, 데이터 삽입 및 쿼리 및 조인 작업과 같은 고급 기능이 포함됩니다. 일반적인 오류에는 SQL 구문, 데이터 유형 및 권한이 포함되며 최적화 제안에는 인덱스 사용, 최적화 된 쿼리 및 테이블 분할이 포함됩니다.

MySQL의 중요성 : 데이터 저장 및 관리MySQL의 중요성 : 데이터 저장 및 관리Apr 12, 2025 am 12:18 AM

MySQL은 데이터 저장, 관리, 쿼리 및 보안에 적합한 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1. 다양한 운영 체제를 지원하며 웹 응용 프로그램 및 기타 필드에서 널리 사용됩니다. 2. 클라이언트-서버 아키텍처 및 다양한 스토리지 엔진을 통해 MySQL은 데이터를 효율적으로 처리합니다. 3. 기본 사용에는 데이터베이스 및 테이블 작성, 데이터 삽입, 쿼리 및 업데이트가 포함됩니다. 4. 고급 사용에는 복잡한 쿼리 및 저장 프로 시저가 포함됩니다. 5. 설명 진술을 통해 일반적인 오류를 디버깅 할 수 있습니다. 6. 성능 최적화에는 인덱스의 합리적인 사용 및 최적화 된 쿼리 문이 포함됩니다.

MySQL을 사용하는 이유는 무엇입니까? 혜택과 장점MySQL을 사용하는 이유는 무엇입니까? 혜택과 장점Apr 12, 2025 am 12:17 AM

MySQL은 성능, 신뢰성, 사용 편의성 및 커뮤니티 지원을 위해 선택됩니다. 1.MYSQL은 효율적인 데이터 저장 및 검색 기능을 제공하여 여러 데이터 유형 및 고급 쿼리 작업을 지원합니다. 2. 고객-서버 아키텍처 및 다중 스토리지 엔진을 채택하여 트랜잭션 및 쿼리 최적화를 지원합니다. 3. 사용하기 쉽고 다양한 운영 체제 및 프로그래밍 언어를 지원합니다. 4. 강력한 지역 사회 지원을 받고 풍부한 자원과 솔루션을 제공합니다.

InnoDB 잠금 장치 (공유 잠금, 독점 잠금, 의도 잠금, 레코드 잠금, 갭 잠금, 차세대 자물쇠)를 설명하십시오.InnoDB 잠금 장치 (공유 잠금, 독점 잠금, 의도 잠금, 레코드 잠금, 갭 잠금, 차세대 자물쇠)를 설명하십시오.Apr 12, 2025 am 12:16 AM

InnoDB의 잠금 장치에는 공유 잠금 장치, 독점 잠금, 의도 잠금 장치, 레코드 잠금, 갭 잠금 및 다음 키 잠금 장치가 포함됩니다. 1. 공유 잠금을 사용하면 다른 트랜잭션을 읽지 않고 트랜잭션이 데이터를 읽을 수 있습니다. 2. 독점 잠금은 다른 트랜잭션이 데이터를 읽고 수정하는 것을 방지합니다. 3. 의도 잠금은 잠금 효율을 최적화합니다. 4. 레코드 잠금 잠금 인덱스 레코드. 5. 갭 잠금 잠금 장치 색인 기록 간격. 6. 다음 키 잠금은 데이터 일관성을 보장하기 위해 레코드 잠금과 갭 잠금의 조합입니다.

열악한 MySQL 쿼리 성능의 일반적인 원인은 무엇입니까?열악한 MySQL 쿼리 성능의 일반적인 원인은 무엇입니까?Apr 12, 2025 am 12:11 AM

MySQL 쿼리 성능이 좋지 않은 주된 이유는 인덱스 사용, 쿼리 최적화에 의한 잘못된 실행 계획 선택, 불합리한 테이블 디자인, 과도한 데이터 볼륨 및 잠금 경쟁이 포함됩니다. 1. 색인이 느리게 쿼리를 일으키지 않으며 인덱스를 추가하면 성능이 크게 향상 될 수 있습니다. 2. 설명 명령을 사용하여 쿼리 계획을 분석하고 Optimizer 오류를 찾으십시오. 3. 테이블 구조를 재구성하고 결합 조건을 최적화하면 테이블 설계 문제가 향상 될 수 있습니다. 4. 데이터 볼륨이 크면 분할 및 테이블 디비전 전략이 채택됩니다. 5. 높은 동시성 환경에서 거래 및 잠금 전략을 최적화하면 잠금 경쟁이 줄어들 수 있습니다.

Composite Index와 여러 단일 열 인덱스를 언제 사용해야합니까?Composite Index와 여러 단일 열 인덱스를 언제 사용해야합니까?Apr 11, 2025 am 12:06 AM

데이터베이스 최적화에서 쿼리 요구 사항에 따라 인덱싱 전략을 선택해야합니다. 1. 쿼리에 여러 열이 포함되고 조건 순서가 수정되면 복합 인덱스를 사용하십시오. 2. 쿼리에 여러 열이 포함되어 있지만 조건 순서가 고정되지 않은 경우 여러 단일 열 인덱스를 사용하십시오. 복합 인덱스는 다중 열 쿼리를 최적화하는 데 적합한 반면 단일 열 인덱스는 단일 열 쿼리에 적합합니다.

MySQL에서 느린 쿼리를 식별하고 최적화하는 방법은 무엇입니까? (느린 쿼리 로그, Performance_schema)MySQL에서 느린 쿼리를 식별하고 최적화하는 방법은 무엇입니까? (느린 쿼리 로그, Performance_schema)Apr 10, 2025 am 09:36 AM

MySQL 느린 쿼리를 최적화하려면 SlowQueryLog 및 Performance_Schema를 사용해야합니다. 1. SlowQueryLog 및 Set Stresholds를 사용하여 느린 쿼리를 기록합니다. 2. Performance_schema를 사용하여 쿼리 실행 세부 정보를 분석하고 성능 병목 현상을 찾고 최적화하십시오.

MySQL 및 SQL : 개발자를위한 필수 기술MySQL 및 SQL : 개발자를위한 필수 기술Apr 10, 2025 am 09:30 AM

MySQL 및 SQL은 개발자에게 필수적인 기술입니다. 1.MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템이며 SQL은 데이터베이스를 관리하고 작동하는 데 사용되는 표준 언어입니다. 2.MYSQL은 효율적인 데이터 저장 및 검색 기능을 통해 여러 스토리지 엔진을 지원하며 SQL은 간단한 문을 통해 복잡한 데이터 작업을 완료합니다. 3. 사용의 예에는 기본 쿼리 및 조건 별 필터링 및 정렬과 같은 고급 쿼리가 포함됩니다. 4. 일반적인 오류에는 구문 오류 및 성능 문제가 포함되며 SQL 문을 확인하고 설명 명령을 사용하여 최적화 할 수 있습니다. 5. 성능 최적화 기술에는 인덱스 사용, 전체 테이블 스캔 피하기, 조인 작업 최적화 및 코드 가독성 향상이 포함됩니다.

See all articles

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

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

AI Clothes Remover

AI Clothes Remover

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

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

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

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌
WWE 2K25 : Myrise에서 모든 것을 잠금 해제하는 방법
3 몇 주 전By尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

Atom Editor Mac 버전 다운로드

Atom Editor Mac 버전 다운로드

가장 인기 있는 오픈 소스 편집기

SecList

SecList

SecLists는 최고의 보안 테스터의 동반자입니다. 보안 평가 시 자주 사용되는 다양한 유형의 목록을 한 곳에 모아 놓은 것입니다. SecLists는 보안 테스터에게 필요할 수 있는 모든 목록을 편리하게 제공하여 보안 테스트를 더욱 효율적이고 생산적으로 만드는 데 도움이 됩니다. 목록 유형에는 사용자 이름, 비밀번호, URL, 퍼징 페이로드, 민감한 데이터 패턴, 웹 셸 등이 포함됩니다. 테스터는 이 저장소를 새로운 테스트 시스템으로 간단히 가져올 수 있으며 필요한 모든 유형의 목록에 액세스할 수 있습니다.

DVWA

DVWA

DVWA(Damn Vulnerable Web App)는 매우 취약한 PHP/MySQL 웹 애플리케이션입니다. 주요 목표는 보안 전문가가 법적 환경에서 자신의 기술과 도구를 테스트하고, 웹 개발자가 웹 응용 프로그램 보안 프로세스를 더 잘 이해할 수 있도록 돕고, 교사/학생이 교실 환경 웹 응용 프로그램에서 가르치고 배울 수 있도록 돕는 것입니다. 보안. DVWA의 목표는 다양한 난이도의 간단하고 간단한 인터페이스를 통해 가장 일반적인 웹 취약점 중 일부를 연습하는 것입니다. 이 소프트웨어는

SublimeText3 Linux 새 버전

SublimeText3 Linux 새 버전

SublimeText3 Linux 최신 버전

에디트플러스 중국어 크랙 버전

에디트플러스 중국어 크랙 버전

작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음