最近一週接連處理了2個由於int轉換到varchar而無法使用索引#，而引發的慢查詢。
CREATE TABLE `appstat_day_prototype_201305` ( `day_key` date NOT NULL DEFAULT '1900-01-01', `appkey` varchar(20) NOT NULL DEFAULT '', `user_total` bigint(20) NOT NULL DEFAULT '0', `user_activity` bigint(20) NOT NULL DEFAULT '0', `times_total` bigint(20) NOT NULL DEFAULT '0', `times_activity` bigint(20) NOT NULL DEFAULT '0', `incr_login_daily` bigint(20) NOT NULL DEFAULT '0', `unbind_total` bigint(20) NOT NULL DEFAULT '0', `unbind_activitys` bigint(20) NOT NULL DEFAULT '0', PRIMARY KEY (`appkey`,`day_key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 mysql> explain SELECT * from appstat_day_prototype_201305 where appkey = xxxxx and day_key between '2013-05-23' and '2013-05-30'; +----+-------------+------------------------------+------+---------------+------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------------------------+------+---------------+------+---------+------+----------+-------------+ | 1 | SIMPLE | appstat_day_prototype_201305 | ALL | PRIMARY | NULL | NULL | NULL | 19285787 | Using where | +----+-------------+------------------------------+------+---------------+------+---------+------+----------+-------------+ 1 row in set (0.00 sec) mysql> explain SELECT * from appstat_day_prototype_201305 where appkey = 'xxxxx' and day_key between '2013-05-23' and '2013-05-30'; +----+-------------+------------------------------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------------------------+-------+---------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | appstat_day_prototype_201305 | range | PRIMARY | PRIMARY | 65 | NULL | 1 | Using where | +----+-------------+------------------------------+-------+---------------+---------+---------+------+------+-------------+ 1 row in set (0.00 sec)
從上面可以很明顯的看到由於appkey是varchar，而在where條件中不加''，會引發全表查詢，加了就可以用到索引，這掃描的行數可是天差地別，對於伺服器的壓力和回應時間自然也是天差地別的。
我們再看另一個範例：
*************************** 1. row *************************** Table: poll_joined_151 Create Table: CREATE TABLE `poll_joined_151` ( `poll_id` bigint(11) NOT NULL, `uid` bigint(11) NOT NULL, `item_id` varchar(60) NOT NULL, `add_time` int(11) NOT NULL DEFAULT '0', `anonymous` tinyint(1) NOT NULL DEFAULT '0', `sub_item` varchar(1200) NOT NULL DEFAULT '', KEY `idx_poll_id_uid_add_time` (`poll_id`,`uid`,`add_time`), KEY `idx_anonymous_id_addtime` (`anonymous`,`poll_id`,`add_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 SELECT * FROM poll_joined_151 WHERE poll_id = '2348993' AND anonymous =0 ORDER BY add_time DESC LIMIT 0 , 3 *************************** 1. row *************************** id: 1 select_type: SIMPLE table: poll_joined_151 type: ref possible_keys: idx_poll_id_uid_add_time,idx_anonymous_id_addtime key: idx_anonymous_id_addtime key_len: 9 ref: const,const rows: 30240 Extra: Using where
從上面的範例看，雖然poll_id的類型是bigint，但是SQL中加入了''，但這個語句還是用到了索引，雖然掃描行數也不少，但能用到索引就是好SQL。
那麼一個小小的''為什麼會有這麼大的影響呢？根本原因是因為MySQL在比較文字型別和數字型別比較的時候會進行隱式的型別轉換。
以下是5.5官方手冊的說明：
If both arguments in a comparison operation are strings, they are compared as strings. 两个参数都是字符串，会按照字符串来比较，不做类型转换。 If both arguments are integers, they are compared as integers. 两个参数都是整数，按照整数来比较，不做类型转换。 Hexadecimal values are treated as binary strings if not compared to a number. 十六进制的值和非数字做比较时，会被当做二进制串。 If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed. This is done to be more ODBC-friendly. Note that this is not done for the arguments to IN()! To be safe, always use complete datetime, date, or time strings when doing comparisons. For example, to achieve best results when using BETWEEN with date or time values, use CAST() to explicitly convert the values to the desired data type. 有一个参数是 TIMESTAMP 或 DATETIME，并且另外一个参数是常量，常量会被转换为 timestamp If one of the arguments is a decimal value, comparison depends on the other argument. The arguments are compared as decimal values if the other argument is a decimal or integer value, or as floating-point values if the other argument is a floating-point value. 有一个参数是 decimal 类型，如果另外一个参数是 decimal 或者整数，会将整数转换为 decimal 后进行比较，如果另外一个参数是浮点数，则会把 decimal 转换为浮点数进行比较 In all other cases, the arguments are compared as floating-point (real) numbers.所有其他情况下，两个参数都会被转换为浮点数再进行比较
根據以上的說明，當where條件之後的值的類型和表結構不一致的時候， MySQL會做隱式的型別轉換，都會轉換為浮點數在比較。
對於第一種情況：
例如where string = 1；
#需要將索引中的字串轉換成浮點數，但由於'1',' 1','1a'都會比轉換成1,故MySQL無法使用索引只能進行全表掃描，故造成了慢查詢的產生。
mysql> SELECT CAST(' 1' AS SIGNED)=1; +-------------------------+ | CAST(' 1' AS SIGNED)=1 | +-------------------------+ | 1 | +-------------------------+ 1 row in set (0.00 sec) mysql> SELECT CAST(' 1a' AS SIGNED)=1; +--------------------------+ | CAST(' 1a' AS SIGNED)=1 | +--------------------------+ | 1 | +--------------------------+ 1 row in set, 1 warning (0.00 sec) mysql> SELECT CAST('1' AS SIGNED)=1; +-----------------------+ | CAST('1' AS SIGNED)=1 | +-----------------------+ | 1 | +-----------------------+ 1 row in set (0.00 sec)
同時要注意一點，由於都會轉換成浮點數進行比較，而浮點數只有53bit，故當超過最大值的時候，比較會出現問題。
對於第二種情況：
由於索引建立在int的基礎上，而將純數字的字串可以百分之百轉換成數字，故可以使用到索引，雖然也會進行一定的轉換，消耗一定的資源，但是最終仍然使用了索引，不會產生慢查詢。
mysql> select CAST( '30' as SIGNED) = 30; +----------------------------+ | CAST( '30' as SIGNED) = 30 | +----------------------------+ | 1 | +----------------------------+ 1 row in set (0.00 sec)
以上是在MySQL資料庫中把int類型轉換到varchar類型引發的慢查詢問題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
