MySQL 8.0 DDL 원자 성 특성 및 실현 원리

1.DDL 원자 성 개요
8.0 이전에 통 일 된 데이터 사전 dd,server 층 과 엔진 층 에 각각 메타 데이터 가 있 었 습 니 다.sever 층 의 메타 데 이 터 는(.frm,.opt,.par,.trg 등)을 포함 하여 표 정의,파 티 션 표 정의,트리거 정의 등 정 보 를 저장 하 는 데 사 용 됩 니 다.innodb 층 에 도 표 정보,색인 정보 등 을 포함 한 메타 데이터 가 있 습 니 다.이 두 가지 메타 데 이 터 는 일치 성 을 확보 하지 못 해서 이상 한 상황 에서 메타 데이터 가 일치 하지 않 는 문제 가 존재 할 수 있 습 니 다.전형 적 인 장면 에서 표 삭제 작업,sever 층 의 frm 는 성공 적 으로 삭제 되 었 으 나 엔진 층 데이터 사전 은 업데이트 되 지 않 았 습 니 다.재 명 표를 만 드 는 데 실패 한 문제.같은,예 를 들 어 drop table t1,t2;t1 만 삭 제 했 고 t2 는 여전히 존재 하 는 등 문제 가 있 을 수 있 습 니 다.
8.0 의 중요 한 작업 은 데이터 사전 을 통일 시 키 고 DD(데이터 사전)모듈 을 독립 시 키 며 server 층 의 메타 데 이 터 를 폐기 하고 innodb 의 메타 데 이 터 를 DD 인터페이스 로 추상 화하 여 server 층 과 innodb 층 이 공용 하도록 하 는 것 이다.DD 에 더 해 DDL 의 원자 적 특성 을 도입 해 DDL 조작 을 다 하거나 아예 하지 않 는 능력 을 확보 했다.이 논 리 를 실현 하 는 관건 은 ddl 과 관련 된 수정 입 니 다.dd 데이터 사전 수정,엔진 층 의 수정(파일 생 성,tablespace 초기 화,btree 생 성 등)과 binlog 를'사무'로 하고 업무 의 원자 적 특징 을 이용 하여 ddl 작업 의 원자 성 을 확보 하 는 것 입 니 다.
2.DDL 원자 성 실현 원리
원자 성 을 실현 하 는 관건 은 dd 데이터 사전 의 수정 을 확보 하 는 것 이다.엔진 층 의 수정 과 binlog 작성 은 하나의 업무 이다.MySQL 에 있 는 XA 사무 체 제 는 DML 사무 와 binlog 의 일치 성 을 효과적으로 보장 할 수 있 습 니 다.한편,ddl 데이터 사전 도 innodb 엔진 을 통 해 저장 되 기 때문에 dd 데이터 사전 수정 과 binlog 가 일치 하 는 것 이 쉽 습 니 다.그러면 해결 해 야 할 문 제 는 dd 데이터 사전 과 엔진 층 의 수정 일치 성 이다.엔진 층 의 수정 은 모두 redo 를 기록 하 는 것 이 아니다.예 를 들 어 파일 을 만 들 거나 rename 파일 이름 을 만 들 거나 cache 를 정리 하 는 등 XA 체 제 를 통 해 문 제 를 간단하게 해결 할 수 없 기 때문에 8.0 은 DDL 세트 도 도입 했다.LOG 메커니즘.구체 적 으로 redo 를 기억 하지 않 는 작업 을 로그 로 기록 하 는 방식 으로 dl 에 기록 하 는 것 입 니 다.log 표 에서 이 시 계 는 innodb 엔진 표 입 니 다.dl 을 보증 합 니 다.log 데 이 터 는 dd 데이터 사전 수정 과 일치 하 며,최종 적 으로 dd 데이터 사전 수정,엔진 계층 의 수정 과 쓰기 binlog 일치 성 문 제 를 해결 합 니 다.
3.DD 도입 전후 대비
 ​
​  ​
4.DDL 조작 실현 논리
ddl 도입log 표 이후 ddl 작업 은 기 존의 기초 위 에서 약간의 변화 가 있 는데 주로 두 가지 가 있다.하 나 는 ddl 작업 을 수행 하 는 과정 에서 ddl 작업 이 ddl 로 기 록 될 것 이다.로그 테이블 에서;또 하 나 는 post 가 추가 되 었 습 니 다.ddl 단계,ddl 사 무 를 제출 한 후 ddl 의 마무리 동작 을 합 니 다.예 를 들 어 drop-table,실제 물리 파일 삭 제 는 post-ddl 단계 에서 합 니 다.post-ddl 에서 하 는 일 은 주로 ddl-log 내용 을 읽 고 재생 하여 실행 하 는 것 입 니 다.ddl 작업 유형 은 다음 과 같 습 니 다:

enum class Log_Type : uint32_t {
/** Smallest log type */
SMALLEST_LOG = 1,
/** Drop an index tree */
FREE_TREE_LOG = 1,
/** Delete a file */
DELETE_SPACE_LOG,
/** Rename a file */
RENAME_SPACE_LOG,
/** Drop the entry in innodb_dynamic_metadata */
DROP_LOG,
/** Rename table in dict cache. */
RENAME_TABLE_LOG,
/** Remove a table from dict cache */
REMOVE_CACHE_LOG,
/** Alter Encrypt a tablespace */
ALTER_ENCRYPT_TABLESPACE_LOG,
/** Biggest log type */
BIGGEST_LOG = ALTER_ENCRYPT_TABLESPACE_LOG
};

인 노 db 통과 하기print_ddl_logs 스위치,ddl 과정 에서 innodb 에 기록 되 는 것 을 볼 수 있 습 니 다.ddl_로그 표 의 내용.다음은 몇 가지 전형 적 인 ddl 조작 으로 만들어 진 ddlddl 의 원자 성 을 어떻게 보장 하 는 지 로그 로 설명 합 니 다.
4.1 create table
문장:create table dtt(id int primary key, c1 int); 

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=352, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log delete : 352
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=353, thread_id=23, table_id=1128, new_file_path=mysql/dd_tt]
[InnoDB] DDL log delete : 353
[InnoDB] DDL log insert : [DDL record: FREE, id=354, thread_id=23, space_id=71, index_id=231, page_no=4]
[InnoDB] DDL log delete : 354
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log post ddl : end for thread id : 23 

설명:
1.모든 insert 작업 은 하나의 단독 사무 이 며,대응 하 는 역방향 delete 작업 은 전체 dl 업무 의 일부분 입 니 다.
2.insert 작업 기록 은 파일 작업 의 역방향 작업 입 니 다.예 를 들 어 tablespace,역방향 조작 은 deletespace_log。
3.ddl 업무 가 최종 적 으로 성공 하면 모든 역방향 delete 작업 도 최종 적 으로 유효 합 니 다.ddl로그 로그 가 정상적으로 정리 되 었 습 니 다.ddl 업무 수행 중 실패(예 를 들 어 인 스 턴 스 crash)하면 delete 작업 스크롤 백,ddllog 표 에 3 개 남아 있 는 insertlog,recover 시,이 dl 리 플레이로그,즉 ddl 과정 에서 발생 하 는 쓰레기 를 청소 할 수 있 습 니 다.
4.crash-recovery 시,binlog 가 떨 어 졌 다 면,대응 하 는 dl 사 무 는 prepare 상태 에 있 습 니 다.최종 사 무 는 제출 해 야 합 니 다.dllog 가 깨끗이 정리 되 었 습 니 다.만약 binlog 가 디스크 에 떨 어 지지 않 았 다 면,ddl 사 무 는 스크롤 백 이 필요 합 니 다.ddllog 표 에는 3 개의 기록 이 남아 있 습 니 다.고장 복구 가 끝 난 후에 replay 가 필요 합 니 다.사실은 파일 을 만 들 고 btree 를 만 드 는 등 역방향 작업 을 하여 스크롤 백 후 깨끗 한 지 확인 해 야 합 니 다.
4.2 drop table
drop table dtt;

[InnoDB] DDL log insert : [DDL record: DROP, id=355, thread_id=23, table_id=1128]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=355, thread_id=23, table_id=1128]
[InnoDB] DDL log post ddl : end for thread id : 23

설명:drop 작업 에 있어 서 실행 과정 에서 dl 만 조작 합 니 다.log,진정한 drop 물리 표 작업 을 하지 않 습 니 다.post-ddl 단계 에서 ddl 읽 기log 표 의 기록 과 replay 를 통 해 실제 삭제 동작 을 합 니 다.실행 과정 에서 crash 가 발생 하면 전체 dl 사무 가 굴 러 갑 니 다.이 중 에는 dl 도 포함 되 어 있 습 니 다.로그 의 내용 도 스크롤 백 됩 니 다.그러면 전체 drop 작업 은 발생 하지 않 은 것 과 같 습 니 다.
4.3  add index
문장:alter table dtt add index idx_c1(c1);

[InnoDB] DDL log insert : [DDL record: FREE, id=360, thread_id=23, space_id=72, index_id=233, page_no=5]   
[InnoDB] DDL log delete : 360
[InnoDB] DDL log post ddl : begin for thread id : 23                
[InnoDB] DDL log post ddl : end for thread id : 23

설명:건축 색인 은 건축 표 와 유사 합 니 다.insert 작업 부분 은 하나의 사무 입 니 다.따로 제출 하고 세트 는 delete 작업 을 기록 합 니 다.이 작업 은 전체 dl 업무 의 일부분 입 니 다.업무 가 최종 적 으로 제출 되면 dl-log 내용 이 삭 제 됩 니 다.트 랜 잭 션 이 최종 적 으로 스크롤 백 되면 dl-log 에 FREE-log 가 남아 있 고,replay 를 통 해 만들어 진 색인 을 정리 하여 스크롤 백 효 과 를 얻 을 수 있 습 니 다. 
4.4  drop index
문장:alter table dtt drop index idx_c1;

[InnoDB] DDL log insert : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log replay : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL log post ddl : end for thread id : 23 

설명:
drop table 과 유사 합 니 다.실행 과정 에서 로그 만 기록 하고 post-ddl 단계 에서 만 실제 삭제 작업 을 할 수 있 습 니 다.
4.5 add column
문장:alter table dtt add column c2 int;

[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log post ddl : end for thread id : 23

설명:
8.0 가 열 은 인 스 턴 트-ddl 로 메타 데이터 만 수정 하고 dml 사무 와 유사 하 며 ddl-log 에 의존 하지 않 고 원자 성 을 확보 합 니 다.
4.6 drop column
문장:alter table dtt drop column c2;
구문 분해:
1.prepare 단계:

create table #sql-ib1129-2815969725;

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=362, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1129-2815969725.ibd] 
[InnoDB] DDL log delete : 362
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=363, thread_id=23, table_id=1130, new_file_path=mysql/#sql-ib1129-2815969725]  
[InnoDB] DDL log delete : 363
[InnoDB] DDL log insert : [DDL record: FREE, id=364, thread_id=23, space_id=73, index_id=234, page_no=4]         
[InnoDB] DDL log delete : 364

2.peform 단계:ddl-log 에 대한 아무것도
3.commit 단계:
3.1 alter table dd_tt rename to #sql-ib1130-2815969726;

[InnoDB] DDL log insert : [DDL record: DROP, id=365, thread_id=23, table_id=1129]     <br>[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=366, thread_id=23, space_id=72, old_file_path=./mysql/#sql-ib1130-2815969726.ibd, new_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log delete : 366
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=367, thread_id=23, table_id=1129, old_file_path=mysql/#sql-ib1130-2815969726, new_file_path=mysql/dd_tt]
[InnoDB] DDL log delete : 367

역방향 조작:alter table mysql/#sql-ib1130-2815969726 rename to dd_tt;3.2 alter table #sql-ib1129-2815969725 rename to dd_tt;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

역방향 조작:alter table dd_tt rename to mysql/#sql-ib1129-2815969725;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

기록 작업 만 post-ddl 단계 에서 청소 합 니 다.                                                              
post-ddl 단계:

drop table #sql-ib1130-2815969726;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

설명:drop column 은 copy 형식의 dl 입 니 다.기본 논 리 는 임시 표를 새로 만 들 고 데 이 터 를 복사 하 며 마지막 으로 rename 작업 을 다시 하 는 것 입 니 다.주로 4 단계 포함:
1.prepare 단계:임시 표를 만 드 는 과정 은 표를 만 드 는 과정의 dl-log 작업 과 유사 합 니 다.insert-log 는 단독 업무 로 직접 제출 하고 delete-log 는 전체 업무 의 일부분 입 니 다.
이 단계 에 이상 이 발생 하면 ddl-log 표 에 역 조작 기록 이 남아 있 습 니 다.crash-recovery 시 replay 에서 청 소 를 할 수 있 습 니 다.
2.peform 단계:데이터 복사 가 끝나 고 online-ddl 논 리 를 실현 합 니 다.
3.데 이 터 를 복사 한 후에 rename 교환 표 이름 작업 을 해 야 합 니 다.
   1)DROP,임시 테이블 삭제
   2)RENAME SPACE/TABLE 은./mysql/\#sql-ib 1130-2815969726.ibd 를 d 로 이름 바 꿉 니 다.tt.idb
   3)REANAME SPACE/TABLE 는 ddtt.idb 이름 은/\#sql-ib 1129-2815969725.idb 입 니 다.
   4)오래된 표 sql-ib1130-2815969726.ibd 작업 을 기록 삭제 하고 post-ddl 단계 에서 실제 삭 제 를 합 니 다.
이 단계 에 이상 이 생기 면 같은 insert-log 단독 사무,delete 는 전체 업무 의 일부분 으로 insert-log 는 dl-log 표 에 남아 있 습 니 다.replay 를 통 해 청소 하고 dd 를 복원 할 수 있 습 니 다.tt 의 데 이 터 를 정리 하고 임시 표\#sql-ib 1130-2815969726.ibd.
4.post-ddl 단계:
  1).오래된 파일 을 물리 적 으로 삭제 합 니 다./mysql/\#sql-ib1130-2815969726.ibd
  2).mysql.innodb 청소dynamic_metadata 에 관 한 정보.
주의해 야 할 것 은 ddl-log 표 에 저 장 된 내용 이 실제 역방향 으로 작 동 하기 때문에 ddl-log 를 수집 할 때 실제 적 으로 역순 으로 수집 하여 재생 하 는 것 입 니 다.
4.7 truncate table
문장
구문 분해:
1.rename dd_tt to #sql-ib1130-2815969727;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=372, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd, new_file_path=./mysql/dd_tt.ibd
[InnoDB] DDL log delete : 372

2.drop table #sql-ib1130-2815969727;

[InnoDB] DDL log insert : [DDL record: DROP, id=373, thread_id=23, table_id=1130]     
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd]

3.create table dd_tt;

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=375, thread_id=23, space_id=74, old_file_path=./mysql/dd_tt.ibd]     
[InnoDB] DDL log delete : 375
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=376, thread_id=23, table_id=1131, new_file_path=mysql/dd_tt]      
[InnoDB] DDL log delete : 376
[InnoDB] DDL log insert : [DDL record: FREE, id=377, thread_id=23, space_id=74, index_id=235, page_no=4]         
[InnoDB] DDL log delete : 377
[InnoDB] DDL log post ddl : begin for thread id : 23                      
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd] 
[InnoDB] DDL log replay : [DDL record: DROP, id=373, thread_id=23, table_id=1130]    

[InnoDB] DDL log post ddl : end for thread id : 23

설명:
1.dtt 이름 바 꾸 기 sql-ib1130-2815969727
2.sql-ib1130-2815969727 표 삭제,post-ddl 단 계 를 표시 해 야 실제 삭제
3.새 테이블 ddtt,같은 insert 작업 은 단독 트 랜 잭 션 으로 제출 되 며,delete 작업 은 전체 트 랜 잭 션 의 일부분 입 니 다.스크롤 백 을 하면 결국 insert 작업 이 남아 있 습 니 다.replay 동작 을 통 해 청소 합 니 다. 
5.DDL 조작 코드 스 택
5.1 create-table

Sql_cmd_create_table::execute
-->mysql_create_table
 -->mysql_create_table_no_lock
  -->create_table_impl
  -->rea_create_base_table
   -->ha_create_table
    -->ha_create
     -->ha_innobase::create
     -->innobase_basic_ddl::create_impl
      -->create_table_info_t::create_table
      {
       ......
      }
 -->trans_commit_implicit
  -->ha_commit_trans
  -->MYSQL_BIN_LOG::prepare
   -->ha_prepare_low //      prepare
    {
    binlog_prepare
    innobase_xa_prepare
    }
  -->MYSQL_BIN_LOG::commit
   -->MYSQL_BIN_LOG::ordered_commit
    -->MYSQL_BIN_LOG::process_flush_stage_queue
     -->MYSQL_BIN_LOG::flush_thread_caches
     -->binlog_cache_mngr::flush
      -->binlog_cache_data::flush
       -->MYSQL_BIN_LOG::write_gtid
        -->Log_event::write
        -->MYSQL_BIN_LOG::Binlog_ofile::write // binlog-gtid
       -->MYSQL_BIN_LOG::write_cache
        --> MYSQL_BIN_LOG::do_write_cache
         -->Binlog_cache_storage::copy_to
         -->stream_copy
          -->Binlog_event_writer::write
           -->MYSQL_BIN_LOG::Binlog_ofile::write // binlog-ddl  
    -->MYSQL_BIN_LOG::sync_binlog_file
    -->MYSQL_BIN_LOG::process_commit_stage_queue
     -->ha_commit_low
     {
      binlog_commit
      innobase_commit
      -->trx_commit_for_mysql
       -->trx_commit
        -->trx_commit_low
         -->trx_commit_in_memory
         -->trx_undo_insert_cleanup
     }
 -->innobase_post_ddl(ht->post_ddl(thd))
  -->Log_DDL::post_ddl
  -->replay_by_thread_id


-->create_table_info_t::create_table
 -->create_table_def
  -->dict_mem_table_create //  innodb         
  -->row_create_table_for_mysql
  -->dict_build_table_def
   -->dict_build_tablespace_for_table
    -->  xxx.idb  
    -->Log_DDL::write_delete_space_log
    {
     -->Log_DDL::insert_delete_space_log
     -->trx_start_internal //      ，    。
     -->  DDL_Record(DELETE_SPACE_LOG)
     -->DDL_Log_Table::insert(    B-Tree)
     -->Log_DDL:delete_by_id //  ddl_log  ，  ddl      。
    }
    -->fil_ibd_create
    -->   segment，extent，page
  -->Log_DDL::write_remove_cache_log
  -->Log_DDL::insert_remove_cache_log
  -->Log_DDL::delete_by_id
 -->create_index(  ，    )
  -->dict_create_index_tree_in_mem
  -->btr_create
  -->Log_DDL::write_free_tree_log
   -->Log_DDL::insert_free_tree_log
   -->Log_DDL:delete_by_id<br>
crash-recovery
 -->ha_post_recover
  -->post_recover_handlerton
    -->innobase_post_recover
     -->Log_DDL::recover
      -->Log_DDL::replay_all
       -->Log_DDL::replay
        {
         replay_delete_space_log
         replay_remove_cache_log
         replay_free_tree_log
         ......
        }
       -->delete_by_ids
        -->DDL_Log_Table::remove

5.2 drop table

mysql_rm_table
 -->mysql_rm_table_no_locks
  -->drop_base_table
   -->ha_delete_table
    -―>handler::ha_delete_table
     -->ha_innobase::delete_table
     -->innobase_basic_ddl::delete_impl
      -->row_drop_table_for_mysql
       -->Log_DDL::write_drop_log  //    innodb_dynamic_metadata  
       -―>Log_DDL::write_delete_space_log  //    ibd  
   -->dd::drop_table
    -->dd::cache::Dictionary_client::drop<dd::Table>
     -->dd::cache::Storage_adapter::drop<dd::Table>
      -->dd::sdi::drop
  -->innobase_post_ddl
   -->Log_DDL::post_ddl
    -->Log_DDL::replay_by_thread_id
     -->Log_DDL::replay
      ―>Log_DDL::replay_delete_space_log // post-ddl     innodb_dynamic_metadata
      ―>Log_DDL::replay_drop_log   // post-ddl     ibd
     -->delete_by_ids
      -->DDL_Log_Table::remove

drop table 에 서 는 동작 로 그 를 삭제 하 는 것 만 기록 합 니 다.이 로 그 는 트 랜 잭 션 의 전체 부분 으로 최종 트 랜 잭 션 이 제출 되면 postddl 단계 에서 로 그 를 읽 고 삭제 합 니 다.트 랜 잭 션 이 다시 굴 러 가면 dl로그 도 업무 의 일부분 으로 굴 러 갑 니 다.
참고 문서
https://dev.mysql.com/worklog/task/?id=9045
https://dev.mysql.com/worklog/task/?id=9173
https://dev.mysql.com/worklog/task/?id=9175
https://dev.mysql.com/worklog/task/?id=9525
https://dev.mysql.com/worklog/task/?id=9536
총결산
위 에서 말 한 것 은 편집장 님 께 서 소개 해 주신 MySQL 8.0 DDL 의 원자 적 특성 과 실현 원리 입 니 다.여러분 께 도움 이 되 셨 으 면 좋 겠 습 니 다.궁금 한 점 이 있 으 시 면 메 시 지 를 남 겨 주세요.편집장 님 께 서 바로 답 해 드 리 겠 습 니 다.여기 서도 저희 사이트 에 대한 여러분 의 지지 에 감 사 드 립 니 다!
만약 당신 이 본문 이 당신 에 게 도움 이 된다 고 생각한다 면,전 재 를 환영 합 니 다.번 거 로 우 시 겠 지만 출처 를 밝 혀 주 십시오.감사합니다!