MySQL에서 명령문을 실행하는 전체 과정은 무엇입니까?

1. Mysql의 논리적 아키텍처

Mysql의 논리적 아키텍처는 전체적으로 서버 계층과 스토리지 엔진 계층의 두 부분으로 나뉩니다.

스토리지 엔진과 관련되지 않은 작업은 서버 계층에서 완료되며, 스토리지 엔진 계층은 데이터 액세스를 담당합니다.

다음은 위 그림의 과정에 따른 각 단계의 기능을 예로 들어 설명하겠습니다.

2. 커넥터

이 단계는 주로 연결 및 권한 확인을 관리하는 단계입니다.

클라이언트와 커넥터 사이에 이루어지는 mysql -u root -p 등의 클라이언트 연결 관리를 담당합니다. 연결은 긴 연결과 짧은 연결로 나누어 사용하는 것이 좋습니다. 연결이 상대적으로 복잡하기 때문에 연결이 오래 걸립니다. 그러나 긴 연결에도 최적화할 여지가 있습니다. 즉, 긴 연결이 너무 많으면 대규모 쿼리 작업이 실행될 때 더 많은 메모리를 차지하게 됩니다. mysql -u root -p，就是客户端与连接器之间完成的，连接分为长连接和短连接，建议使用长连接，因为建立连接是相对复杂的一个过程。但是长连接也有优化的空间，即长连接过多，随着执行大的查询操作，会占用较多的内存。

建立连接完成之后，连接器会判断该用户的权限，之后用户的操作都会基于权限来判定是否允许。

3.分析器

这一步主要是词法分析和语法分析。

词法分析主要是判定用户想做什么，比如select 就是想要查询。

语法分析主要是判定用户输入的SQL是否符合Mysql的语法。

4.优化器

经过分析器，Mysql已经知道用户想要干什么了，但是对于相同的一条SQL语句，对于Mysql具体实施的时候，可能有多种方法去实现，效率也就不一样。

在优化器这一步，mysql需要判定怎么样执行才是最优的效率。

5.执行器

这一步主要是操作引擎和返回结果。操作存储引擎层以遍历数据表，查找符合条件的数据并将其返回给客户端。

6.Mysql执行一条更新语句的过程

与一条SQL查询语句相同的是，在Mysql中同样要经过连接器、分析器、优化器、执行器，也要用到存储引擎来进行数据的存取。

不同的是，更新语句需要涉及到两个重要的日志模块，redo log和binlog

7.redo log

一家饭店生意红火，但作为一家饭店来说，免不了每天都有赊账和来还账的。

如果有大量的赊账和还账的人，老板将无法用一块粉板来记录一个月的赊账记录。

所以老板想到可以把所有的赊账记录写到账本上，而粉板上写的都是短时间的，等下班了之后，拿粉板上的和账本进行对账。

在这个例子中，粉板就是redo log，账本就是mysql中的记录，我们用还账类比一下mysql的更新过程，如果每次有人更新，我们都去mysql中找到这条记录，效率很低，所以mysql的思路和这个老板一致，更新操作先放到redo log中，过一段时间再慢慢消化。

这种思路叫WAL技术，即Write Ahead Logging技术，先写日志，再写磁盘。

老板必须停下手头的工作，如果粉板已经满了而且老板还没有下班。mysql中的redo log总共可以记录4GB的操作

当write pos 追上check point，mysql这个老板就要去处理一下redo log了。

除此之外，有了redo log持久化，数据库即使异常重启也不会丢日志，这是crash saf

연결이 설정된 후 커넥터는 사용자의 권한을 결정하고 사용자의 작업은 권한에 따라 결정됩니다.

3. 분석기

이 단계는 주로 어휘 분석과 구문 분석입니다.

어휘 분석은 주로 사용자가 원하는 작업을 결정하는 데 사용됩니다(예: 쿼리 수단 선택).

구문 분석은 주로 사용자가 입력한 SQL이 Mysql의 구문과 일치하는지 확인하는 것입니다.

• 4. Optimizer
  분석기 후에 Mysql은 사용자가 무엇을 하려는지 이미 알고 있지만 동일한 SQL 문에 대해 Mysql을 구현할 때 이를 구현하는 방법이 여러 가지 있을 수 있으며 효율성이 달라집니다.
• 최적화 단계에서 mysql은 최적의 효율성을 위해 실행 방법을 결정해야 합니다.
  5. Executor
• 이 단계는 주로 엔진을 작동하고 결과를 반환하는 단계입니다. 스토리지 엔진 계층을 작동하여 데이터 테이블을 순회하고 기준에 맞는 데이터를 찾아 클라이언트에 반환합니다.
  6. Mysql이 업데이트 문을 실행하는 과정

SQL 쿼리문과 마찬가지로 Mysql도 커넥터, 분석기, 최적화 프로그램, 실행기를 거쳐야 하며, 데이터 액세스를 처리하기 위해 스토리지 엔진도 사용합니다.

다릅니다. 업데이트 문에는 두 가지 중요한 로그 모듈인 redo log와 binlog가 포함되어야 합니다

7.redo log

레스토랑이 호황을 누리고 있지만 레스토랑으로서 매일 신용 계좌와 상환이 불가피합니다.

신용을 만들고 빚을 갚는 사람이 많으면 사장님이 핑크보드를 이용해 한 달간의 신용기록을 기록할 수 없게 됩니다.

🎜 그래서 사장님은 장부에 모든 신용 기록을 적을 수 있다고 생각했고, 핑크색 판에 적힌 내용은 퇴근 후 핑크색 판을 사용하여 장부를 조정하곤 했습니다. 🎜🎜이 예에서 분홍색 보드는 redo log이고, 원장은 mysql의 기록을 상환 비유로 사용하여 mysql의 업데이트 프로세스를 비교해 보겠습니다. to 이 레코드는 mysql에서 발견되는데 이는 매우 비효율적이므로 mysql의 아이디어는 이 상사와 일치합니다. 업데이트 작업은 먼저 redo log에 배치된 다음 천천히 소화됩니다. 잠시 후. 🎜🎜이 아이디어를 WAL 기술이라고 하는데, 이는 Write Ahead Logging 기술입니다. 로그를 먼저 쓴 다음 디스크를 씁니다. 🎜🎜핑크보드가 가득 차고 아직 퇴근하지 않았다면 상사는 하던 일을 멈춰야 합니다. mysql의 redo 로그는 총 4GB의 작업을 기록할 수 있습니다🎜🎜🎜🎜쓰기 pos가 체크 포인트를 따라잡으면 MySQL의 상사는 redo 로그를 처리해야 합니다. 🎜🎜또한 다시 실행 로그 지속성을 사용하면 데이터베이스가 비정상적으로 다시 시작되더라도 로그가 손실되지 않습니다. 이는 충돌 안전 메커니즘이지만 여전히 비용을 지불해야 합니다. 예, 리두 로그는 innodb 스토리지 엔진에 고유합니다. 🎜🎜8.bin log🎜🎜binlog는 서버 계층 로그이며 모든 스토리지 엔진에 적용할 수 있습니다. 🎜🎜그렇다면 binlog가 있는데 왜 innodb 스토리지 엔진 전용 redo 로그를 생성해야 할까요? 🎜🎜mysql은 처음에는 innodb 엔진이 없었고, binlog를 사용하는 myisam 엔진이 있었는데, binlog는 아카이브에만 국한되어 있고 충돌 방지 메커니즘도 없었기 때문에 redo 로그를 추가했습니다. 🎜🎜🎜🎜redo 로그는 innodb 스토리지 엔진에 고유하고 binlog는 서버 계층에 고유합니다🎜🎜🎜🎜redo 로그는 물리적 로그를 저장하고, binlog는 논리 로그🎜🎜🎜🎜redo 로그는 위에서 언급한 대로 4GB를 지원하는 경우 크기가 너무 크므로 처리하여 덮어써야 합니다. binlog 로그가 log🎜🎜🎜🎜 파일로 채워지면 새 로그 파일이 생성됩니다. 🎜🎜🎜다음은 ID 2의 데이터 행을 업데이트하는 예입니다. 🎜🎜🎜그림의 밝은 상자는 InnoDB 내에서 실행됨을 나타내고 어두운 상자는 실행기에서 실행됨을 나타냅니다. 🎜🎜🎜🎜

• 실행자는 먼저 라인 ID=2를 얻기 위해 엔진을 찾습니다. ID는 기본 키이며 엔진은 이 행을 찾기 위해 트리 검색을 직접 사용합니다. ID=2인 행이 있는 데이터 페이지가 이미 메모리에 있으면 실행기로 직접 반환됩니다. 그렇지 않으면 먼저 디스크에서 메모리로 읽어온 다음 반환해야 합니다.

• 실행자는 엔진에서 제공한 행 데이터를 가져오고 이 값에 1을 더합니다. 예를 들어 이전에는 N이었지만 지금은 N+1이고 새 데이터 행을 가져온 다음 엔진을 호출합니다. 이 새로운 데이터 행을 쓰는 인터페이스입니다.

• 엔진은 이 새로운 데이터 행을 메모리에 업데이트하고 업데이트 작업을 리두 로그에 기록합니다. 이때 리두 로그는 준비 상태입니다. 그런 다음 실행이 완료되었으며 언제든지 트랜잭션을 제출할 수 있음을 실행자에게 알립니다. 작업을 실행하는 동안 실행 프로그램은 binlog를 생성하고 이를 디스크에 씁니다.

• Executor는 엔진의 커밋 트랜잭션 인터페이스를 호출하고, 엔진은 방금 작성된 Redo 로그를 커밋 상태로 변경하며 업데이트가 완료됩니다.

위 내용은 MySQL에서 명령문을 실행하는 전체 과정은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!