mysql sql wait 写法_有关SQL语句写法注意的那些事情（原创整理）
前段時(shí)候針對(duì)開(kāi)發(fā)做的SQL語(yǔ)句寫(xiě)法方面注意點(diǎn)的培訓(xùn)，
特意總結(jié)了一下，也共享一下。
書(shū)寫(xiě)SQL需要注意的若干問(wèn)題(MySQL版)
一、基本問(wèn)題
1，在系統(tǒng)中運(yùn)行的SQL查詢(xún)，先考慮一下能不能在Slave上檢索，目前各個(gè)項(xiàng)目中Master上的不可避免的查詢(xún)量是其他所有的Slave總和還多。
但也不是一味的都是在Slave上查詢(xún)。
系統(tǒng)上出過(guò)一次查詢(xún)數(shù)據(jù)的情況：在一個(gè)前后順序執(zhí)行的邏輯代碼中，先更新Master的數(shù)據(jù)，再在Slave上查更新后的數(shù)據(jù)，這樣的操作很多時(shí)候因服務(wù)器和網(wǎng)絡(luò)環(huán)境而出現(xiàn)查詢(xún)結(jié)果不一致的情況。這樣的就不能在Slave上查詢(xún)了。
2，盡量不要輸出沒(méi)有用的列，也不要輸出已經(jīng)明確的列，增加了無(wú)用的數(shù)據(jù)傳輸量也是影響性能的。
3，盡量在每個(gè)查詢(xún)中返回自己需要的那些行，無(wú)關(guān)的不要返回。對(duì)簡(jiǎn)單查詢(xún)是這樣，對(duì)復(fù)雜的包含很多子查詢(xún)中的每個(gè)子查詢(xún)更是這樣，盡量讓每個(gè)子查詢(xún)的結(jié)果集保留到最小再進(jìn)行關(guān)聯(lián)，避免出現(xiàn)先關(guān)聯(lián)后再取Distinct這樣的操作。
4，盡量不要在程序里面有Select *這樣的寫(xiě)法，以后表字段的順序變動(dòng)都可能造成程序的問(wèn)題。
5，對(duì)多表之間的連接必須用索引來(lái)作為連接列，否則這樣的查詢(xún)就是一個(gè)全表掃描，兩邊的關(guān)聯(lián)字段一定要類(lèi)型一致，避免強(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)
什么索引都沒(méi)用上，全表掃描。
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語(yǔ)句時(shí)，對(duì) “C%”是能利用索引的，但對(duì) “%C”是無(wú)效的。而且在前面這個(gè)固定字符串越多時(shí)效率越好，也就盡量多匹配。
見(jiàn)上例。
8，Not in是個(gè)危險(xiǎn)的用法，在程序中慎用，必要時(shí)可以用left outer
join來(lái)改寫(xiě)。
9，少用點(diǎn)or，它很可能會(huì)使一個(gè)查詢(xún)索引失效，必要時(shí)可以用union all或者union來(lái)替代。
10，注意一下 Union all與union的區(qū)別。前者是兩個(gè)結(jié)果集的不會(huì)經(jīng)過(guò)任何處理進(jìn)行相加，而后者是要經(jīng)過(guò)合并以后的內(nèi)容。
對(duì)兩個(gè)毫不相關(guān)的集合合并時(shí)，盡量用UNION ALL，避免不必要的排序浪費(fèi)系統(tǒng)資源。
11，在大表上不做Group by操作，如果需要的話(huà)，可以用大表的總結(jié)表。
對(duì)一些避免不了的實(shí)時(shí)檢索，可以考慮用索引覆蓋的方式來(lái)對(duì)所用到的字段全部建立索引的方式來(lái)加快查詢(xún)速度。
12，對(duì)Group by ,distinct出來(lái)的結(jié)果已經(jīng)是有序的了，不需要再排序，盡量使用已經(jīng)排好序的數(shù)據(jù)，免得再排序浪費(fèi)資源，如果要排序，不要在Order by里面的使用表達(dá)式。
13，在java中盡量使用prepareStatement來(lái)替代Statement，一個(gè)SQL提交給MYSQL后經(jīng)歷詞義檢查、語(yǔ)義檢查、對(duì)象檢查、獲取存取路徑、形成最終執(zhí)行計(jì)劃、生成執(zhí)行代碼，但是如果是兩個(gè)一樣的SQL(一模一樣，多個(gè)空格都不行)這個(gè)過(guò)程就全部省了，使用綁定變量(有的地方可能稱(chēng)主機(jī)變量，就是用？來(lái)替代值，然后再設(shè)置這個(gè)值)能達(dá)到一模一樣的效果，DBMS在算存取路徑的時(shí)候會(huì)估算一個(gè)值來(lái)替代，這樣能達(dá)到一個(gè)很好的效果。(如果不注意這一點(diǎn)，那么你的系統(tǒng)離崩潰就不遠(yuǎn)了，這點(diǎn)對(duì)程序員特別重要！！)但是也不是所有的情況都是這樣，對(duì)一個(gè)SQL“長(zhǎng)時(shí)間固定不變的環(huán)境中”，那么每次執(zhí)行都是相同的SQL，這時(shí)靜態(tài)變量和綁定變量方式唯一的差別是獲取存取路徑方式的不同，綁定方式是估算，而寫(xiě)成變量的方式是精確的路徑。實(shí)際中到底使用哪種？1)一般都按照綁定變量來(lái)寫(xiě)。２)如果在設(shè)計(jì)的時(shí)候就能明確該句在使用執(zhí)行的環(huán)境，再換成靜態(tài)方式。
其實(shí) 都用綁定變量這種方式來(lái)寫(xiě)，沒(méi)有什么壞處！
14，不要輕易利用MySQL的自動(dòng)類(lèi)型轉(zhuǎn)換，看起來(lái)挺好使，但用起來(lái)危害非常大，因?yàn)樗芸赡軙?huì)讓看起來(lái)好端端的索引失效。
15，在數(shù)據(jù)庫(kù)上經(jīng)常在允許為NULL的字段上建立了索引，注意想查詢(xún)此字段上的is null或者is not null可能會(huì)使索引失效。
16，避免出現(xiàn) 跨庫(kù)操作這樣的SQL語(yǔ)句，例如：
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庫(kù)的SLAVE，這個(gè)SQL就會(huì)導(dǎo)致同步中斷，而一般需要人工干預(yù)才能繼續(xù)同步。
17，現(xiàn)有的數(shù)據(jù)庫(kù)結(jié)構(gòu)中各個(gè)Slave所忽略的表是不一樣的，對(duì)類(lèi)似這樣的SQL:
Insert into TA select * From TB where
Code=’ABC’，在Master上執(zhí)行沒(méi)問(wèn)題，但如果某個(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)排序的，沒(méi)有主鍵或者自增長(zhǎng)主鍵的是按照記錄的插入先后順序進(jìn)行輸出，某些時(shí)候是滿(mǎn)足需求的，但是這樣的排序是不可靠的，在數(shù)據(jù)庫(kù)進(jìn)行過(guò)數(shù)據(jù)重整和索引重建或者后插入的數(shù)據(jù)的主鍵值不是按照一個(gè)固定的順序來(lái)的時(shí)候，就很可能打亂原始的順序而出現(xiàn)不用時(shí)間的不用的檢索結(jié)果。
19，關(guān)于批處理的SQL，編寫(xiě)時(shí)要考慮SQL更新的速率和數(shù)據(jù)量的大小。 這主要是考慮到我們現(xiàn)在所使用的M/S同步機(jī)制。更新速度過(guò)快可能使數(shù)據(jù)庫(kù)壓力增大，并且出現(xiàn)數(shù)據(jù)庫(kù)同步延遲。更新太慢沒(méi)有效率。總之，一定要通過(guò)測(cè)試綜合進(jìn)行考慮，找到平衡點(diǎn)以達(dá)到最好的效果。
20，不要在正式系統(tǒng)里面運(yùn)行沒(méi)有試過(guò)的SQL語(yǔ)句，即使是Select語(yǔ)句。
A)、不恰當(dāng)關(guān)聯(lián)，造成笛卡兒結(jié)果集非常龐大，讓系統(tǒng)忙死在寫(xiě)入臨時(shí)文件的操作中，這個(gè)會(huì)發(fā)生在兩個(gè)大表間關(guān)聯(lián)的時(shí)候，關(guān)聯(lián)的條件是多對(duì)多的關(guān)系，造成結(jié)果集非常龐大，一時(shí)半會(huì)都執(zhí)行不完，這時(shí)不要慌，關(guān)閉終端是解決不了問(wèn)題的，進(jìn)入MySQL或者在客戶(hù)端終端，按照以下命令：
show processlist ;--à找到State處于Copy to tmp ..這樣的SQL對(duì)應(yīng)的Id號(hào)
kill XXXX ;
才算真正控制了這個(gè)SQL的執(zhí)行。
B)、要清楚“的確”存在能把數(shù)據(jù)庫(kù)整死的純查詢(xún)SQL，看起來(lái)不起眼，但威力很大，有些是因?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)樵谧硬樵?xún)中Order by了一個(gè)不存在的字段，不是報(bào)語(yǔ)句的錯(cuò)誤，而是直接將MySQL數(shù)據(jù)庫(kù)重啟了。
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ù)庫(kù)重啟。
二、有關(guān)分頁(yè)相關(guān)的：
1.分頁(yè)查詢(xún)時(shí)，通常一頁(yè)記錄為幾十條，每次只需要查詢(xún)當(dāng)頁(yè)的記錄。當(dāng)有復(fù)雜的查詢(xún)sql時(shí)，我們要將sql分解，提煉出必要的影響結(jié)果集的sql，用于分頁(yè)查詢(xún)，這個(gè)sql只包含一部分主要的表；在分頁(yè)查詢(xún)執(zhí)行后，再查詢(xún)這一頁(yè)記錄對(duì)應(yīng)的其它表的記錄。因?yàn)橛涗洈?shù)只有一頁(yè)了，那么其它表的查詢(xún)的性能將會(huì)很好，這部分是需要在java程序中處理的。2.如果僅僅統(tǒng)計(jì)表記錄數(shù)量，那么就不要使用order by。
3.對(duì)于分頁(yè)查詢(xún)，通常需要顯示符合條件的總記錄數(shù)、頁(yè)碼、當(dāng)頁(yè)條數(shù)。這樣就需要執(zhí)行兩次數(shù)據(jù)庫(kù)查詢(xún)，一次是計(jì)算總記錄數(shù)，一次是檢索當(dāng)頁(yè)全部記錄。對(duì)于復(fù)雜sql，建議將這兩次查詢(xún)使用的sql分開(kāi)。這么做的原因是，比如在FX項(xiàng)目中，分頁(yè)方法一般都是將sql直接進(jìn)行解析，根據(jù)from來(lái)拆分成統(tǒng)計(jì)記錄數(shù)和返回結(jié)果集的sql。對(duì)于返回當(dāng)頁(yè)記錄的sql來(lái)說(shuō)，一些where條件和表關(guān)聯(lián)是必要的，因?yàn)榭赡芷渲幸恍┲皇菫榱嗽趕elect中包含部分表的字段；但是對(duì)于統(tǒng)計(jì)記錄數(shù)的sql來(lái)說(shuō)，只需要那些影響結(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)系通用分頁(yè)方法會(huì)將統(tǒng)計(jì)記錄數(shù)的sql分解為類(lèi)似下面這樣：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ú)寫(xiě)一個(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)行加鎖，這里的“更新的記錄”比較微妙，它鎖定的范圍是和更新的語(yǔ)句的where條件密切相關(guān)，想要達(dá)到行鎖的效果，Update語(yǔ)句的條件一定要加上索引，最好是主鍵或者唯一鍵，
因?yàn)檫@樣的鎖會(huì)很本分，確定的記錄比較明確。
5，要盡量保證事務(wù)不要過(guò)大，小事務(wù)發(fā)生鎖沖突的幾率較小。
三、如何優(yōu)化
對(duì)每個(gè)SQL語(yǔ)句在執(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ù)庫(kù)維護(hù)它很費(fèi)資源。
2，索引只使用開(kāi)頭的部分。
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)無(wú)用的索引。(從來(lái)沒(méi)被調(diào)用)
6，索引的順序很重要。
7，不要在同列(s)上建立兩個(gè)索引。
8，充分用別的組合索引的前面部分，是個(gè)相當(dāng)好的主意。
9，可以只對(duì)一個(gè)字段的前幾個(gè)字段建立索引。
10，短一些的索引比較好，整數(shù)最好。(Short keys are better, Integer best)
11,有規(guī)律的值 比
沒(méi)有規(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í)，那么全表掃描的效率更高。通過(guò)索引再定位到物理記錄，這個(gè)過(guò)程會(huì)比較耗費(fèi)時(shí)間。
附錄：
MySQL中通過(guò)show status對(duì)得到的值進(jìn)行計(jì)算得到后的值，大家可以參考。
1,連接失敗的監(jiān)控.
■監(jiān)視點(diǎn):連接失敗的百分比。
■公式: Aborted_connects*100 / Connections
■正常范圍:小于10%.
■含義:應(yīng)用程序連接服務(wù)器失敗的比例,一般原因有:未授權(quán)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)/密碼錯(cuò)誤/連接超時(shí)
等.
2,最大情況下的連接使用百分比.
■監(jiān)視點(diǎn):最大情況下的連接使用百分比。
■公式: Max_used_connections /
max_connections
■正常范圍:小于75%.
■含義:從開(kāi)機(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)存讀取要比磁盤(pán)讀取塊很多，因此要盡量保持物理I/O最少。
當(dāng)使用InnoDB大多數(shù)的訪(fǎng)問(wèn)應(yīng)該在內(nèi)存中，因此這個(gè)值要很高。
5,InnoDB緩存寫(xiě)入等待率
■監(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)等待頁(yè)寫(xiě)入到InnoDB緩沖池中。
6,InnoDB回滾日志寫(xiě)入的等待比率
■監(jiān)視點(diǎn): innodb_log_buffer_size的設(shè)置是否適當(dāng)。
■公式: 100* (Innodb_log_waits /
Innodb_log_writes)
■正常范圍: 1%以下.
■含義:為了最佳性能，InnoDB不應(yīng)等待SQL操作寫(xiě)入到日志。
7,線(xiàn)程緩存大小設(shè)定值是否合適.
■監(jiān)視點(diǎn): thread_cache_size的設(shè)置是否適當(dāng)。
■公式: (1-Threads_created/Connections ) *100%
■正常范圍: 95%以上.
■含義:每個(gè)MySQL連接都運(yùn)行在它特有的線(xiàn)程中。線(xiàn)程建立比較耗時(shí)，因此每個(gè)連接關(guān)閉的時(shí)候不是殺死線(xiàn)程。
服務(wù)起能保存線(xiàn)程在線(xiàn)程緩存中稍后為新的連接使用,線(xiàn)程緩存命中率。如果這個(gè)值太小那么就要考慮增加線(xiàn)程緩存的大小。
8,表打開(kāi)操作是否頻繁..
■監(jiān)視點(diǎn): table_cache的設(shè)置是否適當(dāng)。
■公式: Opened_tables的值,服務(wù)器運(yùn)行一段時(shí)間后的值,要是一直在增長(zhǎng),那么就是有問(wèn)題.
■正常范圍: 0 .
■含義: MySQL每次訪(fǎng)問(wèn)表就把它放在表緩存中。如何系統(tǒng)訪(fǎng)問(wèn)很多表那么在緩存中會(huì)更快一些。
Opened_tables就是沒(méi)有通過(guò)表緩存中打開(kāi)表的數(shù)量,如果這個(gè)數(shù)值高或者增長(zhǎng)的很快那么就需要增加table_cache的值。
9,查詢(xún)緩存碎片情況.
■監(jiān)視點(diǎn):查詢(xún)緩存中各個(gè)使用塊的情況,如果單個(gè)塊中有空閑的,那么此項(xiàng)監(jiān)控就高.
■公式: 100 * Qcache_free_blocks /
Qcache_total_blocks
■正常范圍:低于70% .
■含義:如果你有很多小的查詢(xún)結(jié)果,這個(gè)值可能會(huì)很高,請(qǐng)考慮下面的選項(xiàng)：1、減少query_cache_min_res_unit值
2、執(zhí)行FLUSH QUERY CACHE對(duì)查詢(xún)緩存進(jìn)行碎片整理。
10,查詢(xún)修剪(從緩存中刪除，因?yàn)閮?nèi)存不夠)與插入查詢(xún)緩存的比率。
■監(jiān)視點(diǎn):從查詢(xún)緩存中刪除的總體量和插入的的比例.
■公式: Qcache_lowmem_prunes / Qcache_inserts
■正常范圍:
■含義:放入緩存的數(shù)量
與 被迫從緩存中擠出去的數(shù)量的比值.
被擠的情況有某個(gè)查詢(xún)結(jié)果集太久沒(méi)有復(fù)用,來(lái)了新的結(jié)果集,緩存中沒(méi)有空了.
也可能是,緩存的結(jié)果集涉及到的表更新比較頻繁,在下次利用的時(shí)候,
發(fā)現(xiàn)已經(jīng)是臟的數(shù)據(jù)了,于是就擠出來(lái),在重新裝載.
這個(gè)值能反映出
查詢(xún)緩存是不是一個(gè)穩(wěn)定的查詢(xún)緩存,有沒(méi)有必要使用查詢(xún)緩存.
11,查詢(xún)緩存命中率(從緩存中刪除，因?yàn)閮?nèi)存不夠)與插入查詢(xún)緩存的比率。
■監(jiān)視點(diǎn):一個(gè)查詢(xún)的結(jié)果能被復(fù)用的比例.
■公式: Qcache_hits / (Qcache_inserts +
Qcache_hits)
■正常范圍:
■含義:查詢(xún)緩存應(yīng)該為此一個(gè)高的命中率。高命中率表示其他的連接可以使用查詢(xún)緩存中結(jié)果。
低命中率說(shuō)明沒(méi)有足夠的內(nèi)存分配給它，或者查詢(xún)沒(mé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í)無(wú)
■公式:
■正常范圍:
■含義:當(dāng)排序后按排序后的順序讀取行時(shí)，則通過(guò)該緩沖區(qū)讀取行，避免搜索硬盤(pán)。
將該變量設(shè)置為較大的值可以大大改進(jìn)ORDER BY的性能。但是，這是為每個(gè)客戶(hù)端分配的緩沖區(qū)，
因此你不應(yīng)將全局變量設(shè)置為較大的值。相反，只為需要運(yùn)行大查詢(xún)的客戶(hù)端更改會(huì)話(huà)變量。
14, read_rnd_buffer_size的大小是否合適.
■監(jiān)視點(diǎn):表鎖的次數(shù).
■公式:Table_locks_waited / (Table_locks_waited + Table_locks_immediate)
■正常范圍:10%以?xún)?nèi)
■含義:對(duì)MyISAM表,所表是發(fā)生在讀和寫(xiě)他們兩兩之間的,是并發(fā)性很低的,所以如果這個(gè)值高的話(huà),
需要拷考慮進(jìn)行表類(lèi)型的更改.
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%以?xún)?nèi)
■含義:要盡力保持很小的值。設(shè)法隔離沒(méi)使用索引的查詢(xún)。使用慢查詢(xún)?nèi)罩居涗浤男┻\(yùn)行時(shí)間較長(zhǎng)的查詢(xún)。
16, Select_full_join .
■監(jiān)視點(diǎn):沒(méi)有使用索引的聯(lián)接的數(shù)量.
■公式:Select_full_join
■正常范圍:20%以?xún)?nèi)
■含義:沒(mé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%以?xún)?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%以?xún)?nèi)
■含義:如果這個(gè)值太高了那么就要考慮增加tmp_table_size和max_heap_table_size大小。
臨時(shí)表的TEXT or BLOBS字段要保存在磁盤(pán)上，因此設(shè)法改變TEXT或者BLOBS字段類(lèi)型。
(完)
總結(jié)
以上是生活随笔為你收集整理的mysql sql wait 写法_有关SQL语句写法注意的那些事情（原创整理）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： win7电脑内外网切换(一台电脑切换内外
- 下一篇： mysql explain output