Additional languages
« 12.8.5 Fine-Tuning MySQL Full-Text Search
12.10 Other Functions »
Section Navigation      [Toggle]

12.9. Cast Functions and Operators

Name Description
BINARY Cast a string to a binary string
CAST() Cast a value as a certain type

  • BINARY

    The BINARY operator casts the string following it to a binary string. This is an easy way to force a column comparison to be done byte by byte rather than character by character. This causes the comparison to be case sensitive even if the column isn't defined as BINARY or BLOB. BINARY also causes trailing spaces to be significant. 

    mysql> SELECT 'a' = 'A';
        -> 1
mysql> SELECT BINARY 'a' = 'A';
        -> 0
mysql> SELECT 'a' = 'a ';
        -> 1
mysql> SELECT BINARY 'a' = 'a ';
        -> 0

    In a comparison, BINARY affects the entire operation; it can be given before either operand with the same result.

    BINARY was added in MySQL 3.23.0. As of MySQL 4.0.2, BINARY str is a shorthand for CAST(str AS BINARY).

    Note that in some contexts, if you cast an indexed column to BINARY, MySQL is not able to use the index efficiently.

  • CAST(expr AS type), CONVERT(expr,type), CONVERT(expr USING transcoding_name)

    The CAST() and CONVERT() functions take a value of one type and produce a value of another type.

    The type can be one of the following values:

    • BINARY (and BINARY[N] as of MySQL 4.1.1)

    • CHAR (and CHAR[N] as of MySQL 4.1.1)

    • DATE

    • DATETIME

    • SIGNED [INTEGER]

    • TIME

    • UNSIGNED [INTEGER]

    BINARY produces a string with the BINARY data type. See Section 11.4.2, “The BINARY and VARBINARY Types” for a description of how this affects comparisons. If the optional length N is given, BINARY(N) causes the cast to use no more than N bytes of the argument. Similarly, CHAR[N] causes the cast to use no more than N characters of the argument.

    CAST() and CONVERT() are available as of MySQL 4.0.2. The CHAR conversion type is available as of 4.0.6. The USING form of CONVERT() is available as of 4.1.0.

    CAST() and CONVERT(... USING ...) are standard SQL syntax. The non-USING form of CONVERT() is ODBC syntax.

    CONVERT() with USING is used to convert data between different character sets. In MySQL, transcoding names are the same as the corresponding character set names. For example, this statement converts the string 'abc' in the default character set to the corresponding string in the utf8 character set: 

    SELECT CONVERT('abc' USING utf8);

If you want to compare a BLOB value or other binary string in case-insensitive fashion, you can do so as follows:

  • Before MySQL 4.1.1, use the UPPER() function to convert the binary string to uppercase before performing the comparison: 

    SELECT 'A' LIKE UPPER(blob_col) FROM tbl_name;

    If the comparison value is lowercase, convert the string value using LOWER() instead.

  • For MySQL 4.1.1 and up, binary strings have no character set, and thus no concept of lettercase. To perform a case-insensitive comparison, use the CONVERT() function to convert the value to a non-binary string. If the character set of the result has a case-insensitive collation, the LIKE operation is not case sensitive: 

    SELECT 'A' LIKE CONVERT(blob_col USING latin1) FROM tbl_name;

    To use a different character set, substitute its name for latin1 in the preceding statement. To ensure that a case-insensitive collation is used, specify a COLLATE clause following the CONVERT() call.

CONVERT() can be used more generally for comparing strings that are represented in different character sets.

The cast functions are useful when you want to create a column with a specific type in a CREATE ... SELECT statement: 

CREATE TABLE new_table SELECT CAST('2000-01-01' AS DATE);

The functions also can be useful for sorting ENUM columns in lexical order. Normally, sorting of ENUM columns occurs using the internal numeric values. Casting the values to CHAR results in a lexical sort: 

SELECT enum_col FROM tbl_name ORDER BY CAST(enum_col AS CHAR);

CAST(str AS BINARY) is the same thing as BINARY str. CAST(expr AS CHAR) treats the expression as a string with the default character set.

Note: In MySQL 4.0, a CAST() to DATE, DATETIME, or TIME only marks the column to be a specific type but does not change the value of the column.

As of MySQL 4.1.0, the value is converted to the correct column type when it is sent to the user (this is a feature of how the new protocol in 4.1 sends date information to the client): 

mysql> SELECT CAST(NOW() AS DATE);
       -> 2003-05-26

As of MySQL 4.1.1, CAST() also changes the result if you use it as part of a more complex expression such as CONCAT('Date: ',CAST(NOW() AS DATE)).

You should not use CAST() to extract data in different formats but instead use string functions like LEFT() or EXTRACT(). See Section 12.6, “Date and Time Functions”.

To cast a string to a numeric value in numeric context, you normally do not have to do anything other than to use the string value as though it were a number: 

mysql> SELECT 1+'1';
       -> 2

If you use a number in string context, the number automatically is converted to a BINARY string. 

mysql> SELECT CONCAT('hello you ',2);
        -> 'hello you 2'

MySQL supports arithmetic with both signed and unsigned 64-bit values. If you are using numeric operators (such as + or -) and one of the operands is an unsigned integer, the result is unsigned. You can override this by using the SIGNED and UNSIGNED cast operators to cast the operation to a signed or unsigned 64-bit integer, respectively. 

mysql> SELECT CAST(1-2 AS UNSIGNED)
        -> 18446744073709551615
mysql> SELECT CAST(CAST(1-2 AS UNSIGNED) AS SIGNED);
        -> -1

Note that if either operand is a floating-point value, the result is a floating-point value and is not affected by the preceding rule. (In this context, DECIMAL column values are regarded as floating-point values.) 

mysql> SELECT CAST(1 AS UNSIGNED) - 2.0;
        -> -1.0

If you are using a string in an arithmetic operation, this is converted to a floating-point number.

The handing of unsigned values was changed in MySQL 4.0 to be able to support BIGINT values properly. If you have some code that you want to run in both MySQL 4.0 and 3.23, you probably cannot use the CAST() function. You can use the following technique to get a signed result when subtracting two unsigned integer columns ucol1 and ucol2: 

mysql> SELECT (ucol1+0.0)-(ucol2+0.0) FROM ...;

The idea is that the columns are converted to floating-point values before the subtraction occurs.

If you have a problem with UNSIGNED columns in old MySQL applications when porting them to MySQL 4.0, you can use the --sql-mode=NO_UNSIGNED_SUBTRACTION option when starting mysqld. However, as long as you use this option, you are not able to make efficient use of the BIGINT UNSIGNED data type.


User Comments

Posted by Are you mortal? Then prepare to die. on November 3 2004 11:31am[Delete] [Edit]

Be careful that this 'feature' of MySQL dosn't bit you in the ass.

For example, imagine I have a table with two 'unsigned' integer columns (still with me?). Lets call those columns 'one' and 'two'. Now imagine the following query...

# Query to select the 10 biggest differences between two colums
SELECT one - two AS diff
ORDER BY one - two
LIMIT 10;

If the result of 'one - two' is negative (imagine that the value of two is bigger than one), then you end up with values of 18446744073709551615.

This isn't a bug mind you, as this fact is documented this is the expected behaviour!

So, still looking for the 10 biggest differences you might try...

# Query 2 to select the 10 biggest differences between two colums
SELECT one - two AS diff
WHERE one - two < 10000 -- Hopefuly bigger than our biggest differences
ORDER BY one - two
LIMIT 10;

You find it dosn't work, (you still get the 18446744073709551615s) because the internals of subtracting unsigned columns are so messed up.

You need to do the following...

# Query 3 to select the 10 biggest differences between two colums
SELECT CAST(one - two AS SIGNED) AS diff
ORDER BY diff
LIMIT 10;

I hope this example helps

Posted by Richard Crawshaw on January 3 2005 4:40pm[Delete] [Edit]

The target data types that CAST() and CONVERT() support is limited. For example the DECIMAL (or NUMERIC) data type is not supported.

SELECT CAST(NULL AS DECIMAL(9,4)) AS curMoney
does not work.

If you wish to CREATE a new table from a SELECT statement and need to convert a column into a non-supported data type then you will have to explicity create the table first and then INSERT your data into it. Use:

CREATE TEMPORARY TABLE tblTemp(
curMoney DECIMAL(9,4) NULL
);

INSERT INTO tblTemp
SELECT NULL;

This will force an implicit conversion during the INSERT process.

Instead of:
CREATE TEMPORARY TABLE tblTemp
SELECT CAST(NULL AS DECIMAL(9,4)) AS 'curMoney'

Which produces an error.

Posted by anne blankert on May 29 2006 10:14pm[Delete] [Edit]

To convert to numeric, the convert() and cast() functions are less forgiving then the implicit conversion when it comes to the data to be converted. If you want to convert "1a" or "1 apple", "2 apples", " 3 things" to 1, 1, 2 and 3 respectivly, the cast and convert function will produce an error. Instead use select 0+'1a', 0+'1 apple', 0+'2 apples', 0+' 3 things'.

Posted by Ronald Rudy on December 5 2006 5:07pm[Delete] [Edit]

Here's a workaround for not being able to cast/convert a value during table creation with just a create:

CREATE TEMPORARY TABLE tmp
SELECT 1000000.001-1000000.001 as n;

This will yield a table with the following structure:

+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| n     | double(20,3) |      |     | 0.000   |       |
+-------+--------------+------+-----+---------+-------+

Add your own comment.