데이터베이스 가져오기 및 내보내기 데이터, 느린 쿼리, 테이블 잠금 솔루션

1. 데이터 가져오기 및 내보내기

1. 명령줄에서 mysql에 연결하고 가져옵니다.

mysql -h 192.168.0.1 -u user1 -p   enter

password1

MySQL> show databases;

MySQL> use database1;

MySQL> show tables;


MySQL> source  c:/test.sql  #文件导入数据库database1中对应的表格



说明1： -u， 用户名

说明2： -h，指明IP或域名

说明3： -P(大写)，指明端口 

说明4： -p（小写），即密码

데이터 출력

mysqldump

매개변수 이름	약어	의미
--주인	-시간	서버 IP 주소
--포트	-피	서버 포트 번호
--사용자	-유	MySQL 사용자 이름
--비밀번호	-피	MySQL 비밀번호
--데이터베이스		백업할 데이터베이스 지정
--모든 데이터베이스		mysql 서버의 모든 데이터베이스 백업
--콤팩트		압축 모드, 더 적은 출력 생성
--코멘트		주석 정보 추가
--완전-삽입		완료된 insert 문을 출력합니다.
--잠금 테이블		백업하기 전에 모든 데이터베이스 테이블을 잠급니다.
--no-create-db/--no-create-info		데이터베이스 생성 문 생성 비활성화
--힘		오류 발생 시 백업 작업 계속
--기본 문자 집합		기본 문자 집합 지정
--잠금 추가		데이터베이스 테이블을 백업할 때 데이터베이스 테이블 잠금

-- 테이블 테이블1 테이블2

예:

1. 두 데이터베이스 db1 및 db2
mysqldump -uroot -proot --databases db1 db2 >/tmp/user.sql 에서 모든 데이터를 내보냅니다.

2. db1의 a1 및 a2 테이블을 내보냅니다.
참고:
지정된 내보내기 테이블은 하나의 데이터베이스에 대해서만 내보낼 수 있으며 내보낸 내용은 내보낸 데이터베이스와 다릅니다. 내보내기 텍스트에는 데이터베이스 생성에 대한 판단문이 없습니다. 내보낸 지정된 테이블, 테이블 삭제 - 테이블 생성 - 데이터 가져오기만 가능합니다.
mysqldump -uroot -proot --databases db1 --tables a1 a2 >/tmp/db1.sql

3. 조건부 내보내기, db1 테이블 a1에서 id=1인 데이터를 내보냅니다.
여러 테이블의 조건이 동일할 경우 여러 테이블을 한 번에 내보낼 수 있습니다.
• 필드는 정수입니다.
mysqldump -uroot -proot --databases db1 --tables a1 --where='id=1' >/tmp/a1.sql
• 필드는 문자열이고 내보낸 SQL에는 drop이 포함되어 있지 않습니다. 테이블, 테이블 생성
mysqldump -uroot -proot --no-create-info --databases db1 --tables a1 --where="id='a'" >/tmp/a1.sql

2. 느린 쿼리

2.1 느린 쿼리 크롤링

느린 SQL 문을 최적화하려면 일반적으로 다음 단계를 수행할 수 있습니다.

1. 느린 쿼리 로그를 켜고 느린 SQL 문이 몇 초를 초과하도록 설정하고 느린 SQL 문을 캡처합니다.

2. 느린 SQL문 설명 및 분석을 통해 실행 계획을 확인합니다.

3. 인덱스를 생성하고 문장을 조정한 후 실행 계획을 확인하고 튜닝 결과를 비교합니다.

매개변수 Slow_query_log: 느린 쿼리 로그 활성화 여부를 나타냅니다. "set global Slow_query_log=on" 명령문은 느린 쿼리 로그를 일시적으로 활성화하며, 느린 쿼리 로그를 끄려면 "set global Slow_query_log=off"만 실행하면 됩니다.

파라미터 Slow_query_log_file : 느린 쿼리 로그를 파일로 저장할 때(log_output이 "FILE" 또는 "FILE, TABLE"로 설정된 경우) 느린 쿼리 로그가 어떤 로그 파일에 저장되는지 지정한다. 기본 느린 쿼리 로그 파일명은 " 호스트 이름 - Slow.log", 느린 쿼리 로그의 위치는 datadir 매개변수에 해당하는 디렉터리 위치입니다. 또한 MySQL 5.7.2 이후의 경우
느린 로그를 파일에 기록하는 경우 log_timestamps(기본값은 UTC 시간으로 우리보다 8시간 늦으며 시스템 시간 log_timestamps=SYSTEM으로 설정해야 함)를 설정하여 기록되는 시간대를 제어해야 합니다. 느린 로그 파일(이 매개변수는 일반 로그 및 오류 로그에도 영향을 미칩니다)
매개변수 long_query_time: "느린 쿼리"로 간주되기까지 "쿼리가 걸리는 시간"을 나타냅니다. 기본값은 10초로, 10초를 초과하는 쿼리는 느린 쿼리로 간주됨을 나타냅니다. "set long_query_time=5" 구문은 이제부터 실행하는 데 1초 이상 걸리는 모든 SQL 문이 느린 쿼리 파일에 기록된다는 의미입니다.
Parameter log_queries_not_using_indexes : 실행 중인 SQL 문이 인덱스를 사용하지 않는 경우 느린 쿼리 문으로 느린 쿼리 로그에 기록할지 여부를 나타내며, OFF는 기록하지 않음, ON은 기록을 의미합니다.
Parameter log_throttle_queries_not_using_indexes: log_queries_not_using_indexes를 ON으로 설정하면 인덱스를 사용하지 않는 쿼리 문도 느린 쿼리 로그에 느린 쿼리 문으로 기록됩니다. 프로덕션 환경에서는 인덱스를 사용하지 않는 명령문이 많을 수 있으므로 log_throttle_queries_not_using_indexes를 사용하여 이러한 명령문이 분당 느린 쿼리 로그에 기록되는 횟수를 제한합니다. 쿼리 로그는 빠르고 지속적으로 증가하며 관리자는 이 매개변수를 통해 이를 제어할 수 있습니다.

　　느린 쿼리 로그는 계정 번호, 호스트, 실행 시간, 잠금 시간, 반환된 행 등과 같은 정보를 제공하고, 이 정보를 사용하여 이 SQL 문에 무엇이 잘못되었는지 분석합니다. Slow Query 기능을 사용하기 시작하면 Slow Query 로그가 점점 커질 수 있으며, vi나 cat 명령어를 통해서는 Slow Query 로그를 직관적으로 볼 수 없는 경우, 이 경우에는 MySQL에 내장된 mysqldumpslow 명령어를 이용하여 분석할 수 있다. .

2.2 explain을 사용하여 쿼리문 분석하기

explain을 사용하려면 쿼리에서 select 키워드 앞에 explain이라는 단어를 추가하면 됩니다.MySQL은 쿼리를 실행하는 대신 쿼리가 실행될 때 쿼리에 플래그를 설정하고 실행 계획의 각 단계에 대한 정보를 반환합니다.

1) id: 테이블을 읽는 순서나 쿼리에서 select 절이 실행되는 순서를 반영합니다.

① ID가 동일할 경우 위에서 아래로 실행순서가 됩니다.

② ID가 다른 경우 서브쿼리인 경우 ID 일련번호가 증가하며, ID 값이 클수록 우선순위가 높아 먼저 실행된다.

③ id가 동일할 경우 하나의 그룹으로 간주하여 위에서 아래로 순차적으로 실행될 수 있으며, 모든 그룹 중에서 id 값이 클수록 우선순위가 높아져 일찍 실행된다.

(2) select_type : select의 종류를 나타내며 주로 일반 질의, 결합 질의, 하위 질의 등 복잡한 질의를 구별하는데 사용된다.

① 단순: 단순 선택 쿼리로 서브 쿼리나 유니온을 포함하지 않습니다.

② 기본: 쿼리에 복잡한 하위 부분이 포함된 경우 가장 바깥쪽 쿼리가 기본으로 표시됩니다.

③ 하위 쿼리: 선택 또는 Where 목록의 하위 쿼리입니다.

④ 파생됨: from 목록에 포함된 하위 쿼리의 경우 MySQL은 이러한 하위 쿼리를 반복적으로 실행하고 결과를 임시 테이블에 저장합니다.

⑤ Union: Union 다음에 두 번째 Select가 나타나면 Union으로 표시되고, from 절의 하위 쿼리에 Union이 포함되면 Outer Select가 Derived로 표시된다.

⑥ Union 결과 : Union 이후에 설정된 결과입니다.

(3) 테이블: 이 단계에서 접근한 데이터베이스의 테이블 이름을 표시합니다.(이 행의 데이터가 어떤 테이블을 참조하는지 표시합니다.) 때로는 실제 테이블 이름이 아니지만, 결과의 약어일 수도 있습니다. 여러 단계의 실행.

(4) 유형: MySQL이 테이블에서 필요한 행을 찾는 방법을 나타내는 테이블에 대한 액세스 방법으로, "액세스 유형"이라고도 합니다. 일반적인 액세스 유형에는 ALL, index, range, ref, eq_ref, const, system 및 NULL(왼쪽에서 오른쪽으로, 성능이 최악에서 최고로)이 포함됩니다.

① ALL: 전체 테이블 스캔, MySQL은 전체 테이블을 탐색하여 일치하는 행을 찾습니다.

② index:: Full Index Scan, 인덱스와 ALL의 차이점은 인덱스 유형이 인덱스 트리만 순회한다는 점입니다.

③ 범위(Range): 인덱스 범위 스캔, 주어진 범위만 검색하는 행의 배치를 반환하고 인덱스를 사용하여 행을 선택합니다. 일반적으로 where 문에는 between, <, >, in 등과 같은 쿼리가 나타납니다. 이 범위 스캔 인덱스는 전체 인덱스를 스캔하지 않고 인덱스의 특정 지점에서 시작하여 다른 지점에서 끝나기만 하면 되기 때문에 전체 테이블 스캔보다 좋습니다.

④ ref: Non-unique index scan, 단일 값과 일치하는 모든 행을 반환합니다. 본질적으로 인덱스 액세스입니다. 단일 값과 일치하는 모든 행을 반환합니다. 그러나 조건에 맞는 여러 행을 찾을 수도 있으므로 반드시 수행해야 합니다. 검색과 스캔을 혼합해 보세요.

⑤ eq_ref: ref와 유사하게 사용되는 인덱스가 고유 인덱스라는 점이 차이점이며, 각 인덱스 키에 대해 테이블의 하나의 레코드만 일치하며 이는 기본 키 또는 고유 인덱스 스캔에서 흔히 발생합니다. 간단히 말하면 다중 테이블 연결에서는 기본 키(Primary Key) 또는 고유 키(Unique Key)가 연관 조건으로 사용됩니다.

⑥ const, system : MySQL이 쿼리의 특정 부분을 최적화하여 상수로 변환할 때 접근하기 위해 사용하는 타입이다. 쿼리 조건에서 상수를 사용하는 경우 인덱스를 통해 한 번만 찾을 수 있으며 기본 키나 고유 키를 사용하여 인덱스에 나타나는 경우가 많습니다. 시스템은 쿼리된 테이블에 행이 하나만 있을 때 사용되는 const 유형의 특수한 경우입니다.

⑦ NULL: MySQL은 최적화 과정에서 문장을 분해하고, 실행 중에 테이블이나 인덱스에 접근할 필요도 없다.예를 들어, 인덱스 컬럼에서 최소값을 선택하는 것은 별도의 인덱스 조회를 통해 완료될 수 있다.

(5) available_keys: MySQL이 테이블에서 행을 찾기 위해 사용할 수 있는 인덱스를 나타내며, 쿼리에 포함된 필드에 인덱스가 있는 경우 해당 인덱스가 나열되지만 쿼리에서 반드시 사용되는 것은 아닙니다.

(6) key: MySQL이 실제로 사용하기로 결정한 인덱스를 표시하며, 인덱스를 선택하지 않으면 NULL로 표시된다. MySQL이 available_keys 열의 인덱스를 사용하거나 무시하도록 하려면 쿼리에 FORCE INDEX 또는 IGNORE INDEX를 사용하십시오. 쿼리에 포함 인덱스가 사용된 경우(선택 후 쿼리할 필드가 생성된 인덱스 필드와 정확히 동일함) 해당 인덱스는 키 목록에만 나타납니다.

(7) key_len: 인덱스에 사용된 바이트 수를 표시합니다.

(8) ref : 위 표의 연결 매칭 조건, 즉 인덱스 컬럼의 값을 찾기 위해 어떤 컬럼이나 상수를 사용하는지를 나타낸다.

(9) 행: 테이블 통계 및 인덱스 선택을 기반으로 필요한 레코드를 찾기 위해 읽어야 할 행 수에 대한 MySQL의 추정치를 표시합니다.

(10) 추가: 이 열에는 다른 열에 표시하기에 적합하지 않지만 실행 계획에 매우 중요한 추가 정보를 포함하여 MySQL이 쿼리를 해결하는 방법에 대한 지침과 설명이 포함되어 있습니다.

① where 사용: 테이블의 모든 정보를 읽지 않고 인덱스를 통해서만 필요한 데이터를 얻을 수 있는데, 이는 테이블의 요청된 모든 컬럼이 동일한 인덱스 부분에 있는 경우 발생하며, 이는 MySQL 서버가 해당 행을 검색한다는 의미입니다. 스토리지 엔진 이후에 필터링합니다.

② 임시 테이블 사용: 결과 집합을 저장하기 위해 MySQL이 임시 테이블을 사용해야 함을 나타냅니다. MySQL은 쿼리 결과를 정렬할 때 임시 테이블을 사용하는데, 이는 정렬(order by) 및 그룹 쿼리(group by)에서 흔히 발생합니다.

③ filesort 사용: Query에 연산별 정렬이 포함되어 있고 인덱스를 사용하여 정렬 작업을 완료할 수 없는 경우를 "파일 정렬"이라고 합니다. 인덱스 생성 시 데이터가 먼저 정렬됩니다. 일반적으로 filesort를 사용하는 이유는 다음과 같습니다. 인덱스 실패 원인으로 인해 주문한 후에는 최적화하는 것이 가장 좋습니다.

④ 조인 버퍼 사용: 연결 캐시를 사용함을 의미하며, 예를 들어 쿼리 시 다중 테이블 조인 개수가 매우 많기 때문에 설정 파일에서 조인 버퍼를 늘려준다. 이 값이 나타나는 경우 쿼리의 특정 상황에 따라 이를 개선하기 위해 인덱스를 추가해야 할 수도 있다는 점에 유의해야 합니다.

⑤ 인덱스 사용: 추가 검색 없이 인덱스 트리에 있는 정보만 사용하여 실제 행을 읽어 테이블의 컬럼 정보를 검색합니다. 테이블의 데이터 행에 대한 액세스를 방지하기 위해 해당 선택 작업에 포함 인덱스가 사용되며 이는 매우 효율적입니다. Covering index: 선택한 데이터 열은 데이터 행을 읽지 않고 인덱스에서만 가져올 수 있으며, 생성된 인덱스 수(쿼리 열이 인덱스 수보다 작거나 같음) 및 순서와 일치합니다. 커버링 인덱스를 사용하려면 꼭 필요한 컬럼만 선택하도록 주의해야 하며, select*를 사용하지 말아야 하며, 동시에 모든 필드를 함께 인덱스하면 인덱스 파일이 너무 커지고 성능이 저하됩니다.

⑥ 인덱스 조건 사용: ICP 최적화가 수행되었음을 나타냅니다.

정리하자면, explain 명령어에 대한 실행 계획을 생성한다: 먼저 쿼리 타입 타입 컬럼에 포커스를 맞춘다. all 키워드가 나타나면 전체 테이블 스캔을 뜻하며, 인덱스가 사용되지 않는다는 의미이므로 키 컬럼을 다시 살펴본다. 열이 NULL이면 인덱스가 사용되지 않음을 의미합니다. 그런 다음 행 열을 살펴보십시오. 이 열의 값이 클수록 스캔해야 할 행이 많아지고 응답 시간이 길어집니다. 마지막으로 Extra 열을 보고 단어를 피하십시오. filesort 사용 또는 임시 사용과 같이 성능에 큰 영향을 미칩니다.

3. 데이터베이스 테이블이 잠겨 있습니다.

show processlist

프로세스 상태에 wait for... lock 정보가 표시된다는 것은 현재 프로세스가 lock을 기다리고 있다는 의미이다.

구현하다

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

여러 데이터 조각 가져오기:
trx_mysql_thread_id

해당 스레드를 종료하는 명령을 실행하십시오.

kill

참고:

mysql 느린 쿼리 최적화 - Bai Yunying - Blog Park