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)!

MySQL'sBLOBissuitableforstoringbinarydatawithinarelationaldatabase,whileNoSQLoptionslikeMongoDB,Redis,andCassandraofferflexible,scalablesolutionsforunstructureddata.BLOBissimplerbutcanslowdownperformancewithlargedata;NoSQLprovidesbetterscalabilityand

ToaddauserinMySQL,use:CREATEUSER'username'@'host'IDENTIFIEDBY'password';Here'showtodoitsecurely:1)Choosethehostcarefullytocontrolaccess.2)SetresourcelimitswithoptionslikeMAX_QUERIES_PER_HOUR.3)Usestrong,uniquepasswords.4)EnforceSSL/TLSconnectionswith

ToavoidcommonmistakeswithstringdatatypesinMySQL,understandstringtypenuances,choosetherighttype,andmanageencodingandcollationsettingseffectively.1)UseCHARforfixed-lengthstrings,VARCHARforvariable-length,andTEXT/BLOBforlargerdata.2)Setcorrectcharacters

MySQloffersechar, Varchar, text, Anddenumforstringdata.usecharforfixed-Lengthstrings, VarcharerForvariable-Length, text forlarger text, AndenumforenforcingdataAntegritywithaetofvalues.

Optimizing MySQLBLOB requests can be done through the following strategies: 1. Reduce the frequency of BLOB query, use independent requests or delay loading; 2. Select the appropriate BLOB type (such as TINYBLOB); 3. Separate the BLOB data into separate tables; 4. Compress the BLOB data at the application layer; 5. Index the BLOB metadata. These methods can effectively improve performance by combining monitoring, caching and data sharding in actual applications.

Mastering the method of adding MySQL users is crucial for database administrators and developers because it ensures the security and access control of the database. 1) Create a new user using the CREATEUSER command, 2) Assign permissions through the GRANT command, 3) Use FLUSHPRIVILEGES to ensure permissions take effect, 4) Regularly audit and clean user accounts to maintain performance and security.

ChooseCHARforfixed-lengthdata,VARCHARforvariable-lengthdata,andTEXTforlargetextfields.1)CHARisefficientforconsistent-lengthdatalikecodes.2)VARCHARsuitsvariable-lengthdatalikenames,balancingflexibilityandperformance.3)TEXTisidealforlargetextslikeartic

Best practices for handling string data types and indexes in MySQL include: 1) Selecting the appropriate string type, such as CHAR for fixed length, VARCHAR for variable length, and TEXT for large text; 2) Be cautious in indexing, avoid over-indexing, and create indexes for common queries; 3) Use prefix indexes and full-text indexes to optimize long string searches; 4) Regularly monitor and optimize indexes to keep indexes small and efficient. Through these methods, we can balance read and write performance and improve database efficiency.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Dreamweaver CS6
Visual web development tools

WebStorm Mac version
Useful JavaScript development tools

PhpStorm Mac version
The latest (2018.2.1) professional PHP integrated development tool

mPDF
mPDF is a PHP library that can generate PDF files from UTF-8 encoded HTML. The original author, Ian Back, wrote mPDF to output PDF files "on the fly" from his website and handle different languages. It is slower than original scripts like HTML2FPDF and produces larger files when using Unicode fonts, but supports CSS styles etc. and has a lot of enhancements. Supports almost all languages, including RTL (Arabic and Hebrew) and CJK (Chinese, Japanese and Korean). Supports nested block-level elements (such as P, DIV),
