16.7 Data Dictionary Usage Differences

16.7 Data Dictionary Usage Differences

data dictionary가 활성화된 MySQL server를 사용하면 data dictionary가 없는 server를 사용할 때와 비교하여 다음과 같은 운영상의 차이점이 있습니다:

• 이전에는 innodb_read_only system variable을 활성화하면 InnoDB storage engine에 대해서만 table 생성 및 삭제가 불가능했습니다. MySQL 9.5부터는 innodb_read_only를 활성화하면 모든 storage engine에 대해 이러한 작업이 불가능합니다. 어떤 storage engine이든 table 생성 및 삭제 작업은 mysql system database의 data dictionary table을 수정하지만, 이러한 table은 InnoDB storage engine을 사용하며 innodb_read_only가 활성화된 상태에서는 수정할 수 없습니다. 동일한 원칙이 data dictionary table 수정을 필요로 하는 다른 table 작업에도 적용됩니다. 예:

  • ANALYZE TABLE은 table 통계를 업데이트하는데, 이 통계는 data dictionary에 저장되므로 실패합니다.

  • ALTER TABLE tbl_name ENGINE=engine_name은 storage engine 지정 정보를 업데이트하는데, 이 정보는 data dictionary에 저장되므로 실패합니다.

참고

innodb_read_only를 활성화하는 것은 mysql system database 내의 non-data dictionary table에도 중요한 영향을 미칩니다. 자세한 내용은 Section 17.14, “InnoDB Startup Options and System Variables”에 있는 innodb_read_only 설명을 참조하십시오.

• 이전에는 mysql system database의 table이 DML 및 DDL statement에 의해 볼 수 있었습니다. MySQL 9.5부터는 data dictionary table이 보이지 않으며 직접 수정하거나 query할 수 없습니다. 그러나 대부분의 경우 대신 query할 수 있는 대응되는 INFORMATION_SCHEMA table이 있습니다. 이를 통해 server 개발이 진행되는 동안 내부 data dictionary table은 변경하면서도 application에서 사용할 수 있는 안정적인 INFORMATION_SCHEMA 인터페이스는 유지할 수 있습니다.

• MySQL 9.5의 INFORMATION_SCHEMA table은 data dictionary와 긴밀히 연계되어 있어, 사용상의 차이점이 몇 가지 발생합니다:

  • 이전에는 STATISTICS 및 TABLES table의 table 통계에 대한 INFORMATION_SCHEMA query가 통계를 storage engine에서 직접 가져왔습니다. MySQL 9.5부터는 기본적으로 캐시된 table 통계가 사용됩니다. information_schema_stats_expiry system variable은 캐시된 table 통계가 만료되기까지의 기간을 정의합니다. 기본값은 86400초(24시간)입니다. (특정 table에 대해 캐시된 값을 언제든지 업데이트하려면 ANALYZE TABLE을 사용합니다.) 캐시된 통계가 없거나 통계가 만료된 경우, table 통계 column을 query할 때 통계는 storage engine에서 가져옵니다. 항상 최신 통계를 storage engine에서 직접 가져오려면 information_schema_stats_expiry를 0으로 설정하십시오. 자세한 내용은 Section 10.2.3, “Optimizing INFORMATION_SCHEMA Queries”를 참조하십시오.

  • 여러 INFORMATION_SCHEMA table은 data dictionary table에 대한 view이며, 이를 통해 옵티마이저가 해당 table의 인덱스를 사용할 수 있습니다. 그 결과 옵티마이저의 선택에 따라 INFORMATION_SCHEMA query 결과의 row 순서가 이전 결과와 다를 수 있습니다. query 결과에서 특정 row 정렬 특성이 필요하다면 ORDER BY 절을 포함해야 합니다.

  • INFORMATION_SCHEMA table에 대한 query가 이전 MySQL series와는 다른 대소문자의 column 이름을 반환할 수 있습니다. application은 result set의 column 이름을 대소문자를 구분하지 않고 검사해야 합니다. 이것이 불가능하다면, select list에서 원하는 대소문자를 가진 column 이름을 반환하는 column alias를 사용하는 것이 우회 방법이 될 수 있습니다. 예:

    1SELECT TABLE_SCHEMA AS table_schema, TABLE_NAME AS table_name
    2FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'users';

  • mysqldump는 더 이상 command line에서 명시적으로 지정하더라도 INFORMATION_SCHEMA database를 dump하지 않습니다.

  • [CREATE TABLE dst_tbl LIKE src_tbl](https://dev.mysql.com/doc/refman/9.5/en/create-table-like.html "15.1.24.3 CREATE TABLE ... LIKE Statement)은 _src_tbl_이 base table이어야 하며, data dictionary table에 대한 view인 INFORMATION_SCHEMA table인 경우 실패합니다.

  • 이전에는 INFORMATION_SCHEMA table에서 선택한 column의 result set header가 query에서 지정한 대소문자를 사용했습니다. 이 query는 header가 table_name인 result set을 생성합니다:

    1SELECT table_name FROM INFORMATION_SCHEMA.TABLES;

    MySQL 9.5부터는 이러한 header가 대문자로 표시되며, 위의 query는 header가 TABLE_NAME인 result set을 생성합니다. 필요한 경우 다른 대소문자를 사용하기 위해 column alias를 사용할 수 있습니다. 예:

    1SELECT table_name AS 'table_name' FROM INFORMATION_SCHEMA.TABLES;

• data directory는 mysqldump가 mysql system database에서 정보를 dump하는 방식에 영향을 줍니다:

  • mysqldump는 이전에는 mysql system database의 모든 table을 dump할 수 있었지만, 이제는 해당 database의 non-data dictionary table만 dump합니다.

  • 이전에는 --routines 및 --events option이 --all-databases option을 사용할 때 저장 프로시저 및 이벤트를 포함하기 위해 필요하지 않았습니다. dump에는 mysql system database가 포함되었고, 따라서 저장 프로시저 및 이벤트 정의를 포함하는 proc 및 event table도 포함되었습니다. MySQL 9.5부터는 event 및 proc table이 사용되지 않습니다. 해당 객체의 정의는 data dictionary table에 저장되지만, 이 table은 dump되지 않습니다. --all-databases를 사용하여 만든 dump에 저장 프로시저 및 이벤트를 포함하려면 --routines 및 --events option을 명시적으로 사용해야 합니다.

  • 이전에는 --routines option에 proc table에 대한 SELECT 권한이 필요했습니다. MySQL 9.5부터는 해당 table이 사용되지 않으며, --routines에는 대신 글로벌 SELECT 권한이 필요합니다.

  • 이전에는 proc 및 event table을 dump함으로써 저장 프로시저 및 이벤트 정의를 생성/수정 timestamp와 함께 dump할 수 있었습니다. MySQL 9.5부터는 이러한 table이 사용되지 않으므로 timestamp를 dump할 수 없습니다.

• 이전에는 illegal 문자를 포함하는 저장 프로시저를 생성하면 warning이 발생했습니다. MySQL 9.5부터는 이것이 error가 됩니다.