一個單引號引發(fā)的MYSQL性能問題分析
更新時間：2011年03月06日 20:34:07 作者：
剛剛我們說過了，生活中難免會有一些不如意，比如，我們用一個字符串類型的字段來作為主鍵，表面上，這太不如意了，然而，事實也證明這是有用的。
對于大型的系統(tǒng)而言，Oracle,SQLServer無疑是最好的選擇，可看看現(xiàn)在越來越多的小網(wǎng)站，他們沒有自己的服務(wù)器，只是買別人的空間和數(shù)據(jù)庫，但這種小型的數(shù)據(jù)庫在性能上當(dāng)然和大型數(shù)據(jù)庫沒有對比性，但小型的數(shù)據(jù)庫也要對自己的優(yōu)化方式，今天和大家分享Mysql中加沒加單引號的巨大區(qū)別，對于MYSQL性能優(yōu)化很有意義。
剛剛我們說過了，生活中難免會有一些不如意，比如，我們用一個字符串類型的字段來作為主鍵，表面上，這太不如意了，然而，事實也證明這是有用的。問題也就出來了，當(dāng)在查詢語句中對該字段值加上單引號和不加查詢耗時相差百倍！
測試表：
CREATE TABLE `foo` ( `key` varchar(10) NOT NULL, `time` int(11) NOT NULL, PRIMARY KEY (`key`)) ENGINE=MyISAM DEFAULT CHARSET=utf8;
然后插入30多萬條數(shù)據(jù)，然后執(zhí)行下面的SQL語句：
SELECT *FROM `foo`WHERE `key` =1293322797
查詢花費(fèi) 0.1288 秒，大約花費(fèi)這么久的時間，然后，給1293322797加上單引號：
SELECT *FROM `foo`WHERE `key` ='1293322797'
查詢花費(fèi) 0.0009 秒，基本上相差100倍！??！也就是說不加單引號MYSQL性能損失了100倍，很震撼的比例！
SELECT *FROM `foo`WHERE `key` >1293322797SELECT *FROM `foo`WHERE `key` >'1293322797'
加單引號和不加單引號就是這么大的差別！就是會對mysql性能產(chǎn)生這么大的影響。
再后來，我將字段`key`換成INT類型，這時候，加不加單引號，就沒有什么差別了，EXPLAIN顯示他們都同樣能夠用上主索引，只是key_len變短了。
剛剛我們說過了，生活中難免會有一些不如意，比如，我們用一個字符串類型的字段來作為主鍵，表面上，這太不如意了，然而，事實也證明這是有用的。問題也就出來了，當(dāng)在查詢語句中對該字段值加上單引號和不加查詢耗時相差百倍！
測試表：
復(fù)制代碼 代碼如下:
CREATE TABLE `foo` ( `key` varchar(10) NOT NULL, `time` int(11) NOT NULL, PRIMARY KEY (`key`)) ENGINE=MyISAM DEFAULT CHARSET=utf8;
然后插入30多萬條數(shù)據(jù)，然后執(zhí)行下面的SQL語句：
復(fù)制代碼 代碼如下:
SELECT *FROM `foo`WHERE `key` =1293322797
查詢花費(fèi) 0.1288 秒，大約花費(fèi)這么久的時間，然后，給1293322797加上單引號：
復(fù)制代碼 代碼如下:
SELECT *FROM `foo`WHERE `key` ='1293322797'
查詢花費(fèi) 0.0009 秒，基本上相差100倍！??！也就是說不加單引號MYSQL性能損失了100倍，很震撼的比例！
后來用EXPLAIN分別跑了一下上面兩條語句，見下面兩張圖：
沒有單引號時
有單引號時
很明顯，不使用單引號沒有用上主索引，并進(jìn)行了全表掃描，使用單引號就能使用上索引了。
后來我用大于分別進(jìn)行了測試，返回的結(jié)果集相同，而他們的耗時和上面一樣，用EXPLAIN測試，也和上面一樣
復(fù)制代碼 代碼如下:
SELECT *FROM `foo`WHERE `key` >1293322797SELECT *FROM `foo`WHERE `key` >'1293322797'
加單引號和不加單引號就是這么大的差別！就是會對mysql性能產(chǎn)生這么大的影響。
再后來，我將字段`key`換成INT類型，這時候，加不加單引號，就沒有什么差別了，EXPLAIN顯示他們都同樣能夠用上主索引，只是key_len變短了。
就是這些，綜上所述，我們在寫SQL查詢的時候還是不厭其煩的加上單引號吧，似乎那沒有壞處。
相關(guān)文章
今天小編就為大家分享一篇關(guān)于linux下mysql亂碼問題的解決方案，小編覺得內(nèi)容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧2019-03-03
MYSQL 完全備份、主從復(fù)制、級聯(lián)復(fù)制、半同步小結(jié)
這篇文章主要介紹了MYSQL 完全備份、主從復(fù)制、級聯(lián)復(fù)制、半同步小結(jié)，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2019-05-05
本篇文章主要給大家講述了MySQL存儲引擎相關(guān)基礎(chǔ)知識，有助于大家對MySQL存儲引擎有更好的理解，學(xué)習(xí)下吧。2017-12-12
MySQL數(shù)據(jù)庫實現(xiàn)MMM高可用群集架構(gòu)
這篇文章主要介紹了MySQL數(shù)據(jù)庫實現(xiàn)MMM高可用群集架構(gòu)，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-12-12
這篇文章主要介紹了MySQL之主鍵索引排序失效問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-12-12
用戶經(jīng)認(rèn)證后成功登錄數(shù)據(jù)庫,之后服務(wù)器將通過系統(tǒng)權(quán)限表檢測用戶發(fā)出的每個請求操作，判斷用戶是否有足夠的權(quán)限來實施該操作，這就是MySQL的權(quán)限控制過程2022-12-12
MySql報錯Table mysql.plugin doesn’t exist的解決方法
一般產(chǎn)生原因是手工更改my.ini的數(shù)據(jù)庫文件存放地址導(dǎo)致的,大家可以參考下下面的方法2013-02-02
MySQL與JDBC之間的SQL預(yù)編譯技術(shù)講解
這篇文章主要介紹了MySQL與JDBC之間的SQL預(yù)編譯技術(shù)講解，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-11-11
這篇文章主要介紹了MySQL GTID主備不一致的修復(fù)方案，幫助大家更好的理解和學(xué)習(xí)使用MySQL數(shù)據(jù)庫，感興趣的朋友可以了解下2021-04-04
本篇文章是對MySQL查詢優(yōu)化中的explain進(jìn)行了詳細(xì)的分析介紹，需要的朋友參考下2013-06-06