MySQL數(shù)據(jù)庫(kù)中把int轉(zhuǎn)化varchar引發(fā)的慢查詢
最近一周接連處理了2個(gè)由于int向varchar轉(zhuǎn)換無(wú)法使用索引,從而引發(fā)的慢查詢。
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條件中不加'',會(huì)引發(fā)全表查詢,加了就可以用到索引,這掃描的行數(shù)可是天差地別,對(duì)于服務(wù)器的壓力和響應(yīng)時(shí)間自然也是天差地別的。
我們?cè)倏戳硗庖粋€(gè)例子:
*************************** 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中添加了'',但是這個(gè)語(yǔ)句仍然用到了索引,雖然掃描行數(shù)也不少,但是能用到索引就是好SQL。
那么一個(gè)小小的''為什么會(huì)有這么大的影響呢?根本原因是因?yàn)镸ySQL在對(duì)文本類型和數(shù)字類型進(jìn)行比較的時(shí)候會(huì)進(jìn)行隱式的類型轉(zhuǎn)換。
以下是5.5官方手冊(cè)的說(shuō)明:
If both arguments in a comparison operation are strings, they are compared as strings. 兩個(gè)參數(shù)都是字符串,會(huì)按照字符串來(lái)比較,不做類型轉(zhuǎn)換。 If both arguments are integers, they are compared as integers. 兩個(gè)參數(shù)都是整數(shù),按照整數(shù)來(lái)比較,不做類型轉(zhuǎn)換。 Hexadecimal values are treated as binary strings if not compared to a number. 十六進(jìn)制的值和非數(shù)字做比較時(shí),會(huì)被當(dāng)做二進(jìn)制串。 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. 有一個(gè)參數(shù)是 TIMESTAMP 或 DATETIME,并且另外一個(gè)參數(shù)是常量,常量會(huì)被轉(zhuǎn)換為 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. 有一個(gè)參數(shù)是 decimal 類型,如果另外一個(gè)參數(shù)是 decimal 或者整數(shù),會(huì)將整數(shù)轉(zhuǎn)換為 decimal 后進(jìn)行比較,如果另外一個(gè)參數(shù)是浮點(diǎn)數(shù),則會(huì)把 decimal 轉(zhuǎn)換為浮點(diǎn)數(shù)進(jìn)行比較 In all other cases, the arguments are compared as floating-point (real) numbers.所有其他情況下,兩個(gè)參數(shù)都會(huì)被轉(zhuǎn)換為浮點(diǎn)數(shù)再進(jìn)行比較
根據(jù)以上的說(shuō)明,當(dāng)where條件之后的值的類型和表結(jié)構(gòu)不一致的時(shí)候,MySQL會(huì)做隱式的類型轉(zhuǎn)換,都將其轉(zhuǎn)換為浮點(diǎn)數(shù)在比較。
對(duì)于第一種情況:
比如where string = 1;
需要將索引中的字符串轉(zhuǎn)換成浮點(diǎn)數(shù),但是由于'1',' 1','1a'都會(huì)比轉(zhuǎn)化成1,故MySQL無(wú)法使用索引只能進(jìn)行全表掃描,故造成了慢查詢的產(chǎn)生。
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)
同時(shí)需要注意一點(diǎn),由于都會(huì)轉(zhuǎn)換成浮點(diǎn)數(shù)進(jìn)行比較,而浮點(diǎn)數(shù)只有53bit,故當(dāng)超過(guò)最大值的時(shí)候,比較會(huì)出現(xiàn)問(wèn)題。
對(duì)于第二種情況:
由于索引建立在int的基礎(chǔ)上,而將純數(shù)字的字符串可以百分百轉(zhuǎn)換成數(shù)字,故可以使用到索引,雖然也會(huì)進(jìn)行一定的轉(zhuǎn)換,消耗一定的資源,但是最終仍然使用了索引,不會(huì)產(chǎn)生慢查詢。
mysql> select CAST( '30' as SIGNED) = 30; +----------------------------+ | CAST( '30' as SIGNED) = 30 | +----------------------------+ | 1 | +----------------------------+ 1 row in set (0.00 sec)
以上所述是小編給大家介紹的MySQL數(shù)據(jù)庫(kù)中把int轉(zhuǎn)化varchar引發(fā)的慢查詢 ,希望對(duì)大家有所幫助,如果大家有任何疑問(wèn)請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持!
- 深入mysql慢查詢?cè)O(shè)置的詳解
- 詳解MySql的慢查詢分析及開(kāi)啟慢查詢?nèi)罩?/a>
- mysql 開(kāi)啟慢查詢 如何打開(kāi)mysql的慢查詢?nèi)罩居涗?/a>
- MYSQL5.7.9開(kāi)啟慢查詢?nèi)罩镜募记?/a>
- MySQL開(kāi)啟慢查詢?nèi)罩緇og-slow-queries的方法
- MySQL慢查詢查找和調(diào)優(yōu)測(cè)試
- MySQL慢查詢優(yōu)化之慢查詢?nèi)罩痉治龅膶?shí)例教程
- MySQL 開(kāi)啟慢查詢?nèi)罩镜姆椒?/a>
- 簡(jiǎn)單談?wù)凪ySQL優(yōu)化利器-慢查詢
- MySQL慢查詢?nèi)绾味ㄎ辉斀?/a>
相關(guān)文章
基于mysql數(shù)據(jù)庫(kù)的密碼問(wèn)題詳解
本篇文章是對(duì)mysql數(shù)據(jù)庫(kù)的密碼問(wèn)題進(jìn)行了詳細(xì)的分析介紹,需要的朋友參考下2013-06-06MySQL Packet for query is too large 問(wèn)題及解決方法
這篇文章主要介紹了MySQL Packet for query is too large 問(wèn)題及解決方法,需要的朋友可以參考下2018-05-05mysql8.0.11 winx64手動(dòng)安裝配置教程
這篇文章主要為大家詳細(xì)介紹了mysql8.0.11 winx64手動(dòng)安裝配置教程,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-05-05mysql查詢獲得兩個(gè)時(shí)間的時(shí)間差方式
這篇文章主要介紹了mysql查詢獲得兩個(gè)時(shí)間的時(shí)間差方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-05-05