Skip to content

# Tag: Data Types

## Re: MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation

MySQL Data Types Open Source Percona Toolkit January 24, 2013

Reading Sheeri’s MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation, I was baffled at this change of floating point number notation.

However, I was also concerned about the final action taken: using “–ignore-columns” to avoid comparing the FLOAT/DOUBLE types.

The –float-precision option for pt-table-checksum currently only uses ROUND() so as to disregard minor rounding issues. But it can very easily extend to handle the difference in floating point notation. Consider again the problem:

>     mysql> create table tf(f float);
>     Query OK, 0 rows affected (0.11 sec)

>     mysql> insert into tf values(0.0000958084);
>     Query OK, 1 row affected (0.04 sec)

>     mysql-5.1> select * from tf;
>     +-------------+
>     | f           |
>     +-------------+
>     | 9.58084e-05 |
>     +-------------+

>     mysql-5.5> select * from tf;
>     +--------------+
>     | f            |
>     +--------------+
>     | 0.0000958084 |
>     +--------------+

How can we normalize the notation?

Easily: CAST it as DECIMAL. Consider: Continue reading » “Re: MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation”

## CHAR and spaces

MySQL Data Types June 12, 2012

I know about it, I knew about it all along, but… it’s so easy to fall for it; there’s just so much absurdity!

A CHAR type has a known number of characters. For example, the column:

>     CountryCode CHAR(3) CHARSET ascii NOT NULL

– is known to have exactly three characters. These could be ‘USA’, ‘FRA’, etc.

What happens with spaces? A SQL CHAR type ignores any trailing spaces; thus, the code ‘GB ‘ (the characters ‘G’, ‘B’, and the space ‘ ‘) is interpreted as ‘GB’. Trailing spaces are not regarded as part of the text. Want to see some absurdity?

>     CREATE TABLE `c_test` (
>       `c` char(1) DEFAULT NULL
>     );
>     INSERT INTO c_test VALUES ('a');
>     INSERT INTO c_test VALUES ('b');
>     INSERT INTO c_test VALUES (' ');

>     SELECT c, LENGTH(c), c = 'a', c = 'b', c = ' ', LENGTH(' ') FROM c_test;
>     +------+-----------+---------+---------+---------+-------------+
>     | c    | LENGTH(c) | c = 'a' | c = 'b' | c = ' ' | LENGTH(' ') |
>     +------+-----------+---------+---------+---------+-------------+
>     | a    |         1 |       1 |       0 |       0 |           1 |
>     | b    |         1 |       0 |       1 |       0 |           1 |
>     |      |         0 |       0 |       0 |       1 |           1 |
>     +------+-----------+---------+---------+---------+-------------+

Continue reading » “CHAR and spaces”

## 23:59:59 is not the end of the day. No, really!

MySQL Data Types July 27, 2011July 31, 2011

How would you check whether some TIMESTAMP column falls within a given day, say July 26th, 2011?

This is a question I tend to ask students, and usually I get the same range of answers. Some are wrong; some cannot utilize an index, some are correct, and some are temporarily correct. I wish to take a closer look at the last. Such an answer looks like this:

>     SELECT * FROM some_table WHERE timstamp_column BETWEEN '2011-07-26 00:00:00' AND '2011-07-26 23:59:59'

Yikes! I get my allergies when I see this one.

Technically this seems correct. And it seems to work so far for people. There are two things that disturb me:

1. ’23:59:59′ refers to the beginning of the last second of the day. This means a full second is missing in concept. No one would write such a code on a C, Java or PHP application: that would be a newbie’s mistake. But people feel at ease doing it with SQL

Of course, this works when timestamps are in a one second resolution. Which leads me to:

2. One second resolution is a temporary issue. Already MariaDB 5.3 presents with microsecond support for NOW() and TIMESTAMP, TIME and DATETIME columns. Sometime in the not-so-far future the standard MySQL distribution will have that, too.

Continue reading » “23:59:59 is not the end of the day. No, really!”

## Announcing common_schema: common views & routines for MySQL

MySQL Analysis common_schema Data Types Development Indexing INFORMATION_SCHEMA InnoDB Monitoring Open Source Schema Security SQL Stored routines July 13, 2011

Today I have released common_schema, a utility schema for MySQL which includes many views and functions, and is aimed to be installed on any MySQL server.

#### What does it do?

There are views answering for all sorts of useful information: stuff related to schema analysis, data dimensions, monitoring, processes & transactions, security, internals… There are basic functions answering for common needs.

Some of the views/routines simply formalize those queries we tend to write over and over again. Others take the place of external tools, answering complex questions via SQL and metadata. Still others help out with SQL generation.

Here are a few highlights:

- Did you know you can work out simple monitoring of your server with a query? There’s a view to do that for you.
- How about showing just the good parts of the processlist?
- Does your schema have redundant keys?
- Or InnoDB tables with no PRIMARY KEY?
- Is AUTO_INCREMENT running out of space?
- Can I get the SQL statements to generate my FOREIGN KEYs? To drop them?
- And can we finally get SHOW GRANTS for all accounts, and as an SQL query?
- Ever needed a 64 bit CRC function?
- And aren’t you tired of writing the cumbersome SUBSTRING_INDEX(SUBSTRING_INDEX(str, ‘,’, 3), ‘,’, -1)? There’s an alternative.

There’s more. Take a look at the common_schema documentation for full listing. And it’s evolving: I’ve got quite a few ideas already for future components.

Some of these views rely on heavyweight INFORMATION_SCHEMA tables. You should be aware of the impact and risks.

#### What do I need to install?

There’s no script or executable file. It’s just a schema. The distribution in an SQL file which generates common_schema. Much like a dump file.

#### Continue reading » “Announcing common_schema: common views & routines for MySQL”

## TIMESTAMP vs. DATETIME, which should I be using?

MySQL Data Types May 22, 2011May 26, 2011

They both look the same, have roughly the same use. Nevertheless, they differ in many respects. I’ll note the difference, and note a few pitfalls and peculiarities.

#### Range

TIMESTAMP starts with the epoch, ‘1970-01-01 00:00:01’ UTC and ends with ‘2038-01-19 03:14:07’ UTC. This is all very nice today, and may actually hold up till our retirement, but the younger readers may yet have to deal with the Bug2K+38™, certain to arrive.

DATETIME starts with ‘1000-01-01 00:00:00’ and lasts up to ‘9999-12-31 23:59:59’. More on that later.

In respect of range, your current event logs may well use a TIMESTAMP value, while your grandfather’s and granddaughter’s birth dates may require DATETIME.

In general I would suggest that anything that relates to now, can be a TIMESTAMP. A new entry is added? It is added now. It can be represented by a TIMESTAMP. Anything has an expiry time of a few minutes, perhaps a few days or a month? You’ll be safe using it up till late 2037. Anything else had better use a DATETIME. In particular, dates relating to issues such as birth, insurance, the market etc. fall into this category.

History, however, does not even hold up with DATETIME. Rome fell long before MIN(DATETIME). You will have to manage your own. Not even YEAR will help you out.

#### Storage

TIMESTAMP makes for 4 bytes. DATETIME makes for 8 bytes. Now that we have this behind us, let’s see why. Continue reading » “TIMESTAMP vs. DATETIME, which should I be using?”

## Implicit casting you don’t want to see around

MySQL Data Types SQL July 7, 2010July 7, 2010

In Beware of implicit casting, I have outlined the dangers of implicit casting. Here’s a few more real-world examples I have tackled:

#### Number-String comparisons

Much like in programming languages, implicit casting is made to numbers when at least one of the arguments is a number. Thus:

>     mysql> SELECT 3 = '3.0';
>     +-----------+
>     | 3 = '3.0' |
>     +-----------+
>     |         1 |
>     +-----------+
>     1 row in set (0.00 sec)

>     mysql> SELECT '3' = '3.0';
>     +-------------+
>     | '3' = '3.0' |
>     +-------------+
>     |           0 |
>     +-------------+

The second query consists of pure strings comparison. It has no way to determine that number comparison should be made.

#### Direct DATE arithmetics

The first query seems to work, but is completely incorrect. The second explains why. The third is a total mess. Continue reading » “Implicit casting you don’t want to see around”

## Choosing MySQL boolean data types

MySQL Data Types SQL June 3, 2010

How do you implement True/False columns?

There are many ways to do it, each with its own pros and cons.

#### ENUM

Create you column as ENUM(‘F’, ‘T’), or ENUM(‘N’,’Y’) or ENUM(‘0’, ‘1’).

This is the method used in the mysql tables (e.g. mysql.user privileges table). It’s very simple and intuitive. It truly restricts the values to just two options, which serves well. It’s compact (just one byte).

A couple disadvantages to this method:

1. Enums are represented by numerical values (which is good) and start with 1 instead of 0. This means ‘F’ is 1, and ‘T’ is 2, and they both translate to True when directly used in a booleanic expression (e.g. IF(val, ‘True’, ‘False’) always yields ‘True’)
2. There’s no real convention. Is it ‘Y’/’N’? ‘T’/’F’? ‘P’/’N’? ‘1’/’0′?

#### CHAR(1)

Simple again. Proposed values are, as before, ‘F’, ‘T’ etc. This time there’s no way to limit the range of values. You cannot (in MySQL, unless using triggers) prevent an ‘X’.

Watch out for the charset! If it’s utf8 you pay with 3 bytes instead of just 1. And, again, ‘T’, ‘F’, ‘Y’, ‘N’ values all evaluate as True. It is possible to use the zero-valued character, but it defeats the purpose of using CHAR. Continue reading » “Choosing MySQL boolean data types”

## But I DO want MySQL to say “ERROR”!

MySQL Configuration Data Types sql_mode Syntax March 12, 2010March 12, 2010

MySQL is known for its willingness to accept invalid queries, data values. It can silently commit your transaction, truncate your data.

- Using GROUP_CONCAT with a small group_concat_max_len setting? Your result will be silently truncated (make sure to check the warnings though).
- Calling CREATE TEMPORARY TABLE? You get silent commit.
- Issuing a ROLLBACK on non-transactional involved engines? Have a warning; no error.
- Using LOCK IN SHARE MODE on non transactional tables? Not a problem. Nothing reported.
- Adding a FOREIGN KEY on a MyISAM table? Good for you; no action actually taken.
- Inserting 300 to a TINYINT column in a relaxed sql_mode? Give me 255, I’ll silently drop the remaining 45. I owe you.

#### Warnings and errors

It would be nice to: Continue reading » “But I DO want MySQL to say “ERROR”!”

## Useful temporal functions & queries

MySQL Data Types Indexing SQL December 8, 2009

Here’s a complication of some common and useful time & date calculations and equations. Some, though very simple, are often misunderstood, leading to inefficient or incorrect implementations.

There are many ways to solve such problems. I’ll present my favorites.

#### Querying for time difference

Given two timestamps: ts1 (older) and ts2 (newer), how much time has passed between them?

One can use TIMEDIFF() & DATEDIFF(), or compare two UNIX_TIMESTAMP() values. My personal favorite is to use TIMESTAMPDIFF(). Reason being that I’m usually interested in a specific metric, like the number of hours which have passed, or the number of days, disregarding the smaller minute/second resolution. Which allows one to:

>     SELECT TIMESTAMPDIFF(HOUR, ts1, ts2)

Take, for example:

>     SELECT TIMESTAMPDIFF(MONTH, '2008-10-07 00:00:00', '2009-12-06 00:00:00')

The function correctly identifies the number of days per month, and provides with 13, being the truncated number of full months.

#### Doing arithmetics

One can use TIMESTAMPADD(), or DATE_SUB(), but, again, when dealing with specific resolutions, I find “+ INTERVAL” to be the most convenient:

>     SELECT ts1 + INTERVAL 10 HOUR

Continue reading » “Useful temporal functions & queries”

## Character sets: latin1 vs. ascii

MySQL Configuration Data Types July 8, 2009July 8, 2009

Unless specified otherwise, latin1 is the default character set in MySQL.

What I usually find in schemes are columns which are either utf8 or latin1. The utf8 columns being those which need to contain multilingual characters (user names, addresses, articles etc.), and latin1 column being all the rest (passwords, digests, email addresses, hard-coded values etc.)

I find latin1 to be improper for such purposes and suggest that ascii be used instead. The reason being that latin1 implies a European text (with swedish collation). It is unclear for an outsider, when finding a latin1 column, whether it should actually contain West European characters, or is it just being used for ascii text, utilizing the fact that a character in latin1 only requires 1 byte of storage. Continue reading » “Character sets: latin1 vs. ascii”