一個單引號激發的MYSQL機能成績剖析。本站提示廣大學習愛好者：（一個單引號激發的MYSQL機能成績剖析）文章只能為提供參考，不一定能成為您想要的結果。以下是一個單引號激發的MYSQL機能成績剖析正文
關於年夜型的體系而言，Oracle,SQLServer無疑是最好的選擇，可看看如今愈來愈多的小網站，他們沒有本身的辦事器，只是買他人的空間和數據庫，但這類小型的數據庫在機能受騙然和年夜型數據庫沒有比較性，但小型的數據庫也要對本身的優化方法，明天和年夜家分享Mysql中加沒加單引號的偉大差別，關於MYSQL機能優化很成心義。
方才我們說過了，生涯中不免會有一些不如意，好比，我們用一個字符串類型的字段來作為主鍵，外面上，這太不如意了，但是，現實也證實這是有效的。成績也就出來了，當在查詢語句中對該字段值加上單引號和不加查詢耗時相差百倍！
測試表：
CREATE TABLE `foo` ( `key` varchar(10) NOT NULL, `time` int(11) NOT NULL, PRIMARY KEY (`key`)) ENGINE=MyISAM DEFAULT CHARSET=utf8;
然後拔出30多萬條數據，然後履行上面的SQL語句：
SELECT *FROM `foo`WHERE `key` =1293322797
查詢消費 0.1288 秒，年夜約消費這麼久的時光，然後，給1293322797加上單引號：
SELECT *FROM `foo`WHERE `key` ='1293322797'
查詢消費 0.0009 秒，根本上相差100倍！！！也就是說不加單引號MYSQL機能喪失了100倍，很震動的比例！
後來用EXPLAIN分離跑了一下下面兩條語句，見上面兩張圖：
沒有單引號時
有單引號時
很顯著，不應用單引號沒有效上主索引，並停止了全表掃描，應用單引號就可以應用上索引了。
後來我用年夜於分離停止了測試，前往的成果集雷同，而他們的耗時和下面一樣，用EXPLAIN測試，也和下面一樣
SELECT *FROM `foo`WHERE `key` >1293322797SELECT *FROM `foo`WHERE `key` >'1293322797'
加單引號和不加單引號就是這麼年夜的差異！就是會對mysql機能發生這麼年夜的影響。
再後來，我將字段`key`換成INT類型，這時候候，加不加單引號，就沒有甚麼差異了，EXPLAIN顯示他們都異樣可以或許用上主索引，只是key_len變短了。
就是這些，綜上所述，我們在寫SQL查詢的時刻照樣誨人不倦的加上單引號吧，仿佛那沒有害處。
