從這幾個(gè)方面入手
1.建立一些有效的索引，索引是比較影響查詢(xún)速度的，它可以快速的定位到你要查詢(xún)的數(shù)據(jù)，如果有多個(gè)條件的話可以建立聯(lián)合索引，但要注意聯(lián)合索引的順序，比如有一個(gè)這樣的索引，有以下這些字段，(user_id,type_id,views (瀏覽次數(shù)))當(dāng)我們寫(xiě)查詢(xún)語(yǔ)句的時(shí)候，mysql會(huì)從左往右匹配索引。比如我們這么寫(xiě) (加入表名叫post)
select * from post where user_id = 1 and views > 2 ,如果這樣的話，我們的索引只匹配到了user_id 就不匹配了，因?yàn)閙ysql只能順序的匹配索引。索引的順序也很重要，一般是將區(qū)分度比較高的索引放在最左側(cè)，比如 上邊的例子，因?yàn)橐粋€(gè)網(wǎng)站里用戶的數(shù)量正常來(lái)說(shuō)會(huì)比類(lèi)型的數(shù)量要多很多，所以用戶id的區(qū)分度比較高。
2.如果實(shí)在是無(wú)法避免條件確實(shí)不夠，比如上例子確實(shí)只需要這兩個(gè)條件(user_id,views),如果是這兩個(gè)，mysql就只能匹配user_id,而type_id 無(wú)法匹配,由于type數(shù)量并不多，那么我們可以在語(yǔ)句中加入 and type in(此處填寫(xiě)所有類(lèi)型id,當(dāng)然如果類(lèi)型特別多就不要這么干了)。這樣的話，建立的索引就能全部匹配。
3.盡可能的用合適的數(shù)據(jù)類(lèi)型來(lái)表示數(shù)據(jù)，定長(zhǎng)的數(shù)據(jù)char要比varchar優(yōu)秀，如果表示狀態(tài)的話tinyint要比int好。
4.如果數(shù)據(jù)量特別多，需要統(tǒng)計(jì)條數(shù)的話，如果不是需要非常精確的數(shù)字 explain 的row 是比較快的方式，它比count要快。
5.切分查詢(xún)，比如，有這樣一個(gè)需求。查詢(xún)出所有文章(post)，并且包含作者的名字也就是user_name ,一般的話，我們會(huì)想到去連表，但我們可以把這個(gè)查詢(xún)切分開(kāi)來(lái)，先用一個(gè)sql查詢(xún)出所有文章，再通過(guò)代碼拿到所有user_id，然后用in去user表中查詢(xún)，最后將查詢(xún)的結(jié)果合并，這么做雖然有些麻煩，但有時(shí)會(huì)是比較快的選擇，因?yàn)?，?dāng)我們將查詢(xún)分開(kāi)的時(shí)候，如果此前有程序做過(guò)同樣的查詢(xún)，mysql就不會(huì)執(zhí)行一遍查詢(xún)語(yǔ)句，而是會(huì)直接從緩存里取數(shù)據(jù)。
6.如果數(shù)據(jù)量不大，建議還是全表掃比較快，因?yàn)楫吘顾饕灿谐杀尽?/p>

裝5.5版本的mysql占用1G主機(jī)的4.6%內(nèi)存，幾乎不怎么占用
但是5.7版本的超占內(nèi)存。我已經(jīng)卸載了

要先確定性能瓶頸到底在哪里，再來(lái)談優(yōu)化！