MySQL: Changes Introduced In MySQL 5.5
With the migration to MySQL 5.5 there are some new features that have been introduced, where some aren’t compatible with the previous MySQL 5.1 server that was running on our servers.
Default storage engine
With MySQL 5.5 InnoDB has become default the storage engine instead of MyISAM storage engine. This is NOT the case for our servers, all of our shared,reseller and managed VPS servers still utilize MyISAM as the default storage engine.
Improved performance
Improved performance is due to the optimizations in MySQL to better utilize multi core CPUs alongside with improving InnoDB locking and memory management. Since all of our servers have multiple cores available to services running on them, it is important that they can fully utilize them and provide maximum efficiency.
SQL changes
- INTO clauses are no longer accepted in nested SELECT statements. Modify the SQL statements to not contain the clause.
- MySQL usernames are now changed to allow for more then 7 characters.
- Alias declarations outside table_reference are not allowed for multiple-table DELETE statements. Modify those statements to use aliases only inside the table_reference part.
- Alias resolution does not require qualification and alias reference should not be qualified with the database name.
- New reserved words:
- GENERAL
- IGNORE_SERVER_IDS
- MASTER_HEARTBEAT_PERIOD
- MAXVALUE
- RESIGNAL
- SIGNAL
- SLOW
Numeric calculations
On the numeric side, the server includes a new a library for conversions between strings and numbers, dtoa.
This library provides the basis for an improved conversion between string or DECIMAL values and approximate-value (FLOAT or DOUBLE) numbers. Also, all numeric operators and functions on integer, floating-point and DECIMAL values throw an out of range error (ER_DATA_OUT_OF_RANGE) rather than returning an incorrect value or NULL.
If an application relies on previous numeric results, it may have to be adjusted to the new precision or behavior.
Unicode support
The Unicode implementation has been extended to provide support for supplementary characters that lie outside the Basic Multilingual Plane (BMP), introducing the utf16, utf32 and utf8mb4 charsets.
If you are considering upgrading from utf8 to utf8mb4 to take advantage of the supplementary characters, you may have to adjust the size of the fields and indexes in the future. See http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-upgrading.html.
Upgrading to utf8mb4 will not take place unless you explicitly change the charset, i.e. with a ALTER TABLE… statement
Indexes
The stopword file is loaded and searched using latin1 if the character_set_server is ucs2, utf16, or utf32. If any table was created with FULLTEXT indexes while the server character set was ucs2, utf16, or utf32, it should be repaired using this statement REPAIR TABLE tbl_name QUICK;
Deprecated features
MySQL 5.5 introduces a number of deprecated features that would be removed in future MySQL releases. Certain features are provided with alternatives that can be used, other features would be fully removed.
- Relying on implicit GROUP BY sorting in MySQL 5.5 is deprecated. To achieve a specific sort order of grouped results, it is preferable to use an explicit ORDER BY clause. GROUP BY sorting is a MySQL extension that may change in a future release; for example, to make it possible for the optimizer to order groupings in whatever manner it deems most efficient and to avoid the sorting overhead.
- The YEAR(2) data type. YEAR(2) columns in existing tables are treated as before, but YEAR(2) in new or altered tables are converted to YEAR(4). For more information about YEAR(4) please visit http://dev.mysql.com/doc/refman/5.5/en/migrating-to-year4.html
For a in depth review of the changes introduced in MySQL 5.5 please visit: http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html
Gerri Lushey November 27, 2014 at 5:12 pm
I am changing my website from WordPress to another and need to know how to do this. Can you please give me the email of someone I can liaise with on this. Thanks, Gerri
James Davey November 28, 2014 at 6:53 am
Hi Gerri,
Anyone on our support team should be able to answer any questions you may have, if you open a support ticket. Please note that we are not website designers, so we can’t help you with your code, but we can certainly advise you on how to make the change.
Stu November 29, 2014 at 3:08 am
What time will the change be occurring?
James Davey December 1, 2014 at 6:40 am
Hello Stu,
That depends on the server location. Because we have servers located around the world, we time things like this so they happen during low-traffic times for that server. As the scheduled date of an upgrade approaches, customers on that server will receive an email with more specific details, including the time the maintenance starts, and how long it is expected to last.
Vlad December 5, 2014 at 2:13 pm
On my message said TUE, Dec 9th, but it did not mentioned any specific hours. My server is in USA midwest. Any more info for that location?
James Davey December 8, 2014 at 6:42 am
Hi Vlad,
The maintenance window will be between 2am and 6am, local to the server’s location.
Perke December 4, 2014 at 6:19 am
Will there be any impact on sites running Drupal 7.34?
James Davey December 4, 2014 at 7:35 am
Hello Perke,
There should be no impact, no.
Perke December 4, 2014 at 7:38 am
Thanks!
Marj Wyatt December 4, 2014 at 12:48 pm
Are you upgrading PHP to v5.5 or just MySQL?
A month ago when I asked about this, I was told I needed to add this handler to my .htaccess file:
AddHandler application/x-httpd-php54 .php
Will the server upgrade make it possible to remove this and will all the cPanels on my Reseller account be upgraded at once with this change?
James Davey December 4, 2014 at 12:53 pm
Hi Marj,
This upgrade is to MySQL only – PHP versions will not be adjusted with this. All accounts on the server will be updated at the same time as it is a server-wide upgrade.
Marj Wyatt December 4, 2014 at 1:00 pm
So, Site5 will continue to force a well beyond end-of-life and less secure version of PHP as the default and upgrading only MySQL? I find that to be an extremely odd business decision but at least you’re moving forward a little.
James Davey December 4, 2014 at 2:03 pm
Hi Marj,
Not at all. PHP 5.3, the default version, is no longer receiving development updates, but 5.4 is available on all servers as well. 5.4 is receiving updates for security fixes from the PHP development team, meaning it is still an active, stable, secure version.
We are looking at 5.5 for the future, but it is not a simple matter to upgrade such a critical tool on the server fleet. Extensive testing needs to be done to ensure existing accounts are not affected negatively by the change, and that the new version interacts well with our server environment.
Marj Wyatt December 4, 2014 at 2:45 pm
The operative here is “available.” I must add an .htaccess handler to use it.
Even GoDaddy’s default for PHP is defaulted to 5.4.34 on their cPanel hosting and has been for over a year.
Just so you understand, I wouldn’t want to return to hosting at GoDaddy but it surprises me that they are “more ahead of the game” than Site5.
I understand it isn’t easy to upgrade PHP versions on a server with so many accounts on each one. I also understand that using an AddHandler statement in .htaccess is not optimal.
James Davey December 5, 2014 at 6:43 am
Hi Marj,
The reason 5.3 is the default is fairly simple, but you have to go back a few years to see it. Back when we were running PHP4 on the server fleet, 5.2 was the default version, and 5.3 was available as well. At the time, 5.4 was still barely out of beta versioning, and we decided to drop PHP4 altogether. We needed to decide which version to make the default, and 5.3 was the best option at the time, though 5.4 was made available as an option.
As a result of this, most sites on our servers are optimally used when 5.3 is the default. The changes from 5.3 to 5.4 are minimal, but would have enough impact on enough people that making a change like that is simply asking for disaster. Installing a new version of PHP on the server is difficult, yes – there are so many factors to take into consideration that it takes months and dozens of people to figure it all out – but changing the default version is just as difficult. If not more. Everyone running the AddHandler exception for 5.4 will need to have that removed. Everyone NOT using it will need a .htaccess file created with that line added – across thousands and thousands of accounts. And that is just the most obvious step.
I realise that 5.4 as a default version may seem like an easy change to make, and it may be a better option (I am not convinced of that, though, as most people use 5.3 for most things), but for our server fleet and our customers, 5.3 works just fine, and it’s an easy switch to use 5.4 on a per-account basis.
Lavinia M December 4, 2014 at 3:19 pm
Is it possible to use a previous version on some sites that are built on mysql < 5.5 ?
Michael Thomas December 4, 2014 at 6:03 pm
There are ways to do this, however, we haven’t implemented any of them at this time. One method you could use, however, would be to manage your own mySQL installation and versioning on one of our Unmanaged VPS servers, where you have full control over the environment and what is installed.
Jim E December 5, 2014 at 10:06 am
Not so sure timing is good on this upgrade. I’m so glad I don’t rely on any of the sites on this server during the holiday season. This really seems like an upgrade that could have waited until just after Christmas or New Years.
James Davey December 5, 2014 at 1:37 pm
Hello Jim,
We took that into consideration, yes. But the impact now versus after the holidays is essentially the same. We are aware of the concerns, and believe this is the best time to complete this.
Tom T December 8, 2014 at 10:51 am
My notification gave me Thursday Dec 11th. My server is in Dallas. Any idea on the time frame? I will need to notify my clients ahead of time.
James Davey December 8, 2014 at 11:18 am
Hi Tom,
All of these should be done between 2am and 6am, local time to the server. If there is any deviation from that, you would be alerted.
Dickie December 9, 2014 at 5:19 pm
Unfortunately I found out that this change broke one of my sites, as my SQL user was “automatically” truncated to 16 characters (from 20) which meant that my WordPress installation could no longer connect to the database.
I only found out when trying to add the user back in through CPanel to be told that the limit was 16.
I initially thought I had been hacked, as the username in the wp-config file did not match the user in the Database settings.
Bit of a shock
James Davey December 10, 2014 at 6:39 am
I’m very sorry for that, though I am happy to hear you found a solution to this.
Mike Wilkinson December 17, 2014 at 4:35 pm
I’m a confused by a statement that is under the subheading “SQL Changes”.
“MySQL usernames are now changed and limited to 7 characters. You will need to update your database connection string if the old username was greater then 7 characters.”
A database connection string for one of my clients looks like this:
$connection = mysql_connect(‘localhost’, ‘user_user’, ‘XXXXXXXXXXX’)
The username above is ‘user_user’. My client’s cPanel, FTP, etc. username is ‘user”.
Will I need to shorten the username for the MySQL connnection?
James Davey December 18, 2014 at 6:34 am
Hello Mike,
The two examples you give above – which have been edited out for your security – will not need to be changed. Both are seven characters long, so would not be trimmed. The character limit is applied after the underscore in the SQL username. If you previously had an SQL username of cpaneluser_somethingreallylonglikethis it would be trimmed to the following:
cpaneluser_somethi
Mike Wilkinson December 18, 2014 at 10:10 am
“The character limit is applied after the underscore in the SQL username.”
This is very helpful information. Thanks!
David McGarva January 1, 2015 at 11:01 am
Thanks for the upgrade this morning. I notice my database is 10% smaller now. Is that a normal effect?
James Davey January 1, 2015 at 1:10 pm
Hi David,
It should not affect the actual size, no – while you may want to confirm that no data is missing, any loss is unlikely. The update should not have touched your data at all, as it was simply an upgrade to the MySQL installation, not the databases themselves. It is most likely a case of the new version reading things a little differently, and reporting a slightly different size.
David McGarva January 1, 2015 at 2:51 pm
I don’t see any problems with the data, so I’ll just be happy with saving some space. Thanks James!
Di May 18, 2015 at 11:58 pm
Does this mean we need to back up all our websites?
James Davey May 19, 2015 at 5:10 am
We generate daily backups from our end, usually around midnight. However, it is always a good idea for you to back up your data, as well.