4.1. EXPLAIN MySQL에서는 EXPLAIN을 사용하여 SQL 실행 계획을 볼 수 있습니다. 사용법: EXPLAIN SELECT * FROM tb_item
4.2.결과 설명 4.2.1.id SELECT 식별자. SELECT 쿼리 시퀀스 번호입니다. 이것은 중요하지 않습니다. 4.2.2.select_type 은 SELECT문의 종류를 나타냅니다.
에는 다음과 같은 값이 있습니다. 1. SIMPLE 은 조인 쿼리와 하위 쿼리를 포함하지 않는 단순 쿼리를 나타냅니다. 2. PRIMARY 는 메인 쿼리, 즉 가장 바깥쪽 쿼리문을 나타냅니다.
3. UNION 은 연결 쿼리의 두 번째 이후 쿼리문을 나타냅니다.
4. DEPENDENT UNION UNION의 두 번째 또는 후속 SELECT 문은 외부 쿼리에 따라 다릅니다. 5. UNION RESULT 연결 쿼리 결과입니다. 6. SUBQUERY 하위 쿼리의 첫 번째 SELECT 문입니다.
7. 종속 하위 쿼리 하위 쿼리의 첫 번째 SELECT 문은 외부 쿼리에 따라 달라집니다. 8. DERIVED SELECT(FROM 절의 하위 쿼리). 4.2.3.테이블 은 쿼리 테이블을 나타냅니다. 4.2.4.유형(중요) 은 테이블의 연결 유형을 나타냅니다. 다음 연결 유형은 가장 좋은 것부터 가장 나쁜 것 순으로 정렬됩니다.
1. 시스템 테이블에는 행이 하나만 있습니다. 이는 const 유형의 특수 열이며 일반적으로 무시할 수 있습니다. 2.const 데이터 테이블에는 최대 하나의 데이터 행만 일치할 수 있으므로 PRIMARY KEY 또는 UNIQUE 인덱스에 대한 쿼리에 자주 사용됩니다. const가 가장 최적화되어 있음을 이해하십시오.
3. eq_ref MySQL 설명서에는 다음과 같이 나와 있습니다. "이전 테이블의 각 행 조합에 대해 테이블에서 한 행을 읽습니다. 이는 const 유형을 제외하면 아마도 가장 좋은 조인 유형일 것입니다. 인덱스의 모든 부분이 조인에 사용되며 인덱스는 UNIQUE 또는 PRIMARY KEY입니다. eq_ref는 =를 사용하여 인덱스된 열을 비교하는 데 사용할 수 있습니다.
4. ref 쿼리 조건 인덱스가 UNIQUE 또는 PRIMARY KEY가 아닙니다. ref는 =, < 연산자를 사용하여 인덱스된 열에 사용할 수 있습니다.
5. ref_or_null 이 조인 유형은 ref와 비슷하지만 NULL 값이 포함된 행을 구체적으로 검색하기 위해 MySQL을 추가합니다. 이러한 조인 유형의 최적화는 하위 쿼리를 해결하는 데 자주 사용됩니다.
위의 다섯 가지 상황은 모두 이상적인 인덱스 사용 상황입니다.
6. index_merge 이 조인 유형은 인덱스 병합 최적화 방법이 사용됨을 나타냅니다. 이 경우 키 열에는 사용된 인덱스 목록이 포함되고, key_len에는 사용된 인덱스의 가장 긴 키 요소가 포함됩니다. 7.unique_subquery 이 유형은 IN 하위 쿼리의 참조를 다음 형식으로 대체합니다. value IN (SELECT Primary_key FROM Single_table WHERE some_expr) unique_subquery는 하위 쿼리를 완전히 대체할 수 있는 인덱스 검색 함수입니다. 더 효율적입니다. 8. index_subquery 이 연결 유형은 Unique_subquery와 유사합니다. IN 하위 쿼리는 대체될 수 있지만 다음 형식의 하위 쿼리에 있는 고유하지 않은 인덱스에만 적합합니다. value IN (SELECT key_column FROM Single_table WHERE some_expr) 9. range 는 다음을 사용하여 지정된 범위의 행만 검색합니다. 행을 선택하는 하나의 인덱스.
10.index 이 조인 유형은 인덱스 트리만 검색한다는 점을 제외하면 ALL과 동일합니다. 인덱스 파일은 일반적으로 데이터 파일보다 작기 때문에 일반적으로 ALL보다 빠릅니다. 11. ALL 이전 테이블의 각 행 조합에 대해 전체 테이블 스캔을 수행합니다. (최악의 성능) 4.2.5.posable_keys 는 MySQL이 이 테이블에서 행을 찾는 데 사용할 수 있는 인덱스를 나타냅니다. 열이 NULL이면 인덱스가 사용되지 않는다는 의미입니다. 성능을 향상시키기 위해 열에 인덱스를 생성할 수 있습니다. 4.2.6.key MySQL이 실제로 사용하기로 결정한 키(인덱스)를 표시합니다. 인덱스를 선택하지 않으면 키는 NULL입니다.
인덱스를 강제로 사용하거나 무시할 수 있습니다.
4.2.7.key_len MySQL이 사용하기로 결정한 키 길이를 표시합니다. 키가 NULL이면 길이도 NULL입니다.
참고: key_len은 MySQL이 사용할 실제 인덱스 길이를 결정합니다.
4.2.8.ref 테이블에서 행을 선택하기 위해 키와 함께 사용되는 열 또는 상수를 표시합니다. 4.2.9.rows MySQL이 쿼리를 실행할 때 검사해야 한다고 생각하는 행 수를 표시합니다. 4.2.10.추가 이 열에는 MySQL이 쿼리를 어떻게 해결했는지에 대한 세부 정보가 포함되어 있습니다. • 구별: MySQL은 일치하는 첫 번째 행을 찾은 후 현재 행 조합에 대한 추가 행 검색을 중지합니다. • 존재하지 않음: MySQL은 쿼리에서 LEFT JOIN 최적화를 수행할 수 있습니다. LEFT JOIN 표준과 일치하는 행을 찾은 후에는 더 이상 테이블에서 이전 행 조합에 대해 더 많은 행을 확인하지 않습니다. • 각 레코드에 대한 범위 확인(인덱스 맵: #): MySQL은 사용할 수 있는 좋은 인덱스를 찾지 못했지만 이전 테이블의 열 값을 알고 있는 경우 일부 인덱스가 사용될 수 있음을 발견했습니다. • filesort 사용: MySQL은 정렬된 순서로 행을 검색하는 방법을 알아내기 위해 추가 패스가 필요합니다. • 인덱스 사용: 추가 검색 없이 인덱스 트리에 있는 정보만 사용하여 실제 행을 읽어 테이블에서 열 정보를 검색합니다. • 임시 사용: 쿼리를 해결하려면 MySQL은 결과를 보관할 임시 테이블을 생성해야 합니다. • where:WHERE 절을 사용하여 다음 테이블과 일치하는 행을 제한하거나 클라이언트에 전송됩니다. • sort_union(...) 사용, Union(...) 사용, intersect(...) 사용: 이 함수는 index_merge 조인 유형에 대한 인덱스 스캔을 병합하는 방법을 보여줍니다. • 그룹별로 인덱스 사용: 테이블에 액세스하는 인덱스 사용 방법과 유사하게, 그룹별로 인덱스를 사용한다는 것은 MySQL이 GROUP BY 또는 DISTINCT 쿼리의 모든 열을 쿼리하지 않고 쿼리하는 데 사용할 수 있는 인덱스를 찾았음을 의미합니다. 추가 검색. 실제 테이블에 대한 하드 디스크 액세스.
다음은 일부 데이터베이스 SQL 최적화 솔루션입니다. (01) 가장 효율적인 테이블 이름 순서 선택(자주 필기 테스트)
数据库的解析器按照从右到左的顺序处理FROM子句中的表名，
FROM子句中写在最后的表将被最先处理，
在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后，
如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后。
例如：查询员工的编号，姓名，工资，工资等级，部门名
select emp.empno,emp.ename,emp.sal,salgrade.grade,dept.dname
from salgrade,dept,emp
where (emp.deptno = dept.deptno) and (emp.sal between salgrade.losal and salgrade.hisal)
1)如果三个表是完全无关系的话，将记录和列名最少的表，写在最后，然后依次类推
2)如果三个表是有关系的话，将引用最多的表，放在最后，然后依次类推
(02) WHERE 절의 연결 순서(수시 필기 시험)
数据库采用自右而左的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之左,
那些可以过滤掉最大数量记录的条件必须写在WHERE子句的之右。
例如：查询员工的编号，姓名，工资，部门名
select emp.empno,emp.ename,emp.sal,dept.dname
from emp,dept
where (emp.deptno = dept.deptno) and (emp.sal > 1500)
(03) SELECT 절에 * 기호를 사용하지 마세요
数据库在解析的过程中,会将*依次转换成所有的列名，这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间
select empno,ename from emp;
인턴십을 마치고 얼마 지나지 않아 다른 사람들이 찾아서 기록한 SQL Server를 사용하게 되었습니다. DBCC DROPCLEANBUFFERS는 캐시를 지웁니다. DBCC FREEPROCCACHE는 계획 캐시의 요소를 삭제합니다. CPU 시간을 보려면 SET STATISTICS TIME ON 논리적 읽기 수를 보려면 SET STATISTICS IO ON SET STATISTICS PROFILE ON 사용법을 모릅니다
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
4.1. EXPLAIN
MySQL에서는 EXPLAIN을 사용하여 SQL 실행 계획을 볼 수 있습니다. 사용법: EXPLAIN SELECT * FROM tb_item
4.2.결과 설명
4.2.1.id
SELECT 식별자. SELECT 쿼리 시퀀스 번호입니다. 이것은 중요하지 않습니다.
4.2.2.select_type
은 SELECT문의 종류를 나타냅니다.
에는 다음과 같은 값이 있습니다.
1. SIMPLE
은 조인 쿼리와 하위 쿼리를 포함하지 않는 단순 쿼리를 나타냅니다.
2. PRIMARY
는 메인 쿼리, 즉 가장 바깥쪽 쿼리문을 나타냅니다.
3. UNION
은 연결 쿼리의 두 번째 이후 쿼리문을 나타냅니다.
4. DEPENDENT UNION
UNION의 두 번째 또는 후속 SELECT 문은 외부 쿼리에 따라 다릅니다.
5. UNION RESULT
연결 쿼리 결과입니다.
6. SUBQUERY
하위 쿼리의 첫 번째 SELECT 문입니다.
7. 종속 하위 쿼리
하위 쿼리의 첫 번째 SELECT 문은 외부 쿼리에 따라 달라집니다.
8. DERIVED
SELECT(FROM 절의 하위 쿼리).
4.2.3.테이블
은 쿼리 테이블을 나타냅니다.
4.2.4.유형(중요)
은 테이블의 연결 유형을 나타냅니다.
다음 연결 유형은 가장 좋은 것부터 가장 나쁜 것 순으로 정렬됩니다.
1. 시스템
테이블에는 행이 하나만 있습니다. 이는 const 유형의 특수 열이며 일반적으로 무시할 수 있습니다.
2.const
데이터 테이블에는 최대 하나의 데이터 행만 일치할 수 있으므로 PRIMARY KEY 또는 UNIQUE 인덱스에 대한 쿼리에 자주 사용됩니다. const가 가장 최적화되어 있음을 이해하십시오.
3. eq_ref
MySQL 설명서에는 다음과 같이 나와 있습니다. "이전 테이블의 각 행 조합에 대해 테이블에서 한 행을 읽습니다. 이는 const 유형을 제외하면 아마도 가장 좋은 조인 유형일 것입니다. 인덱스의 모든 부분이 조인에 사용되며 인덱스는 UNIQUE 또는 PRIMARY KEY입니다. eq_ref는 =를 사용하여 인덱스된 열을 비교하는 데 사용할 수 있습니다.
4. ref
쿼리 조건 인덱스가 UNIQUE 또는 PRIMARY KEY가 아닙니다. ref는 =, < 연산자를 사용하여 인덱스된 열에 사용할 수 있습니다.
5. ref_or_null
이 조인 유형은 ref와 비슷하지만 NULL 값이 포함된 행을 구체적으로 검색하기 위해 MySQL을 추가합니다. 이러한 조인 유형의 최적화는 하위 쿼리를 해결하는 데 자주 사용됩니다.
위의 다섯 가지 상황은 모두 이상적인 인덱스 사용 상황입니다.
6. index_merge
이 조인 유형은 인덱스 병합 최적화 방법이 사용됨을 나타냅니다. 이 경우 키 열에는 사용된 인덱스 목록이 포함되고, key_len에는 사용된 인덱스의 가장 긴 키 요소가 포함됩니다.
7.unique_subquery
이 유형은 IN 하위 쿼리의 참조를 다음 형식으로 대체합니다. value IN (SELECT Primary_key FROM Single_table WHERE some_expr)
unique_subquery는 하위 쿼리를 완전히 대체할 수 있는 인덱스 검색 함수입니다. 더 효율적입니다.
8. index_subquery
이 연결 유형은 Unique_subquery와 유사합니다. IN 하위 쿼리는 대체될 수 있지만 다음 형식의 하위 쿼리에 있는 고유하지 않은 인덱스에만 적합합니다. value IN (SELECT key_column FROM Single_table WHERE some_expr)
9. range
는 다음을 사용하여 지정된 범위의 행만 검색합니다. 행을 선택하는 하나의 인덱스.
10.index
이 조인 유형은 인덱스 트리만 검색한다는 점을 제외하면 ALL과 동일합니다. 인덱스 파일은 일반적으로 데이터 파일보다 작기 때문에 일반적으로 ALL보다 빠릅니다.
11. ALL
이전 테이블의 각 행 조합에 대해 전체 테이블 스캔을 수행합니다. (최악의 성능)
4.2.5.posable_keys
는 MySQL이 이 테이블에서 행을 찾는 데 사용할 수 있는 인덱스를 나타냅니다.
열이 NULL이면 인덱스가 사용되지 않는다는 의미입니다. 성능을 향상시키기 위해 열에 인덱스를 생성할 수 있습니다.
4.2.6.key
MySQL이 실제로 사용하기로 결정한 키(인덱스)를 표시합니다. 인덱스를 선택하지 않으면 키는 NULL입니다.
인덱스를 강제로 사용하거나 무시할 수 있습니다.
4.2.7.key_len
MySQL이 사용하기로 결정한 키 길이를 표시합니다. 키가 NULL이면 길이도 NULL입니다.
참고: key_len은 MySQL이 사용할 실제 인덱스 길이를 결정합니다.
4.2.8.ref
테이블에서 행을 선택하기 위해 키와 함께 사용되는 열 또는 상수를 표시합니다.
4.2.9.rows
MySQL이 쿼리를 실행할 때 검사해야 한다고 생각하는 행 수를 표시합니다.
4.2.10.추가
이 열에는 MySQL이 쿼리를 어떻게 해결했는지에 대한 세부 정보가 포함되어 있습니다.
• 구별: MySQL은 일치하는 첫 번째 행을 찾은 후 현재 행 조합에 대한 추가 행 검색을 중지합니다.
• 존재하지 않음: MySQL은 쿼리에서 LEFT JOIN 최적화를 수행할 수 있습니다. LEFT JOIN 표준과 일치하는 행을 찾은 후에는 더 이상 테이블에서 이전 행 조합에 대해 더 많은 행을 확인하지 않습니다.
• 각 레코드에 대한 범위 확인(인덱스 맵: #): MySQL은 사용할 수 있는 좋은 인덱스를 찾지 못했지만 이전 테이블의 열 값을 알고 있는 경우 일부 인덱스가 사용될 수 있음을 발견했습니다.
• filesort 사용: MySQL은 정렬된 순서로 행을 검색하는 방법을 알아내기 위해 추가 패스가 필요합니다.
• 인덱스 사용: 추가 검색 없이 인덱스 트리에 있는 정보만 사용하여 실제 행을 읽어 테이블에서 열 정보를 검색합니다.
• 임시 사용: 쿼리를 해결하려면 MySQL은 결과를 보관할 임시 테이블을 생성해야 합니다.
• where:WHERE 절을 사용하여 다음 테이블과 일치하는 행을 제한하거나 클라이언트에 전송됩니다.
• sort_union(...) 사용, Union(...) 사용, intersect(...) 사용: 이 함수는 index_merge 조인 유형에 대한 인덱스 스캔을 병합하는 방법을 보여줍니다.
• 그룹별로 인덱스 사용: 테이블에 액세스하는 인덱스 사용 방법과 유사하게, 그룹별로 인덱스를 사용한다는 것은 MySQL이 GROUP BY 또는 DISTINCT 쿼리의 모든 열을 쿼리하지 않고 쿼리하는 데 사용할 수 있는 인덱스를 찾았음을 의미합니다. 추가 검색. 실제 테이블에 대한 하드 디스크 액세스.
다음은 일부 데이터베이스 SQL 최적화 솔루션입니다.
(01) 가장 효율적인 테이블 이름 순서 선택(자주 필기 테스트)
(02) WHERE 절의 연결 순서(수시 필기 시험)
(03) SELECT 절에 * 기호를 사용하지 마세요
(04) DELETE 대신 TRUNCATE를 사용하세요
(05) COMMIT를 최대한 활용하세요
(06) HAVING 절을 WHERE 절로 교체
(07) SQL 효율성 향상을 위한 내부 기능 추가
(08) 테이블 별칭 사용
(09) 열 별칭 사용
설명
SQL 실행 시 자동으로 explain 분석 작업을 수행하고 명령줄보다 조작이 편리한 비주얼 툴인 navicat을 사용하는 것이 좋습니다.
인턴십을 마치고 얼마 지나지 않아 다른 사람들이 찾아서 기록한 SQL Server를 사용하게 되었습니다.
DBCC DROPCLEANBUFFERS는 캐시를 지웁니다.
DBCC FREEPROCCACHE는 계획 캐시의 요소를 삭제합니다.
CPU 시간을 보려면 SET STATISTICS TIME ON
논리적 읽기 수를 보려면 SET STATISTICS IO ON
SET STATISTICS PROFILE ON 사용법을 모릅니다