{"id":1886,"date":"2010-02-02T21:55:22","date_gmt":"2010-02-02T19:55:22","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=1886"},"modified":"2010-02-02T21:55:22","modified_gmt":"2010-02-02T19:55:22","slug":"beware-of-implicit-casting","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/beware-of-implicit-casting","title":{"rendered":"Beware of implicit casting"},"content":{"rendered":"

Ever so often a query provides a “bad” execution plan. Adding a missing index can many times solve the problem. However, not everything can be solved with an index. I wish to highlight the point of having an implicit cast<\/em>, which negates the use of an index on MySQL.<\/p>\n

I see this happening a lot on customers’ databases, and this begs for a short introduction.<\/p>\n

MySQL doesn’t support index functions<\/h4>\n

Let’s assume the following table:<\/p>\n

\n
CREATE TABLE `person` (\r\n `id` bigint(20) NOT NULL AUTO_INCREMENT,\r\n `first_name` varchar(32) CHARACTER SET utf8 DEFAULT NULL,\r\n `last_name` varchar(32) CHARACTER SET utf8 DEFAULT NULL,\r\n `driver_license_registration` bigint(20) DEFAULT NULL,\r\n PRIMARY KEY (`id`),\r\n KEY `last_name` (`last_name`),\r\n KEY `driver_license_registration` (`driver_license_registration`)\r\n)\r\n<\/pre>\n<\/blockquote>\n
And suppose we’re looking for persons whose last name begin with “Smith”. The following query will NOT<\/strong> utilize an index:<\/p>\n
\n
SELECT * FROM person WHERE LEFT(last_name, 5) = 'Smith'<\/strong>;\r\n<\/pre>\n<\/blockquote>\n
Why not? Because we use a function (LEFT<\/strong>) over the last_name<\/strong> column, and this makes MySQL unable to deduce the outcome of the expression. Will it be ordered in the same way as the original column? (in this case, the answer is yes<\/em>, LEFT<\/strong> is a monotonic function) Is it possible to produce the reverse function? (In this case, no<\/em>). MySQL cannot and does not handle these questions and therefore avoids using the index on last_name<\/strong> altogether:<\/p>\n
\n
EXPLAIN SELECT * FROM person WHERE LEFT(last_name, 5) = 'Smith';\r\n+----+-------------+--------+------+---------------+------+---------+------+------+-------------+\r\n| id | select_type | table\u00a0 | type | possible_keys | key\u00a0 | key_len | ref\u00a0 | rows | Extra\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+----+-------------+--------+------+---------------+------+---------+------+------+-------------+\r\n|\u00a0 1 | SIMPLE\u00a0\u00a0\u00a0\u00a0\u00a0 | person | ALL<\/strong>\u00a0 | NULL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | NULL | NULL\u00a0\u00a0\u00a0 | NULL | 1000 | Using where |\r\n+----+-------------+--------+------+---------------+------+---------+------+------+-------------+\r\n<\/pre>\n<\/blockquote>\n
To solve the problem above, a simple change to the query will do the trick:<\/p>\n
\n
EXPLAIN SELECT * FROM person WHERE last_name LIKE 'Smith%'<\/strong>;\r\n+----+-------------+--------+-------+---------------+-----------+---------+------+------+-------------+\r\n| id | select_type | table\u00a0 | type\u00a0 | possible_keys | key\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | key_len | ref\u00a0 | rows | Extra\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+----+-------------+--------+-------+---------------+-----------+---------+------+------+-------------+\r\n|\u00a0 1 | SIMPLE\u00a0\u00a0\u00a0\u00a0\u00a0 | person | range<\/strong> | last_name\u00a0\u00a0\u00a0\u00a0 | last_name | 99\u00a0\u00a0\u00a0\u00a0\u00a0 | NULL |\u00a0\u00a0\u00a0 5 | Using where |\r\n+----+-------------+--------+-------+---------------+-----------+---------+------+------+-------------+\r\n<\/pre>\n<\/blockquote>\n
Not all functions are explicit<\/h4>\n
This leads us to the subject of this post. What if we were to look for persons whose driver license registration number begins with ‘123’<\/strong>? Trying to learn from the above example, we write:<\/p>\n
\n
SELECT * FROM person WHERE driver_license_registration LIKE '123%';<\/pre>\n<\/blockquote>\n
But the above query does NOT<\/strong> utilize an index! See:<\/p>\n
\n
EXPLAIN SELECT * FROM person WHERE driver_license_registration LIKE '123%';\r\n+----+-------------+--------+------+-----------------------------+------+---------+------+------+-------------+\r\n| id | select_type | table\u00a0 | type | possible_keys\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | key\u00a0 | key_len | ref\u00a0 | rows | Extra\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+----+-------------+--------+------+-----------------------------+------+---------+------+------+-------------+\r\n|\u00a0 1 | SIMPLE\u00a0\u00a0\u00a0\u00a0\u00a0 | person | ALL\u00a0 | driver_license_registration | NULL | NULL\u00a0\u00a0\u00a0 | NULL | 1000 | Using where |\r\n+----+-------------+--------+------+-----------------------------+------+---------+------+------+-------------+\r\n<\/pre>\n<\/blockquote>\n
Why not?<\/p>\n
Because the driver_license_registration<\/strong> column is an integer. The query asks for a string comparison (LIKE ‘123%’<\/strong>). This kind of comparison cannot be performed on integers. The column value will have to transform to text in order to work out the query. Effectively, it’s as if we wrote:<\/p>\n
\n
SELECT * FROM person WHERE CAST(driver_license_registration AS CHAR)<\/strong> LIKE '123%';\r\n<\/pre>\n<\/blockquote>\n
There’s no immediate solution to this last query. Perhaps the column should be textual after all, perhaps maintain a “ghost” column. If the number of digits in a number if fixed an known, then we can convert the above to a range query.<\/p>\n
Casting is an implicit function<\/h4>\n
And, alas, it’s a well hidden function. There’s nothing to suggest a problem here. This is SQL, not Java. It’s not a strongly typed language. I see the above example quite a lot. Another common casting mistake is comparing Timestamp values to strings.<\/p>\n
So, until MySQL supports index functions, watch out for these nuances.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ever so often a query provides a “bad” execution plan. Adding a missing index can many times solve the problem. However, not everything can be solved with an index. I wish to highlight the point of having an implicit cast, which negates the use of an index on MySQL. I see this happening a lot […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[26,21],"class_list":["post-1886","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-indexing","tag-sql"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-uq","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/1886","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=1886"}],"version-history":[{"count":14,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/1886\/revisions"}],"predecessor-version":[{"id":1901,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/1886\/revisions\/1901"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=1886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=1886"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=1886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}