前段時(shí)候針對(duì)開發(fā)做的SQL語句寫法方面注意點(diǎn)的培訓(xùn)，

特意總結(jié)了一下，也共享一下。

書寫SQL需要注意的若干問題(MySQL版)

一、基本問題

1，在系統(tǒng)中運(yùn)行的SQL查詢，先考慮一下能不能在Slave上檢索，目前各個(gè)項(xiàng)目中Master上的不可避免的查詢量是其他所有的Slave總和還多。

但也不是一味的都是在Slave上查詢。

系統(tǒng)上出過一次查詢數(shù)據(jù)的情況：在一個(gè)前后順序執(zhí)行的邏輯代碼中，先更新Master的數(shù)據(jù)，再在Slave上查更新后的數(shù)據(jù)，這樣的操作很多時(shí)候因服務(wù)器和網(wǎng)絡(luò)環(huán)境而出現(xiàn)查詢結(jié)果不一致的情況。這樣的就不能在Slave上查詢了。

2，盡量不要輸出沒有用的列，也不要輸出已經(jīng)明確的列，增加了無用的數(shù)據(jù)傳輸量也是影響性能的。

3，盡量在每個(gè)查詢中返回自己需要的那些行，無關(guān)的不要返回。對(duì)簡單查詢是這樣，對(duì)復(fù)雜的包含很多子查詢中的每個(gè)子查詢更是這樣，盡量讓每個(gè)子查詢的結(jié)果集保留到最小再進(jìn)行關(guān)聯(lián)，避免出現(xiàn)先關(guān)聯(lián)后再取Distinct這樣的操作。

4，盡量不要在程序里面有Select *這樣的寫法，以后表字段的順序變動(dòng)都可能造成程序的問題。

5，對(duì)多表之間的連接必須用索引來作為連接列，否則這樣的查詢就是一個(gè)全表掃描，兩邊的關(guān)聯(lián)字段一定要類型一致，避免強(qiáng)制轉(zhuǎn)換。

mysql> explain select count(*) From JHF_ALIVE_EXECUTION E , JHF_ALIVE_CONTRACT C where C.Trade_ID=E.Trade_ID ;

+----+-------------+-------+------+-------------------+-------------------+---------+--------------------+------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+-------+------+-------------------+-------------------+---------+--------------------+------+-------------+

| 1 | SIMPLE | E | ALL | NULL | NULL | NULL | NULL | 866 | |

| 1 | SIMPLE | C | ref | ALIVE_CONTRACT_02 | ALIVE_CONTRACT_02 | 42 | CFDMAIN.E.TRADE_ID | 1 | Using index |

+----+-------------+-------+------+-------------------+-------------------+---------+--------------------+------+-------------+

2 rows in set (0.00 sec)

6，不要在Where字句中對(duì)列使用函數(shù)，那樣會(huì)導(dǎo)致索引失效，

mysql> show index from JHF_ALIVE_CONTRACT ;

+--------------------+------------+-------------------+--------------+-------------+-----------+-------------+-+------------

| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | | Index_type

+--------------------+------------+-------------------+--------------+-------------+-----------+-------------+-+------------

| JHF_ALIVE_CONTRACT | 0 | PRIMARY | 1 | CONTRACT_ID | A | 157 | | BTREE

| JHF_ALIVE_CONTRACT | 1 | ALIVE_CONTRACT_01 | 1 | ORDER_ID | A | 157 | | BTREE

| JHF_ALIVE_CONTRACT | 1 | ALIVE_CONTRACT_02 | 1 | TRADE_ID | A | 157 | | BTREE

| JHF_ALIVE_CONTRACT | 1 | ALIVE_CONTRACT_03 | 1 | CUSTOMER_ID | A | 19 | | BTREE

+--------------------+------------+-------------------+--------------+-------------+-----------+-------------+-+------------

4 rows in set (0.00 sec)

mysql>

mysql> explain select * From JHF_ALIVE_CONTRACT where Order_ID='20090930CONT00002005' ;

+----+-------------+--------------------+------+-------------------+-------------------+---------+-------+------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+--------------------+------+-------------------+-------------------+---------+-------+------+-------------+

| 1 | SIMPLE | JHF_ALIVE_CONTRACT | ref | ALIVE_CONTRACT_01 | ALIVE_CONTRACT_01 | 82 | const | 1 | Using where |

+----+-------------+--------------------+------+-------------------+-------------------+---------+-------+------+-------------+

1 row in set (0.00 sec)

主鍵檢索，最快的那種了。

mysql> explain select * From JHF_ALIVE_CONTRACT where substr(Order_ID,1,17) ='20090930ORD000115' ;

+----+-------------+--------------------+------+---------------+------+---------+------+------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+--------------------+------+---------------+------+---------+------+------+-------------+

| 1 | SIMPLE | JHF_ALIVE_CONTRACT | ALL | NULL | NULL | NULL | NULL | 94 | Using where |

+----+-------------+--------------------+------+---------------+------+---------+------+------+-------------+

1 row in set (0.00 sec)

什么索引都沒用上，全表掃描。

mysql> explain select * From JHF_ALIVE_CONTRACT where Order_ID like '20090930ORD000115%' ;

+----+-------------+--------------------+-------+-------------------+-------------------+---------+------+------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+--------------------+-------+-------------------+-------------------+---------+------+------+-------------+

| 1 | SIMPLE | JHF_ALIVE_CONTRACT | range | ALIVE_CONTRACT_01 | ALIVE_CONTRACT_01 | 82 | NULL | 6 | Using where |

+----+-------------+--------------------+-------+-------------------+-------------------+---------+------+------+-------------+

1 row in set (0.00 sec)

like 也能發(fā)揮索引的效果。

7，使用like語句時(shí)，對(duì) “C%”是能利用索引的，但對(duì) “%C”是無效的。而且在前面這個(gè)固定字符串越多時(shí)效率越好，也就盡量多匹配。

見上例。

8，Not in是個(gè)危險(xiǎn)的用法，在程序中慎用，必要時(shí)可以用left outer

join來改寫。

9，少用點(diǎn)or，它很可能會(huì)使一個(gè)查詢索引失效，必要時(shí)可以用union all或者union來替代。

10，注意一下 Union all與union的區(qū)別。前者是兩個(gè)結(jié)果集的不會(huì)經(jīng)過任何處理進(jìn)行相加，而后者是要經(jīng)過合并以后的內(nèi)容。

對(duì)兩個(gè)毫不相關(guān)的集合合并時(shí)，盡量用UNION ALL，避免不必要的排序浪費(fèi)系統(tǒng)資源。

11，在大表上不做Group by操作，如果需要的話，可以用大表的總結(jié)表。

對(duì)一些避免不了的實(shí)時(shí)檢索，可以考慮用索引覆蓋的方式來對(duì)所用到的字段全部建立索引的方式來加快查詢速度。

12，對(duì)Group by ,distinct出來的結(jié)果已經(jīng)是有序的了，不需要再排序，盡量使用已經(jīng)排好序的數(shù)據(jù)，免得再排序浪費(fèi)資源，如果要排序，不要在Order by里面的使用表達(dá)式。

13，在java中盡量使用prepareStatement來替代Statement，一個(gè)SQL提交給MYSQL后經(jīng)歷詞義檢查、語義檢查、對(duì)象檢查、獲取存取路徑、形成最終執(zhí)行計(jì)劃、生成執(zhí)行代碼，但是如果是兩個(gè)一樣的SQL(一模一樣，多個(gè)空格都不行)這個(gè)過程就全部省了，使用綁定變量(有的地方可能稱主機(jī)變量，就是用？來替代值，然后再設(shè)置這個(gè)值)能達(dá)到一模一樣的效果，DBMS在算存取路徑的時(shí)候會(huì)估算一個(gè)值來替代，這樣能達(dá)到一個(gè)很好的效果。(如果不注意這一點(diǎn)，那么你的系統(tǒng)離崩潰就不遠(yuǎn)了，這點(diǎn)對(duì)程序員特別重要！！)但是也不是所有的情況都是這樣，對(duì)一個(gè)SQL“長時(shí)間固定不變的環(huán)境中”，那么每次執(zhí)行都是相同的SQL，這時(shí)靜態(tài)變量和綁定變量方式唯一的差別是獲取存取路徑方式的不同，綁定方式是估算，而寫成變量的方式是精確的路徑。實(shí)際中到底使用哪種？1)一般都按照綁定變量來寫。２)如果在設(shè)計(jì)的時(shí)候就能明確該句在使用執(zhí)行的環(huán)境，再換成靜態(tài)方式。

其實(shí) 都用綁定變量這種方式來寫，沒有什么壞處！

14，不要輕易利用MySQL的自動(dòng)類型轉(zhuǎn)換，看起來挺好使，但用起來危害非常大，因?yàn)樗芸赡軙?huì)讓看起來好端端的索引失效。

15，在數(shù)據(jù)庫上經(jīng)常在允許為NULL的字段上建立了索引，注意想查詢此字段上的is null或者is not null可能會(huì)使索引失效。

16，避免出現(xiàn) 跨庫操作這樣的SQL語句，例如：

Use MAIN ;

Insert into

JHF_ORDER select * From HISTORY.JHF_ORDER where id=’33’ ;

這樣的SQL在Master上能正常運(yùn)行的，但是因?yàn)镾lave的結(jié)構(gòu)各種各樣，對(duì)不存在HISTORY庫的SLAVE，這個(gè)SQL就會(huì)導(dǎo)致同步中斷，而一般需要人工干預(yù)才能繼續(xù)同步。

17，現(xiàn)有的數(shù)據(jù)庫結(jié)構(gòu)中各個(gè)Slave所忽略的表是不一樣的，對(duì)類似這樣的SQL:

Insert into TA select * From TB where

Code=’ABC’，在Master上執(zhí)行沒問題，但如果某個(gè)Slave忽略了TB表的同步，那么在這個(gè)Slave上的TA表的數(shù)據(jù)將也不會(huì)正常，在程序中避免出現(xiàn)一個(gè)Insert/Update/Delete中關(guān)聯(lián)多個(gè)表的情況，很容易因?yàn)镾lave同步部分表的原因而導(dǎo)致數(shù)據(jù)不一致。

18，對(duì)一個(gè)大的結(jié)果結(jié)進(jìn)行排序是個(gè)非常費(fèi)系統(tǒng)資源的操作。但也不能因?yàn)檫@點(diǎn)而不排序。對(duì)一個(gè)未使用任何排序操作的結(jié)果集的默認(rèn)順序是按照主鍵的順序進(jìn)行默認(rèn)排序的，沒有主鍵或者自增長主鍵的是按照記錄的插入先后順序進(jìn)行輸出，某些時(shí)候是滿足需求的，但是這樣的排序是不可靠的，在數(shù)據(jù)庫進(jìn)行過數(shù)據(jù)重整和索引重建或者后插入的數(shù)據(jù)的主鍵值不是按照一個(gè)固定的順序來的時(shí)候，就很可能打亂原始的順序而出現(xiàn)不用時(shí)間的不用的檢索結(jié)果。

19，關(guān)于批處理的SQL，編寫時(shí)要考慮SQL更新的速率和數(shù)據(jù)量的大小。 這主要是考慮到我們現(xiàn)在所使用的M/S同步機(jī)制。更新速度過快可能使數(shù)據(jù)庫壓力增大，并且出現(xiàn)數(shù)據(jù)庫同步延遲。更新太慢沒有效率。總之，一定要通過測試綜合進(jìn)行考慮，找到平衡點(diǎn)以達(dá)到最好的效果。

20，不要在正式系統(tǒng)里面運(yùn)行沒有試過的SQL語句，即使是Select語句。

A)、不恰當(dāng)關(guān)聯(lián)，造成笛卡兒結(jié)果集非常龐大，讓系統(tǒng)忙死在寫入臨時(shí)文件的操作中，這個(gè)會(huì)發(fā)生在兩個(gè)大表間關(guān)聯(lián)的時(shí)候，關(guān)聯(lián)的條件是多對(duì)多的關(guān)系，造成結(jié)果集非常龐大，一時(shí)半會(huì)都執(zhí)行不完，這時(shí)不要慌，關(guān)閉終端是解決不了問題的，進(jìn)入MySQL或者在客戶端終端，按照以下命令：

show processlist ;--à找到State處于Copy to tmp ..這樣的SQL對(duì)應(yīng)的Id號(hào)

kill XXXX ;

才算真正控制了這個(gè)SQL的執(zhí)行。

B)、要清楚“的確”存在能把數(shù)據(jù)庫整死的純查詢SQL，看起來不起眼，但威力很大，有些是因?yàn)镸ySQL本身的BUG，例如：

我遇到的兩個(gè)：

SELECT COUNT(*) FROM (

SELECT Customer_ID FROM JHF_DEPOSIT

UNION ALL

SELECT Customer_ID

FROM JHF_WITHDRAWAL ORDER BY CustomerID

) A ；

(在MySQL 5.0.33中)

因?yàn)樵谧硬樵冎蠴rder by了一個(gè)不存在的字段，不是報(bào)語句的錯(cuò)誤，而是直接將MySQL數(shù)據(jù)庫重啟了。

select A.CC,A.bid,A.ask,A.rateTime,

(select ratetime From wxlTemp B where B.CC=A.CC and B.bid <> A.bid and B.ask <> A.bid and B.ratetime > A.ratetime Order by ratetime limit 1) as LastTime

From wxlTemp A

where A.RateTime

Order by A.CC,A.ratetime

這個(gè)SQL也會(huì)導(dǎo)致MySQL數(shù)據(jù)庫重啟。

二、有關(guān)分頁相關(guān)的：

1.分頁查詢時(shí)，通常一頁記錄為幾十條，每次只需要查詢當(dāng)頁的記錄。當(dāng)有復(fù)雜的查詢sql時(shí)，我們要將sql分解，提煉出必要的影響結(jié)果集的sql，用于分頁查詢，這個(gè)sql只包含一部分主要的表；在分頁查詢執(zhí)行后，再查詢這一頁記錄對(duì)應(yīng)的其它表的記錄。因?yàn)橛涗洈?shù)只有一頁了，那么其它表的查詢的性能將會(huì)很好，這部分是需要在java程序中處理的。2.如果僅僅統(tǒng)計(jì)表記錄數(shù)量，那么就不要使用order by。

3.對(duì)于分頁查詢，通常需要顯示符合條件的總記錄數(shù)、頁碼、當(dāng)頁條數(shù)。這樣就需要執(zhí)行兩次數(shù)據(jù)庫查詢，一次是計(jì)算總記錄數(shù)，一次是檢索當(dāng)頁全部記錄。對(duì)于復(fù)雜sql，建議將這兩次查詢使用的sql分開。這么做的原因是，比如在FX項(xiàng)目中，分頁方法一般都是將sql直接進(jìn)行解析，根據(jù)from來拆分成統(tǒng)計(jì)記錄數(shù)和返回結(jié)果集的sql。對(duì)于返回當(dāng)頁記錄的sql來說，一些where條件和表關(guān)聯(lián)是必要的，因?yàn)榭赡芷渲幸恍┲皇菫榱嗽趕elect中包含部分表的字段；但是對(duì)于統(tǒng)計(jì)記錄數(shù)的sql來說，只需要那些影響結(jié)果記錄數(shù)的必要條件和關(guān)聯(lián)的表即可。比如：select * from tableA inner join tableB on(tableA.c1=tableB.c1)

left outer join tableC on (tableC.c2=tableA.c2)

tableA和tableB的記錄是一對(duì)一的關(guān)系通用分頁方法會(huì)將統(tǒng)計(jì)記錄數(shù)的sql分解為類似下面這樣：select count(*) from tableA inner join tableB on(tableA.c1=tableB.c1)

left outer join tableC on (tableC.c2=tableA.c2)但是tableB是不需要關(guān)聯(lián)的，因?yàn)椴挥绊懹涗洈?shù)。那么我們單獨(dú)寫一個(gè)統(tǒng)計(jì)記錄數(shù)的sql：select count(*) from tableA inner join tableB on(tableA.c1=tableB.c1)

二、如何避免出現(xiàn)鎖沖突及死鎖

1，對(duì)一個(gè)象Fx這樣的分布系統(tǒng)，同時(shí)操作注文約定邏輯幾個(gè)表這樣的模塊有很多，一定要在一個(gè)事務(wù)中確保所有的模塊對(duì)操作相同的幾個(gè)表的順序都一致，避免多個(gè)進(jìn)程間對(duì)表產(chǎn)生死鎖。

2，對(duì)由不同的模塊更新相同的一批記錄也可能存在記錄間出現(xiàn)死鎖的情況，所以對(duì)事務(wù)操作比較密集的地方，盡量對(duì)操作的記錄進(jìn)行按照一個(gè)統(tǒng)一的順序進(jìn)行，比如升序或者降序。

3，對(duì)更新比較頻繁的表一定要使用INNODB的表而不要使用MyISAM，因?yàn)镸yISAM的每一次更新都將是鎖住整個(gè)的表，而大大降低了更新的并發(fā)性能。

4，在現(xiàn)有的系統(tǒng)中，我們使用的事務(wù)隔離級(jí)別是：READ_COMMITED，在一個(gè)事務(wù)中它會(huì)對(duì)更新的記錄進(jìn)行加鎖，這里的“更新的記錄”比較微妙，它鎖定的范圍是和更新的語句的where條件密切相關(guān)，想要達(dá)到行鎖的效果，Update語句的條件一定要加上索引，最好是主鍵或者唯一鍵，

因?yàn)檫@樣的鎖會(huì)很本分，確定的記錄比較明確。

5，要盡量保證事務(wù)不要過大，小事務(wù)發(fā)生鎖沖突的幾率較小。

三、如何優(yōu)化

對(duì)每個(gè)SQL語句在執(zhí)行之前，做一下EXPLAIN檢查，查看是否都使用了索引，是否使用了有效的索引，看是否掃描了很多行數(shù)據(jù)。

http://dev.mysql.com/doc/refman/5.1/zh/optimization.html#explain

對(duì)索引的創(chuàng)建也要把握精而不濫的原則，對(duì)特殊的表，可以考慮只在Slave上建立。

1，索引的建立對(duì)提高檢索能力很有用，但是數(shù)據(jù)庫維護(hù)它很費(fèi)資源。

2，索引只使用開頭的部分。

key (a,b) .... where b=5

will not use index.

3,建立一個(gè)對(duì)檢索有用的索引，

index on gender is not a

good idea，例如在性別上建索引不是很有用。

4，對(duì)唯一建的索引，加上UNIQUE。

5，避免出現(xiàn)無用的索引。(從來沒被調(diào)用)

6，索引的順序很重要。

7，不要在同列(s)上建立兩個(gè)索引。

8，充分用別的組合索引的前面部分，是個(gè)相當(dāng)好的主意。

9，可以只對(duì)一個(gè)字段的前幾個(gè)字段建立索引。

10，短一些的索引比較好，整數(shù)最好。(Short keys are better, Integer best)

11,有規(guī)律的值 比

沒有規(guī)律的隨機(jī)的數(shù)要好。

– access locality is much

better

– auto_increment better than

uuid()

12，記得經(jīng)常 優(yōu)化表，這樣能壓縮和排序索引項(xiàng)。

OPTIMIZE TABLE compact and

sort indexes

13，分析表，能更新表的統(tǒng)計(jì)信息，這樣對(duì)檢索很有好處。

ANALYZE TABLE - update

statistics

14.利用索引并不一定能提高性能，如果返回結(jié)果集數(shù)量很大，甚至接近全表記錄數(shù)時(shí)，那么全表掃描的效率更高。通過索引再定位到物理記錄，這個(gè)過程會(huì)比較耗費(fèi)時(shí)間。

附錄：

MySQL中通過show status對(duì)得到的值進(jìn)行計(jì)算得到后的值，大家可以參考。

1,連接失敗的監(jiān)控.

■監(jiān)視點(diǎn):連接失敗的百分比。

■公式: Aborted_connects*100 / Connections

■正常范圍:小于10%.

■含義:應(yīng)用程序連接服務(wù)器失敗的比例,一般原因有:未授權(quán)訪問數(shù)據(jù)庫/密碼錯(cuò)誤/連接超時(shí)

等.

2,最大情況下的連接使用百分比.

■監(jiān)視點(diǎn):最大情況下的連接使用百分比。

■公式: Max_used_connections /

max_connections

■正常范圍:小于75%.

■含義:從開機(jī)到現(xiàn)在的最大連接情況,表示的是這段時(shí)間的峰值,對(duì)繁忙的系統(tǒng)這個(gè)很有參考意義.

3,MyISAM索引緩存命中率

■監(jiān)視點(diǎn): key_buffer_size的設(shè)置是否適當(dāng)。

■公式: 1-(Key_reads / Key_read_requests)

■正常范圍: 95%以上.

■含義:增大key_buffer_size并且監(jiān)控緩存利用率。當(dāng)命中率到達(dá)了一個(gè)可接收的水平，保存key_buffer_size值到MySQL配置文件中。

需要MySQL運(yùn)行一個(gè)合理時(shí)間后，查看命中率才有意義。

4,InnoDB緩存命中率

■監(jiān)視點(diǎn): innodb_buffer_pool_size的設(shè)置是否適當(dāng)。

■公式: 100* (1 - (Innodb_buffer_pool_reads /

Innodb_buffer_pool_read_requests))

■正常范圍: 95%以上.

■含義:數(shù)據(jù)和索引在緩存中讀取的比率。從內(nèi)存讀取要比磁盤讀取塊很多，因此要盡量保持物理I/O最少。

當(dāng)使用InnoDB大多數(shù)的訪問應(yīng)該在內(nèi)存中，因此這個(gè)值要很高。

5,InnoDB緩存寫入等待率

■監(jiān)視點(diǎn): innodb_buffer_pool_size的設(shè)置是否適當(dāng)。

■公式: 100* (Innodb_buffer_pool_wait_free /

Innodb_buffer_pool_write_requests)

■正常范圍: 1%以下.

■含義:為了最佳性能，InnoDB不應(yīng)等待頁寫入到InnoDB緩沖池中。

6,InnoDB回滾日志寫入的等待比率

■監(jiān)視點(diǎn): innodb_log_buffer_size的設(shè)置是否適當(dāng)。

■公式: 100* (Innodb_log_waits /

Innodb_log_writes)

■正常范圍: 1%以下.

■含義:為了最佳性能，InnoDB不應(yīng)等待SQL操作寫入到日志。

7,線程緩存大小設(shè)定值是否合適.

■監(jiān)視點(diǎn): thread_cache_size的設(shè)置是否適當(dāng)。

■公式: (1-Threads_created/Connections ) *100%

■正常范圍: 95%以上.

■含義:每個(gè)MySQL連接都運(yùn)行在它特有的線程中。線程建立比較耗時(shí)，因此每個(gè)連接關(guān)閉的時(shí)候不是殺死線程。

服務(wù)起能保存線程在線程緩存中稍后為新的連接使用,線程緩存命中率。如果這個(gè)值太小那么就要考慮增加線程緩存的大小。

8,表打開操作是否頻繁..

■監(jiān)視點(diǎn): table_cache的設(shè)置是否適當(dāng)。

■公式: Opened_tables的值,服務(wù)器運(yùn)行一段時(shí)間后的值,要是一直在增長,那么就是有問題.

■正常范圍: 0 .

■含義: MySQL每次訪問表就把它放在表緩存中。如何系統(tǒng)訪問很多表那么在緩存中會(huì)更快一些。

Opened_tables就是沒有通過表緩存中打開表的數(shù)量,如果這個(gè)數(shù)值高或者增長的很快那么就需要增加table_cache的值。

9,查詢緩存碎片情況.

■監(jiān)視點(diǎn):查詢緩存中各個(gè)使用塊的情況,如果單個(gè)塊中有空閑的,那么此項(xiàng)監(jiān)控就高.

■公式: 100 * Qcache_free_blocks /

Qcache_total_blocks

■正常范圍:低于70% .

■含義:如果你有很多小的查詢結(jié)果,這個(gè)值可能會(huì)很高,請考慮下面的選項(xiàng)：1、減少query_cache_min_res_unit值

2、執(zhí)行FLUSH QUERY CACHE對(duì)查詢緩存進(jìn)行碎片整理。

10,查詢修剪(從緩存中刪除，因?yàn)閮?nèi)存不夠)與插入查詢緩存的比率。

■監(jiān)視點(diǎn):從查詢緩存中刪除的總體量和插入的的比例.

■公式: Qcache_lowmem_prunes / Qcache_inserts

■正常范圍:

■含義:放入緩存的數(shù)量

與 被迫從緩存中擠出去的數(shù)量的比值.

被擠的情況有某個(gè)查詢結(jié)果集太久沒有復(fù)用,來了新的結(jié)果集,緩存中沒有空了.

也可能是,緩存的結(jié)果集涉及到的表更新比較頻繁,在下次利用的時(shí)候,

發(fā)現(xiàn)已經(jīng)是臟的數(shù)據(jù)了,于是就擠出來,在重新裝載.

這個(gè)值能反映出

查詢緩存是不是一個(gè)穩(wěn)定的查詢緩存,有沒有必要使用查詢緩存.

11,查詢緩存命中率(從緩存中刪除，因?yàn)閮?nèi)存不夠)與插入查詢緩存的比率。

■監(jiān)視點(diǎn):一個(gè)查詢的結(jié)果能被復(fù)用的比例.

■公式: Qcache_hits / (Qcache_inserts +

Qcache_hits)

■正常范圍:

■含義:查詢緩存應(yīng)該為此一個(gè)高的命中率。高命中率表示其他的連接可以使用查詢緩存中結(jié)果。

低命中率說明沒有足夠的內(nèi)存分配給它，或者查詢沒有在服務(wù)器上再三的執(zhí)行。

12,

sort_buffer_size的大小是否合適.

■監(jiān)視點(diǎn):排序算法已經(jīng)執(zhí)行的合并的數(shù)量。如果這個(gè)變量值較大，應(yīng)考慮增加sort_buffer_size系統(tǒng)變量的值。

■公式: Sort_merge_passes

■正常范圍:

■含義:

13,

read_rnd_buffer_size的大小是否合適.

■監(jiān)視點(diǎn):暫時(shí)無

■公式:

■正常范圍:

■含義:當(dāng)排序后按排序后的順序讀取行時(shí)，則通過該緩沖區(qū)讀取行，避免搜索硬盤。

將該變量設(shè)置為較大的值可以大大改進(jìn)ORDER BY的性能。但是，這是為每個(gè)客戶端分配的緩沖區(qū)，

因此你不應(yīng)將全局變量設(shè)置為較大的值。相反，只為需要運(yùn)行大查詢的客戶端更改會(huì)話變量。

14, read_rnd_buffer_size的大小是否合適.

■監(jiān)視點(diǎn):表鎖的次數(shù).

■公式:Table_locks_waited / (Table_locks_waited + Table_locks_immediate)

■正常范圍:10%以內(nèi)

■含義:對(duì)MyISAM表,所表是發(fā)生在讀和寫他們兩兩之間的,是并發(fā)性很低的,所以如果這個(gè)值高的話,

需要拷考慮進(jìn)行表類型的更改.

15, Percentage of full table scans .

■監(jiān)視點(diǎn):全表掃描的比率.

■公式:(Handler_read_rnd_next + Handler_read_rnd) / (Handler_read_rnd_next +

Handler_read_rnd + Handler_read_first + Handler_read_next + Handler_read_key +

Handler_read_prev)

■正常范圍:20%以內(nèi)

■含義:要盡力保持很小的值。設(shè)法隔離沒使用索引的查詢。使用慢查詢?nèi)罩居涗浤男┻\(yùn)行時(shí)間較長的查詢。

16, Select_full_join .

■監(jiān)視點(diǎn):沒有使用索引的聯(lián)接的數(shù)量.

■公式:Select_full_join

■正常范圍:20%以內(nèi)

■含義:沒有使用索引的聯(lián)接的數(shù)量。如果該值不為0,你應(yīng)仔細(xì)檢查表的索引。。

17, binlog_cache_size的大小是否合適.

■監(jiān)視點(diǎn):表鎖的次數(shù).

■公式:Binlog_cache_disk_use / Binlog_cache_use

■正常范圍:10%以內(nèi)

■含義:增加這個(gè)值并且監(jiān)控這個(gè)值。當(dāng)命中率達(dá)到可以接受的水平將binlog_cache_size參數(shù)添加到MySQL配置文件中。

18, tmp_table_size,max_heap_table_size的大小是否合適.

■監(jiān)視點(diǎn):使用臨時(shí)表的次數(shù).

■公式:Created_tmp_disk_tables / Created_tmp_tables

■正常范圍:50%以內(nèi)

■含義:如果這個(gè)值太高了那么就要考慮增加tmp_table_size和max_heap_table_size大小。

臨時(shí)表的TEXT or BLOBS字段要保存在磁盤上，因此設(shè)法改變TEXT或者BLOBS字段類型。

(完)

總結(jié)

以上是生活随笔為你收集整理的mysql sql wait 写法_有关SQL语句写法注意的那些事情（原创整理）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。