MySQL優(yōu)化


1.為查詢緩存優(yōu)化你的查詢

????? 大多數(shù)的MySQL服務器都開啟了查詢緩存孩革。這是提高性能最有效的方法之一,而且這是被MySQL的數(shù)據(jù)庫引擎處理的得运。當有很多相同的查詢被執(zhí)行了多次的時候膝蜈,這些查詢結果會被放到一個緩存中,這樣熔掺,后續(xù)的相同的查詢就不用操作表而直接訪問緩存結構了彬檀。

????? 這里最主要的問題是,對于程序員來書瞬女,這件事情很容易被忽略的窍帝。因為,我們某些查詢語句會讓MySQL不使用緩存诽偷。

查詢緩存不開啟

?????? $result = mysql_query("select username from user where signup_date >=curdate()");

開啟查詢緩存

?????? $today = date("Y-m-d");

?????? $result? = mysql_query("select username from user signup_date >='$today'");

上面兩條SQL語句的差別就是CURDATE()坤学,MySQL的查詢緩存對這個函數(shù)不起作用疯坤。所以,像NOW()和RAND()或是其他的諸如此類的SQL函數(shù)都不會開啟查詢緩存,因為這寫函數(shù)的返回是會不定的易變的深浮。所以压怠,你需要的就是用一個變量來代替MySQL的函數(shù),從而開啟緩存飞苇。

2.EXPLAIN你的SELECT查詢

???? 使用EXPLAIN關鍵字可以讓你知道MYSQL是如何處理你的SQL語句的菌瘫。這可以幫你分析你的查詢語句或是表結構的性能瓶頸。

???? EXPLAIN的查詢結果還會告訴你你的索引主鍵被如何利用的布卡,你的數(shù)據(jù)表是如何被搜索和排序的......等等雨让。

??? 挑一個你的SELECT語句,把關鍵字EXPLAIN加到前面忿等。你可以使用phpmyadmin來做這個事情栖忠。然后,你會看到一張表格贸街。

3.當只要一行數(shù)據(jù)時使用limit 1

????? 當你查詢表的有些時候庵寞,你已經(jīng)知道結果只會有一條結果,但因為你可能需要去fetche游標薛匪,或是你也許會去檢查返回的記錄書捐川。

????? 在這種情況下,加上limit 1可以增加性能逸尖。這樣一來属拾,MYSQL數(shù)據(jù)庫引擎會在找到一條數(shù)據(jù)后停止搜索,而不是繼續(xù)往后查找下一條符合記錄的數(shù)據(jù)

???? 下面有倆條語句

???? $result = mysql_query("select * from user where username = 'admin' ");

??? if(mysql_num_rows($result) > 0){

? ? ? ? // 代碼 ?

??? }

??? $result? = mysql_query("select * from user where username = 'admin' limit 1");

??? if(mysql_num_rows($result) > 0){

??????? // 代碼

??? }

通過觀察我們可以清楚的知道冷溶,這兩條SQL語句的效率渐白,第二條語句是大于第一條的。

4.為搜索字段建立索引

???? 索引并不一定就是給主鍵或是唯一的字段逞频,如果在你的表中纯衍,有某個字段你總要是經(jīng)常用來做搜索,那么苗胀,請為其建立索引襟诸。

從上圖你可以看到倆條語句模糊查詢的時間。一個建立索引基协,一個是沒有索引歌亲,性能差了4倍左右。


另外澜驮,你應該也需要知道什么樣的搜索是不能使用正常的索引的陷揪。例如,當你需要在一篇大的文章中搜索一個詞時,如where post_content like '%apple%' 悍缠,索引可能是沒有意義的卦绣,你可能需要使用MYSQL全文索引,或是自己做一個索引飞蚓。

5.在join表的時候使用相同類型的滤港,并建立索引

??? 如果你的應用程序有很多join查詢,你應該確認倆個表中join的字段是被建立過索引的趴拧。這樣溅漾,MYSQL內(nèi)部會啟動為你優(yōu)化join的SQL語句的機制。

而且著榴,這些被用來JOIN的字段添履,應該是相同的類型。例如:如果你要把DECIMAL字段和一個INT字段join在一起兄渺,MYSQL就無法使用他們的索引缝龄。對于那些STRING類型汰现,還需要有相同的字符集才行挂谍。

$result = mysql_query('select company_name from users left join companies on users.state = companies.state where user.id = $user_id');

6.千萬不要ORDER BY RAND()

???? 想打亂返回的數(shù)據(jù)行?隨機挑一個數(shù)據(jù)瞎饲?真不知道誰發(fā)明了這種用法口叙,但很多新手很喜歡這樣用。但你卻不了解這樣做有多么可怕的性能問題嗅战。

??? 如果你真的想把返回的數(shù)據(jù)行打亂了妄田,你有N種方法可以達到這個目的。這樣使用只能讓你的數(shù)據(jù)庫的性能呈指數(shù)級的下降驮捍。這里的問題是:MYSLQ會不得不去執(zhí)行RAND()函數(shù)(很耗CPU時間)疟呐,而且這是為了每一行記錄去記行,然后再對其排序东且。就算是你用了limit 1 也無濟于事

7.避免SELECT *

??? 從數(shù)據(jù)庫里讀出越多的數(shù)據(jù)启具,那么查詢就會變得越慢。并且珊泳,如果你的數(shù)據(jù)庫服務器和WEB服務器是兩臺獨立的服務器的話鲁冯,這還會增加網(wǎng)絡傳輸?shù)呢撦d。

? 所以色查,你應該養(yǎng)成一個需要什么就取什么的好的習慣薯演。

8.永遠為每張表設置一個ID

???? 我們應該為數(shù)據(jù)庫里的每張表都設置一個ID做為其主鍵,而且最好的是一個INT型的秧了,并設置自動增加的AUTO_INCREMENT標志跨扮。

???? 就算是你users表有一個主鍵叫"email"的字段,你也別讓它成為主鍵。使用varchar 類型來當主鍵會使得性能下降好港。另外愉镰,在你的程序中,你應該使用表的ID來構造你的數(shù)據(jù)結構钧汹。

???? 而且丈探,在MYSQL數(shù)據(jù)引擎下,還有一些操作需要使用主鍵拔莱,在這些情況下碗降,主鍵的性能和設置變得非常重要,比如塘秦,集群讼渊,分區(qū)......

??? 在這里,只有一個情況是例外尊剔,那就是"關聯(lián)表"的外鍵爪幻,也就是說,這個表的主鍵须误,通過若干個別的表的主鍵構成挨稿。我們把這個情況叫做"外鍵"。比如:有一個"學生表"有學生的ID京痢,有一個"課程表"有課程ID奶甘,那么"成績表"就是"關聯(lián)表"了,其關聯(lián)了學生表和課程表祭椰,在成績表中臭家,學生ID和課程ID叫"外鍵"其共同組成主鍵。

9.使用ENUM而不是VARCHAR

??? ENUM類型是非撤接伲快和緊湊的钉赁。在實際上,其保存的是TINYINT,但其外表顯示為字符串携茂。這樣一來你踩,用這個字段來做一些選項列表變的相當?shù)耐昝馈?/p>

? ? 如果你有一個字段,比如"性別"邑蒋,"國家"姓蜂,"民族",你知道這些字段的取值是有限而且固定的医吊,那么钱慢,你應該使用ENUM而不是VARCHAR。

??? MYQSL也有一個"建議"卿堂,告訴你怎么去重新組織你的表結構束莫。當你有一個VARHCAR字段時懒棉,這個建議會告訴你把其改成ENUM類型。使用PROCEDURE ANALYSE() 你可以得到相關的建議览绿。

10.盡可能的使用NOT NULL

????? 除非你有一個很特別的原因去使用NULL值策严,你應該總是讓你的字段保持NOT NULL。這看起來好像有點爭議饿敲。

???? 首先妻导,問問你自己"empty"和"null"有多大的區(qū)別?如果你覺得它們之間沒有什么區(qū)別怀各,那么你就不要使用null倔韭。

?? 不要以為NULL不需要空間,其需要額外的空間瓢对,并且寿酌,在你進行比較的時候,你的程序會更復雜硕蛹。當然醇疼,這里并不是說你就不能使用NULL了,現(xiàn)實情況是很復雜的法焰,依然會有些情況下秧荆,你需要使用NULL值。

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末壶栋,一起剝皮案震驚了整個濱河市辰如,隨后出現(xiàn)的幾起案子普监,更是在濱河造成了極大的恐慌贵试,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,386評論 6 506
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件凯正,死亡現(xiàn)場離奇詭異毙玻,居然都是意外死亡,警方通過查閱死者的電腦和手機廊散,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,142評論 3 394
  • 文/潘曉璐 我一進店門桑滩,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人允睹,你說我怎么就攤上這事运准。” “怎么了缭受?”我有些...
    開封第一講書人閱讀 164,704評論 0 353
  • 文/不壞的土叔 我叫張陵胁澳,是天一觀的道長。 經(jīng)常有香客問我米者,道長韭畸,這世上最難降的妖魔是什么宇智? 我笑而不...
    開封第一講書人閱讀 58,702評論 1 294
  • 正文 為了忘掉前任,我火速辦了婚禮胰丁,結果婚禮上随橘,老公的妹妹穿的比我還像新娘。我一直安慰自己锦庸,他們只是感情好机蔗,可當我...
    茶點故事閱讀 67,716評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著甘萧,像睡著了一般蜒车。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上幔嗦,一...
    開封第一講書人閱讀 51,573評論 1 305
  • 那天酿愧,我揣著相機與錄音,去河邊找鬼邀泉。 笑死嬉挡,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的汇恤。 我是一名探鬼主播庞钢,決...
    沈念sama閱讀 40,314評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼因谎!你這毒婦竟也來了基括?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 39,230評論 0 276
  • 序言:老撾萬榮一對情侶失蹤财岔,失蹤者是張志新(化名)和其女友劉穎风皿,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體匠璧,經(jīng)...
    沈念sama閱讀 45,680評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡桐款,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,873評論 3 336
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了夷恍。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片魔眨。...
    茶點故事閱讀 39,991評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖酿雪,靈堂內(nèi)的尸體忽然破棺而出遏暴,到底是詐尸還是另有隱情,我是刑警寧澤指黎,帶...
    沈念sama閱讀 35,706評論 5 346
  • 正文 年R本政府宣布朋凉,位于F島的核電站,受9級特大地震影響袋励,放射性物質(zhì)發(fā)生泄漏侥啤。R本人自食惡果不足惜当叭,卻給世界環(huán)境...
    茶點故事閱讀 41,329評論 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望盖灸。 院中可真熱鬧蚁鳖,春花似錦、人聲如沸赁炎。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,910評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽徙垫。三九已至讥裤,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間姻报,已是汗流浹背己英。 一陣腳步聲響...
    開封第一講書人閱讀 33,038評論 1 270
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留吴旋,地道東北人损肛。 一個月前我還...
    沈念sama閱讀 48,158評論 3 370
  • 正文 我出身青樓,卻偏偏與公主長得像荣瑟,于是被迫代替她去往敵國和親治拿。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,941評論 2 355

推薦閱讀更多精彩內(nèi)容