MySQL 튜닝 소개

一 소개

CPU의 주파수, 메모리의 크기에 대해 이야기하지 않겠습니다. (이것은 인덱스만큼 중요하지만 그렇지 않습니다. 이 기사의 내용), 하드 디스크 탐색 시간. mysql 튜닝을 생각하면 최소한 실행 계획 설명, 느린 sql 로그, 이전 프로필 명령, 새로운performance_schema 성능 보기 및 information_schema의 현재 트랜잭션 및 메모리 사용량 정보에 대한 관련 테이블, 엔진 innodb 상태 표시 진단 정보 등을 알아야 합니다. 메트릭스의 일부 tps, qps 및 iops 표시기로 사용됩니다. (관련 권장 사항: "MySQLTutorial")

위는 튜닝을 위해 준비된 몇 가지 도구이며, 데이터베이스는 고가용성을 위해 크고 작은 많은 기능을 제공합니다. : 복제, 그룹 복제, 파티션, 파일 링크: 즉, 로그 로그와 데이터 파일을 각각 다른 하드 디스크에 배치할 수 있습니다. 작은 것에는 열 계산, 열에 대한 해시 계산, 인덱스 병합, 인덱스 푸시다운, MRR, BKA, Loose Index 및 기타 알고리즘, 채우기 요소 등이 포함됩니다.

물론 뷰 인덱스와 분산 분할 뷰가 없고 Join은 Nested만 지원하는 것이 mysql의 단점인데 SQL Server Join 알고리즘은 loop while hash 3가지 형태를 지원하는데, 이는 크게 조인 속도가 향상됩니다. MySQL에는 성능 향상을 위한 많은 기능이 없습니다. 정적 테이블과 같은 다른 기능은 하위 쿼리에서 함수를 사용하지 마십시오. 문자열이 아닌 열과 blob 열은 항상 다른 숫자보다 낫습니다. 또는 시간 열이 느립니다. Join |order by|group은 하드 디스크에 임시 테이블을 생성하는 것을 허용해서는 안 됩니다. 물론 이는 메모리, 좁은 테이블 및 넓은 테이블 설계 등과 관련이 있습니다. 귀하의 비즈니스 유형에 따라 다릅니다.

최적화를 시작하는 방법에는 두 가지가 있습니다. 하나는 런타임, 즉 실행 중인 서버에서 최적화하는 것이고, 다른 하나는 개발 프로세스 중에 시작하는 것입니다. 어느 것이든performance_schema가 필요합니다.

성능_스키마 설명

성능 보기는 모든 데이터베이스에서 찾을 수 있으며, SQL 서버는 dm_ 일련의 *로 시작하는 메모리 테이블 그리고 mysql은 performance_schema 라이브러리의 다양한 테이블입니다. 먼저 입구 테이블을 살펴보겠습니다.

SELECT * FROM setup_timers; -- 计时定义表
select * from setup_actors; -- 那些用户需要收集信息
select * from Setup_objects; -- 那些对象需要收集信息，比如mysql表，
select * from setup_consumers; -- 那些仪器的分类需要收集
select * from setup_instruments; -- 收集仪器，每一个功能点都会有仪器的事件，开始和结束，然后开启那个仪器，就会收集那个仪器的数据

#🎜 🎜#먼저 Performance_schema를 켜는 스위치를 살펴보겠습니다.

show variables like 'performance_schema' -- 这是一个read only变量

OFF 인 경우 구성 파일에서 활성화해야 합니다.

그럼 이 엔트리 테이블을 하나씩 소개하겠습니다.

1, setup_actors 테이블

모든 사용자 모두 수집 가능합니다.

2, Setup_objects

　

해당 개체 할 수 있다 테이블인지 트리거인지 등의 컬렉션입니다.

두 개의 열 컨트롤을 끄는 경우 활성화 및 시간 제한 필드가 아니요로 설정되어 있으며, 이는 이 테이블의 경우입니다.

3 setup_consumers

　

# 🎜🎜# 이벤트 분류. 단계는 서버에서 실행되는 문의 처리 단계입니다. 프로파일 방법은 나중에 제거되므로 권장되지 않습니다. 트랜잭션(Transaction)은 트랜잭션 등의 이벤트 모음입니다.

4

setup_instruments　이것은 다음과 같은 주요 이벤트 모니터링 도구입니다.

# 🎜 🎜#

5 마지막으로 setup_timers가 있는데, 이는performance_timers와 함께 해당 악기 범주의 시간 유형을 다음과 같이 정의합니다.

#🎜 🎜#

CYCLE: CPU 클럭, TIMER_FREQUENCY는 몇 초가 있는지, TIMER_RESOLUTION은 매번 증가하는 양, 마지막으로 시간을 얻는 빈도입니다.

Three에서는 Performance_schema를 사용하여 사전 파일 데이터를 얻습니다

관련 기기 열기: #🎜🎜 #위 악기 분류표의 정보를 살펴보겠습니다setup_consumers

. stage에 대한 행이 모두 NO이므로 동시에 YES로 변경해야 합니다. 명령문 모니터링 테이블에는 Turn on 명령문도 필요합니다:

UPDATE setup_consumers SET ENABLED = 'YES'
       WHERE NAME LIKE '%stage%';
UPDATE setup_consumers SET ENABLED = 'YES'
WHERE NAME LIKE '%statements%';

그런 다음 무대 악기를 켜세요

#🎜 🎜#

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
       WHERE NAME LIKE '%stage/%';   -- 开启所有执行步骤的监控
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE '%statement/%';

#🎜🎜 #

sql 기반 실행

 select * from quartz.TestOne

쿼리 이 문의 쿼리 ID:

#🎜 🎜#

SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT
       FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%quartz%';

那么id就是509

然后执行性能监控表：

SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
       FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=509

 

内容和老版本的profile结果一样。

主要看下stage/sql/Sending data这一行，这一行是主要io相关的事件，一般情况下，sql慢了，而这一行数值比较大，那肯定硬盘读数据慢了或者有锁冲突。

那么就是用error log，有死锁，mysql会将死锁信息打入error日志，show engine innodb status只是全局的一些信息，如果要想看详细的再去监控对应的instrument。

而且目前mysql8多支持NOWAIT和skiplocked两个语句，用法还是select.. from 表明 for update/for nowait等，非常灵活的解决了死锁的处理方式，当然你也可以让其事务隔离级别为脏读级别，但是并不能解决更多的业务类型，设置死锁超时也是一个可行的办法。

위 내용은 MySQL 튜닝 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!