服務(wù)器層面

• innodb_buffer_pool_size

將緩沖池的大小設(shè)置的盡可能大，比如設(shè)為總內(nèi)存的3/4。這樣可以減少mysql的磁盤IO次數(shù)，使得盡可能地從緩沖池里讀數(shù)據(jù)

• innodb_log_file_size

在生產(chǎn)環(huán)境下，可以盡可能地把一些日志開關(guān)給關(guān)掉。比如通用查詢?nèi)罩荆樵內(nèi)罩?，錯(cuò)誤日志。并且，將redo log的大小設(shè)置的足夠大，避免由于redo log過小，導(dǎo)致頻繁的臟頁刷磁盤

• innodb_flush_log_at_trx_commit

當(dāng)對數(shù)據(jù)的安全性要求不是那么高的時(shí)候，可以考慮將此參數(shù)設(shè)為0或者2，減少刷磁盤頻率

表設(shè)計(jì)層面

• 對于統(tǒng)計(jì)和分析類等對實(shí)時(shí)性要求不高的需求（OLAP），設(shè)計(jì)中間表，避免直接查大量的raw data
• 創(chuàng)建合理的冗余字段，以減少連表查詢
• 表中不經(jīng)常使用的字段，或者存儲了過多字段，考慮拆表
• 每張表都要有個(gè)主鍵，且主鍵最好是自增的int類型

SQL語句層面

索引優(yōu)化

1. 為經(jīng)常出現(xiàn)在where條件中的字段，需要排序的字段創(chuàng)建合適的索引（當(dāng)讀多寫少時(shí)，可以考慮創(chuàng)建索引）
2. 當(dāng)需要對多個(gè)列建索引時(shí)，優(yōu)先考慮組合索引，而不是多個(gè)單列索引，并且合理的組織組合索引的順序，將篩選粒度大的列，放到組合索引的最左
3. 盡量使用覆蓋索引，而不要使用SELECT * ，可避免回表查詢

LIMIT優(yōu)化

1. 若預(yù)計(jì)查詢結(jié)果只有1條，使用LIMIT 1可以提前終止全表掃描
2. 子查詢優(yōu)化

當(dāng)使用LIMIT進(jìn)行分頁時(shí)，頁碼過大時(shí)，LIMIT的偏移量會很大，此時(shí)會導(dǎo)致MySQL掃描大量不需要的行，然后再丟棄，性能很差。

比如 LIMIT 10000,20 ，會先掃描前10000行，然后丟棄，最后取10000后的20行。

此時(shí)可以使用子查詢來做優(yōu)化

-- 原SQL
select * from product limit 10000,20;
-- 優(yōu)化后的SQL
select * from product where id >(select id from product order by id limit 10000,1) limit 20;
-- 由于子查詢使用了id主鍵索引，且查詢是覆蓋索引，可以很快的定位到10000的位置
-- 當(dāng)單表查詢，且主鍵已經(jīng)是排序好的，可以直接簡寫如下
select * from product where id > 10000 limit 20;

其他優(yōu)化

1. 統(tǒng)計(jì)數(shù)量時(shí)，盡量用count(1)，或count(列)，而不要用count(*)
2. 兩張表進(jìn)行關(guān)聯(lián)時(shí)，關(guān)聯(lián)字段最好都建立索引，且最好字段類型一致
3. where 條件中不使用not in (可使用not exists)
4. 合理使用慢查詢?nèi)罩?，explain查看執(zhí)行計(jì)劃，show profile 查看SQL執(zhí)行時(shí)的資源使用情況

到此這篇關(guān)于淺談MySQL的性能優(yōu)化的文章就介紹到這了,更多相關(guān)MySQL性能優(yōu)化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論