mysql에서는 메모리 데이터 페이지와 디스크 데이터 페이지의 내용이 일치하지 않는 경우 메모리 페이지를 더티 페이지라고 합니다. 더티 페이지 플러시 시나리오: 1. 리두 로그가 가득 차면 MySQL은 모든 업데이트 작업을 일시 중지하고 로그의 이 부분에 해당하는 더티 페이지를 디스크에 동기화합니다. 2. 시스템 메모리가 부족하면 일부 데이터 페이지가 필요합니다. 제거되는 경우 더티 페이지가 더티 페이지인 경우 먼저 더티 페이지를 디스크에 동기화해야 합니다. 3. MySQL은 시스템이 유휴 상태일 때 기회가 있을 때 메모리 데이터를 디스크에 동기화할 것이라고 생각합니다. . 이 경우에는 성능 문제가 없습니다.
이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.
보통 매우 매우 신속하게 모든 업데이트 작업이 메모리와 로그에 기록됩니다.
이때, 메모리 데이터 페이지와 디스크 데이터 페이지의 내용이 일치하지 않는데, 이를 더티 페이지
라고 합니다. 不会马上同步
到磁盘数据页,这时内存数据页跟磁盘数据页内容不一致,我们称之为脏页
。
这里面就涉及 mysql 的内存管理机制
缓冲区中包含这三大类列表。分别为:LRUList
、FreeList
、FlushList
。
在数据库刚启动时,LRUlist中没有数据页
。FreeList存放空闲页。
注意:这时这个页既在LRUlist中,又在FlushList中。
总结:LRUList(管理已经被读取的页)和FreeList(管理空闲的页)用来管理页的可用性;FlushList(管理脏页)用来管理脏页的刷新
在脏页数据同步到磁盘过程中,如果对该磁盘数据页执行 SQL 语句。执行速度就会变慢
如果数据修改和读取只依赖内存的缓冲区,那么一旦数据库宕机,内存中的数据都会丢失。所以MySQL使用之前讲过的redo log来实现异常重启的数据恢复。
简单来说,就是在更新缓冲区之前,先写入redo log,保证异常重启之后可以正常恢复缓冲区中的数据。
数据库宕机,内存数据丢失
。所以需要刷新到磁盘。所以自然而然,我们就一定需要把内存中的脏页按照某种规则刷新到磁盘中,有了刷新这个操作,缓冲区的大小问题和redo log的大小问题都可以解决。
当 redo log 写满
,mysql就会暂停所有更新
操作,将同步这部分日志对应的脏页同步到磁盘
。
系统内存不足
时,需要淘汰
一部分数据页,如果淘汰的是脏页
,就要先将脏页同步到磁盘
。
MySQL 认为系统空闲
的时候,有机会就同步
内存数据到磁盘,这种没有性能问题。
MySQL 正常关闭
,MySQL 会把内存的脏页都同步到磁盘
上,这样下次 MySQL 启动的时候,就可以直接从磁盘上读数据,启动速度会很快。这种没有性能问题。
如果是 redo log 写满了
要尽量避免redo log 写满
。否则整个系统的更新都会停止。此时写的性能变为 0
,必须等待该日志对应脏页同步完成
LRUList
, FreeList
, FlushList
입니다. 🎜🎜데이터베이스가 처음 시작되면 LRUlist에 데이터 페이지가 없습니다
가 있습니다. FreeList는 무료 페이지를 저장합니다. 🎜🎜🎜페이지를 읽어야 할 경우 FreeList에서 데이터를 읽은 후 LRUlist에 저장됩니다. 🎜🎜FreeList에 비어 있는 페이지가 없으면 마지막 페이지입니다. LRU 목록의 페이지는 LRU 알고리즘에 따라 제거됩니다. 🎜🎜LRUlist의 페이지가 수정되면 해당 페이지는 더티 페이지가 되며 이 페이지도 FlushList🎜🎜🎜🎜에 추가됩니다. 이번에는 페이지가 LRUlist와 FlushList 모두에 있습니다. 🎜🎜🎜요약: LRUList(읽은 페이지 관리) 및 FreeList(무료 페이지 관리)는 페이지 가용성을 관리하는 데 사용됩니다. FlushList(더티 페이지 관리)는 더티 페이지 새로 고침을 관리하는 데 사용됩니다.🎜🎜더티 페이지의 데이터 동기화 디스크로 이동하는 과정에서 디스크 데이터 페이지에 SQL문이 실행되는 경우. 실행 속도가 느려집니다🎜데이터베이스 다운타임 및 메모리 데이터 손실
발생합니다. 따라서 디스크에 플러시해야 합니다. 🎜🎜리두 로그가 무한히 크거나 파일이 많으면 시스템에 많은 수정 작업이 발생하게 되며 시스템이 다운되면 복구 시간이 매우 길어집니다. 🎜🎜🎜따라서 특정 규칙에 따라 🎜메모리의 더티 페이지를 디스크로 플러시🎜해야 합니다. 그러면 버퍼 크기 문제와 리두 로그 크기 문제가 해결될 수 있습니다. 🎜🎜🎜버퍼는 디스크에 유지될 수 있으므로 무한할 필요가 없습니다. 🎜🎜리두 로그는 무한할 필요가 없습니다. 왜냐하면 일단 디스크에 지속되면 리두 로그의 데이터 중 해당 부분이 삭제되기 때문입니다. 출시될 수 있습니다. 🎜🎜다시 실행 로그가 가득 차면
, mysql은 모든 업데이트 작업을 일시 중지
하고 로그의 이 부분에 해당하는 더티 페이지를 디스크에 동기화
합니다. 🎜🎜🎜🎜시스템 메모리가 부족
할 때 일부 데이터 페이지를 제거
해야 합니다. 더티 페이지
를 제거하려면, 먼저 제거하세요. 더티 페이지는 디스크에 동기화됩니다
. 🎜🎜🎜🎜MySQL은 시스템이 유휴
일 때 기회가 있을 때 메모리 데이터를 디스크에 동기화
할 것이라고 생각합니다. 이 경우 성능 문제는 없습니다. . 🎜🎜🎜🎜MySQL이 정상적으로 종료
되고, MySQL은 메모리에 있는 모든 더티 페이지를 디스크에
동기화하므로 다음에 MySQL이 시작될 때 다음에서 직접 읽을 수 있습니다. 디스크 데이터, 시작 속도가 매우 빠릅니다. 이에 대한 성능 문제는 없습니다. 🎜🎜🎜재실행 로그가 가득 차지
를 피하세요. >. 그렇지 않으면 전체 시스템의 업데이트가 중지됩니다. 이때 쓰기 성능은 0이 되며
, 더티 페이지 동기화가 완료
될 때까지 기다려야 업데이트가 가능합니다. SQL문 실행 속도가 매우 느립니다. 🎜🎜【관련 추천: 🎜mysql 비디오 튜토리얼🎜】🎜위 내용은 MySQL 더티 페이지란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!