Upgrading temporal columns from MySQL 5.5 to MySQL 5.6 forma_MySQL
Before upgrading from MySQL 5.5 to 5.6, I read therelevant pagein thereference manualand found this section about the storage format change forDATETIME
,TIME
,TIMESTAMP
data types to support microseconds:
Incompatible change: For TIME, DATETIME, and TIMESTAMP columns, the storage required for tables created before MySQL 5.6.4 differs from storage required for tables created in 5.6.4 and later. This is due to a change in 5.6.4 that permits these temporal types to have a fractional part. After upgrading from MySQL 5.5 to MySQL 5.6.4 or later, it is recommended that you also upgrade from MySQL 5.5 to MySQL 5.6 TIME, DATETIME, and TIMESTAMP types…
The problem is that the manual doesn’t tell youhowto “upgrade from MySQL 5.5 to MySQL 5.6 TIME, DATETIME, and TIMESTAMP types”. I figured simply rebuilding the relevant tables would probably do the trick, and I found some confirmation in ablog postfrom the MySQL server team. Quoting that post:
The ALTER TABLE requests ADD/CHANGE/MODIFY COLUMN, ADD INDEX or FORCE operation upon detecting old temporal data types upgrades them to the new format. Also a ‘NOTE’ is reported to indicate the user that an upgrade of the old temporal columns to the new format has been performed as well.
So I figured I would useALTER TABLE ... FORCE
to rebuild my tables. But which tables need to be rebuilt? I could simply rebuild every table that hasDATETIME
,TIME
, and/orTIMESTAMP
columns, but I’d rather be able to tell which storage format the table is using so don’t end up rebuilding it if I don’t need to. For InnoDB tables I can identify the columns using the old temporal types by checking theMTYPE
value in theINFORMATION_SCHEMA.INNODB_SYS_COLUMNS
table, since that value will be6 (INT)
for the old storage format and3 (FIXBINARY)
for the new storage format. Since almost all of my tables are InnoDB that approach works well for me. For other storage engines I’ll just rebuild all tables withDATETIME
,TIME
, and/orTIMESTAMP
columns.
Here’s a query to list all of the relevant columns suspected of using the old format:
<code>select t.table_schema,t.engine,t.table_name,c.column_name,c.column_typefrom information_schema.tables t inner join information_schema.columns c on c.table_schema = t.table_schema and c.table_name = t.table_nameleft outer join information_schema.innodb_sys_tables ist on ist.name = concat(t.table_schema,'/',t.table_name)left outer join information_schema.innodb_sys_columns isc on isc.table_id = ist.table_id and isc.name = c.column_name where c.column_type in ('time','timestamp','datetime')and t.table_schema not in ('mysql','information_schema','performance_schema')and t.table_type = 'base table'and (t.engine != 'innodb' or (t.engine = 'innodb' and isc.mtype = 6))order by t.table_schema,t.table_name,c.column_name;</code> 로그인 후 복사 |
And here’s a quick way to dump theALTER TABLE
commands to a script and then execute that script:
<code>select distinct concat('set sql_log_bin = 0; alter table ',t.table_schema,'.',t.table_name,' force;') as ddlinto outfile '/tmp/rebuild_tables_to_upgrade_tempral_storage_format.sql'from information_schema.tables t inner join information_schema.columns c on c.table_schema = t.table_schema and c.table_name = t.table_nameleft outer join information_schema.innodb_sys_tables ist on ist.name = concat(t.table_schema,'/',t.table_name)left outer join information_schema.innodb_sys_columns isc on isc.table_id = ist.table_id and isc.name = c.column_name where c.column_type in ('time','timestamp','datetime')and t.table_schema not in ('mysql','information_schema','performance_schema')and t.table_type = 'base table'and (t.engine != 'innodb' or (t.engine = 'innodb' and isc.mtype = 6))order by (t.data_length + t.index_length) asc;/W /. /tmp/rebuild_tables_to_upgrade_tempral_storage_format.sql</code> 로그인 후 복사 |
If I re-run the above it will not rebuild the InnoDB tables that were already rebuilt, but it will rebuild the MyISAM tables that were already rebuilt because I don’t know how to tell if they are using the old format or not.
Since I enabled warnings I get this friendly note every time I convert a table:
Note (Code 1880): TIME/TIMESTAMP/DATETIME columns of old format have been upgraded to the new format.
As an added bonus all of myDATETIME
columns shrink from 8 bytes to 5 bytes (assuming I’m not using fractional seconds)!

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL에서 파티셔닝, 샤딩, 인덱싱 및 쿼리 최적화를 포함하여 대규모 데이터 세트를 처리하기위한 전략에 대해 설명합니다.

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].

이 기사에서는 Drop Table 문을 사용하여 MySQL에서 테이블을 떨어 뜨리는 것에 대해 설명하여 예방 조치와 위험을 강조합니다. 백업 없이는 행동이 돌이킬 수 없으며 복구 방법 및 잠재적 생산 환경 위험을 상세하게합니다.

기사는 외국 열쇠를 사용하여 데이터베이스의 관계를 나타내고 모범 사례, 데이터 무결성 및 피할 수있는 일반적인 함정에 중점을 둡니다.

이 기사에서는 PostgreSQL, MySQL 및 MongoDB와 같은 다양한 데이터베이스에서 JSON 열에서 인덱스를 작성하여 쿼리 성능을 향상시킵니다. 특정 JSON 경로를 인덱싱하는 구문 및 이점을 설명하고 지원되는 데이터베이스 시스템을 나열합니다.

기사는 준비된 명령문, 입력 검증 및 강력한 암호 정책을 사용하여 SQL 주입 및 무차별 적 공격에 대한 MySQL 보안에 대해 논의합니다 (159 자)
