例子如下：SELCET * FROM T-USER U WHERE CONCAT(U.LASTNAME,U.FIRSTNAME) LIKE '%$LSP_NAME$%'
成都創(chuàng)新互聯(lián)是一家專業(yè)提供富川企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、成都h5網(wǎng)站建設(shè)、小程序制作等業(yè)務(wù)。10年已為富川眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進(jìn)行中。
LASTNAME 字段是姓；
FIRSTNAME字段是名字；
當(dāng)查詢字段為null時(shí)，返回結(jié)果為null。與concat_ws(...)不同。
如果為多個(gè)字段同時(shí)進(jìn)行查詢時(shí)，使用concat_ws(...)。
select concat_ws(',','11','22','33');
select concat_ws(',','11','22','33',null);都返回11,22,33。
CONCAT_WS() 代表 CONCAT With Separator，是CONCAT()的特殊形式。第一個(gè)參數(shù)是其它參數(shù)的分隔符。分隔符的位置放在要連接的兩個(gè)字符串之間。分隔符可以是一個(gè)字符串，也可以是其它參數(shù)。
CONCAT()可以連接一個(gè)或者多個(gè)字符串,CONCAT_WS()可以添加分割符參數(shù)。
索引功能
索引是一種特殊的文件（InnoDB 數(shù)據(jù)表上的索引是表空間的一個(gè)組成部分），它們包含著對(duì)數(shù)據(jù)表里所有記錄的引用指針。索引不是萬(wàn)能的，索引可以加快數(shù)據(jù)檢索操作，但會(huì)使數(shù)據(jù)修改操作變慢。每修改數(shù)據(jù)記錄，索引就必須刷新一次。為了在某種程度上彌補(bǔ)這一缺陷，許多 SQL 命令都有一個(gè) DELAY_KEY_WRITE 項(xiàng)。這個(gè)選項(xiàng)的作用是暫時(shí)制止 MySQL 在該命令每插入一條新記錄和每修改一條現(xiàn)有之后立刻對(duì)索引進(jìn)行刷新，對(duì)索引的刷新將等到全部記錄插入/修改完畢之后再進(jìn)行。在需要把許多新記錄插入某個(gè)數(shù)據(jù)表的場(chǎng)合，DELAY_KEY_WRITE 選項(xiàng)的作用將非常明顯。另外，索引還會(huì)在硬盤上占用相當(dāng)大的空間。因此應(yīng)該只為最經(jīng)常查詢和最經(jīng)常排序的數(shù)據(jù)列建立索引。注意，如果某個(gè)數(shù)據(jù)列包含許多重復(fù)的內(nèi)容，為它建立索引就沒(méi)有太大的實(shí)際效果。
從理論上講，完全可以為數(shù)據(jù)表里的每個(gè)字段分別建一個(gè)索引，但 MySQL 把同一個(gè)數(shù)據(jù)表里的索引總數(shù)限制為16個(gè)。
1．InnoDB 數(shù)據(jù)表的索引
與?InnoDB數(shù)據(jù)表相比，在 InnoDB 數(shù)據(jù)表上，索引對(duì) InnoDB 數(shù)據(jù)表的重要性要大得多。在 InnoDB 數(shù)據(jù)表上，索引不僅會(huì)在搜索數(shù)據(jù)記錄時(shí)發(fā)揮作用，還是數(shù)據(jù)行級(jí)鎖定機(jī)制的苊、基礎(chǔ)。“數(shù)據(jù)行級(jí)鎖定”的意思是指在事務(wù)操作的執(zhí)行過(guò)程中鎖定正在被處理的個(gè)別記錄，不讓其他用戶進(jìn)行訪問(wèn)。這種鎖定將影響到（但不限于）SELECT、LOCKINSHAREMODE、SELECT、FORUPDATE 命令以及 INSERT、UPDATE 和 DELETE 命令。出于效率方面的考慮，InnoDB 數(shù)據(jù)表的數(shù)據(jù)行級(jí)鎖定實(shí)際發(fā)生在它們的索引上，而不是數(shù)據(jù)表自身上。顯然，數(shù)據(jù)行級(jí)鎖定機(jī)制只有在有關(guān)的數(shù)據(jù)表有一個(gè)合適的索引可供鎖定的時(shí)候才能發(fā)揮效力。
2．限制
如果 WHERE 子句的查詢條件里有不等號(hào)（WHERE coloum !=），MySQL 將無(wú)法使用索引。類似地，如果 WHERE 子句的查詢條件里使用了函數(shù)（WHERE DAY（column）=），MySQL 也將無(wú)法使用索引。在 JOIN 操作中（需要從多個(gè)數(shù)據(jù)表提取數(shù)據(jù)時(shí)），MySQL 只有在主鍵和外鍵的數(shù)據(jù)類型相同時(shí)才能使用索引。
如果 WHERE 子句的查詢條件里使用比較操作符 LIKE 和 REGEXP，MySQL 只有在搜索模板的第一個(gè)字符不是通配符的情況下才能使用索引。比如說(shuō)，如果查詢條件是 LIKE 'abc%‘，MySQL 將使用索引；如果查詢條件是 LIKE '%abc’，MySQL 將不使用索引。
在 ORDER BY 操作中，MySQL 只有在排序條件不是一個(gè)查詢條件表達(dá)式的情況下才使用索引。（雖然如此，在涉及多個(gè)數(shù)據(jù)表查詢里，即使有索引可用，那些索引在加快 ORDER BY 方面也沒(méi)什么作用）。如果某個(gè)數(shù)據(jù)列里包含許多重復(fù)的值，就算為它建立了索引也不會(huì)有很好的效果。比如說(shuō)，如果某個(gè)數(shù)據(jù)列里包含的凈是些諸如 “0/1” 或 “Y/N” 等值，就沒(méi)有必要為它創(chuàng)建一個(gè)索引。
索引類別
1．普通索引
普通索引（由關(guān)鍵字 KEY 或 INDEX 定義的索引）的唯一任務(wù)是加快對(duì)數(shù)據(jù)的訪問(wèn)速度。因此，應(yīng)該只為那些最經(jīng)常出現(xiàn)在查詢條件（WHERE column =）或排序條件（ORDER BY column）中的數(shù)據(jù)列創(chuàng)建索引。只要有可能，就應(yīng)該選擇一個(gè)數(shù)據(jù)最整齊、最緊湊的數(shù)據(jù)列（如一個(gè)整數(shù)類型的數(shù)據(jù)列）來(lái)創(chuàng)建索引。
2．唯一索引
普通索引允許被索引的數(shù)據(jù)列包含重復(fù)的值。比如說(shuō)，因?yàn)槿擞锌赡芡酝粋€(gè)姓名在同一個(gè)“員工個(gè)人資料”數(shù)據(jù)表里可能出現(xiàn)兩次或更多次。
如果能確定某個(gè)數(shù)據(jù)列將只包含彼此各不相同的值，在為這個(gè)數(shù)據(jù)列創(chuàng)建索引的時(shí)候就應(yīng)該用關(guān)鍵字UNIQUE 把它定義為一個(gè)唯一索引。這么做的好處：一是簡(jiǎn)化了 MySQL 對(duì)這個(gè)索引的管理工作，這個(gè)索引也因此而變得更有效率；二是 MySQL 會(huì)在有新記錄插入數(shù)據(jù)表時(shí)，自動(dòng)檢查新記錄的這個(gè)字段的值是否已經(jīng)在某個(gè)記錄的這個(gè)字段里出現(xiàn)過(guò)了；如果是，MySQL 將拒絕插入那條新記錄。也就是說(shuō)，唯一索引可以保證數(shù)據(jù)記錄的唯一性。事實(shí)上，在許多場(chǎng)合，人們創(chuàng)建唯一索引的目的往往不是為了提高訪問(wèn)速度，而只是為了避免數(shù)據(jù)出現(xiàn)重復(fù)。
3．主索引
在前面已經(jīng)反復(fù)多次強(qiáng)調(diào)過(guò)：必須為主鍵字段創(chuàng)建一個(gè)索引，這個(gè)索引就是所謂的“主索引”。主索引與唯一索引的唯一區(qū)別是：前者在定義時(shí)使用的關(guān)鍵字是 PRIMARY 而不是 UNIQUE。
4．外鍵索引
如果為某個(gè)外鍵字段定義了一個(gè)外鍵約束條件，MySQL 就會(huì)定義一個(gè)內(nèi)部索引來(lái)幫助自己以最有效率的方式去管理和使用外鍵約束條件。
5．復(fù)合索引
索引可以覆蓋多個(gè)數(shù)據(jù)列，如像 INDEX (columnA, columnB) 索引。這種索引的特點(diǎn)是 MySQL 可以有選擇地使用一個(gè)這樣的索引。如果查詢操作只需要用到 columnA 數(shù)據(jù)列上的一個(gè)索引，就可以使用復(fù)合索引 INDEX(columnA, columnB)。不過(guò)，這種用法僅適用于在復(fù)合索引中排列在前的數(shù)據(jù)列組合。比如說(shuō)，INDEX (A，B，C) 可以當(dāng)做 A 或 (A,B) 的索引來(lái)使用，但不能當(dāng)做 B、C 或 (B,C) 的索引來(lái)使用。
索引長(zhǎng)度
在為 CHAR 和 VARCHAR 類型的數(shù)據(jù)列定義索引時(shí)，可以把索引的長(zhǎng)度限制為一個(gè)給定的字符個(gè)數(shù)（這個(gè)數(shù)字必須小于這個(gè)字段所允許的最大字符個(gè)數(shù)）。這么做的好處是可以生成一個(gè)尺寸比較小、檢索速度卻比較快的索引文件。在絕大多數(shù)應(yīng)用里，數(shù)據(jù)庫(kù)中的字符串?dāng)?shù)據(jù)大都以各種各樣的名字為主，把索引的長(zhǎng)度設(shè)置為10~15 個(gè)字符已經(jīng)足以把搜索范圍縮小到很少的幾條數(shù)據(jù)記錄了。在為 BLOB 和 TEXT 類型的數(shù)據(jù)列創(chuàng)建索引時(shí)，必須對(duì)索引的長(zhǎng)度做出限制；MySQL 所允許的最大索引全文索引文本字段上的普通索引只能加快對(duì)出現(xiàn)在字段內(nèi)容最前面的字符串（也就是字段內(nèi)容開頭的字符）進(jìn)行檢索操作。如果字段里存放的是由幾個(gè)、甚至是多個(gè)單詞構(gòu)成的較大段文字，普通索引就沒(méi)什么作用了。這種檢索往往以的形式出現(xiàn)，這對(duì) MySQL 來(lái)說(shuō)很復(fù)雜，如果需要處理的數(shù)據(jù)量很大，響應(yīng)時(shí)間就會(huì)很長(zhǎng)。
這類場(chǎng)合正是全文索引（full-textindex）可以大顯身手的地方。在生成這種類型的索引時(shí)，MySQL 將把在文本中出現(xiàn)的所有單詞創(chuàng)建為一份清單，查詢操作將根據(jù)這份清單去檢索有關(guān)的數(shù)據(jù)記錄。全文索引即可以隨數(shù)據(jù)表一同創(chuàng)建，也可以等日后有必要時(shí)再使用下面這條命令添加：
ALTER TABLE tablename ADD FULLTEXT（column1，column2）有了全文索引，就可以用 SELECT 查詢命令去檢索那些包含著一個(gè)或多個(gè)給定單詞的數(shù)據(jù)記錄了。下面是這類查詢命令的基本語(yǔ)法：
SELECT * FROM tablename
WHERE MATCH (column1,column2) AGAINST('word1','word2','word3')
上面這條命令將把 column1 和 column2 字段里有 word1、word2 和 word3 的數(shù)據(jù)記錄全部查詢出來(lái)。
注解：InnoDB 數(shù)據(jù)表不支持全文索引。
很多應(yīng)用往往只展示最新或最熱門的幾條記錄，但為了舊記錄仍然可訪問(wèn)，所以就需要個(gè)分頁(yè)的導(dǎo)航欄。然而，如何通過(guò)MySQL更好的實(shí)現(xiàn)分頁(yè)，始終是比較令人頭疼的問(wèn)題。雖然沒(méi)有拿來(lái)就能用的解決辦法，但了解數(shù)據(jù)庫(kù)的底層或多或少有助于優(yōu)化分頁(yè)查詢。
我們先從一個(gè)常用但性能很差的查詢來(lái)看一看。
SELECT *
FROM city
ORDER BY id DESC
LIMIT 0, 15
這個(gè)查詢耗時(shí)0.00sec。So，這個(gè)查詢有什么問(wèn)題呢？實(shí)際上，這個(gè)查詢語(yǔ)句和參數(shù)都沒(méi)有問(wèn)題，因?yàn)樗玫搅讼旅姹淼闹麈I，而且只讀取15條記錄。
CREATE TABLE city (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
city varchar(128) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;
真正的問(wèn)題在于offset(分頁(yè)偏移量)很大的時(shí)候，像下面這樣：
SELECT *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
上面的查詢?cè)谟?M行記錄時(shí)需要0.22sec，通過(guò)EXPLAIN查看SQL的執(zhí)行計(jì)劃可以發(fā)現(xiàn)該SQL檢索了100015行，但最后只需要15行。大的分頁(yè)偏移量會(huì)增加使用的數(shù)據(jù)，MySQL會(huì)將大量最終不會(huì)使用的數(shù)據(jù)加載到內(nèi)存中。就算我們假設(shè)大部分網(wǎng)站的用戶只訪問(wèn)前幾頁(yè)數(shù)據(jù)，但少量的大的分頁(yè)偏移量的請(qǐng)求也會(huì)對(duì)整個(gè)系統(tǒng)造成危害。Facebook意識(shí)到了這一點(diǎn)，但Facebook并沒(méi)有為了每秒可以處理更多的請(qǐng)求而去優(yōu)化數(shù)據(jù)庫(kù)，而是將重心放在將請(qǐng)求響應(yīng)時(shí)間的方差變小。
對(duì)于分頁(yè)請(qǐng)求，還有一個(gè)信息也很重要，就是總共的記錄數(shù)。我們可以通過(guò)下面的查詢很容易的獲取總的記錄數(shù)。
SELECT COUNT(*)
FROM city;
然而，上面的SQL在采用InnoDB為存儲(chǔ)引擎時(shí)需要耗費(fèi)9.28sec。一個(gè)不正確的優(yōu)化是采用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能夠在分頁(yè)查詢時(shí)事先準(zhǔn)備好符合條件的記錄數(shù)，隨后只要執(zhí)行一句 select FOUND_ROWS(); 就能獲得總記錄數(shù)。但是在大多數(shù)情況下，查詢語(yǔ)句簡(jiǎn)短并不意味著性能的提高。不幸的是，這種分頁(yè)查詢方式在許多主流框架中都有用到，下面看看這個(gè)語(yǔ)句的查詢性能。
SELECT SQL_CALC_FOUND_ROWS *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
這個(gè)語(yǔ)句耗時(shí)20.02sec，是上一個(gè)的兩倍。事實(shí)證明使用 SQL_CALC_FOUND_ROWS 做分頁(yè)是很糟糕的想法。
下面來(lái)看看到底如何優(yōu)化。文章分為兩部分，第一部分是如何獲取記錄的總數(shù)目，第二部分是獲取真正的記錄。
高效的計(jì)算行數(shù)
如果采用的引擎是MyISAM，可以直接執(zhí)行COUNT(*)去獲取行數(shù)即可。相似的，在堆表中也會(huì)將行數(shù)存儲(chǔ)到表的元信息中。但如果引擎是InnoDB情況就會(huì)復(fù)雜一些，因?yàn)镮nnoDB不保存表的具體行數(shù)。
我們可以將行數(shù)緩存起來(lái)，然后可以通過(guò)一個(gè)守護(hù)進(jìn)程定期更新或者用戶的某些操作導(dǎo)致緩存失效時(shí)，執(zhí)行下面的語(yǔ)句：
SELECT COUNT(*)
FROM city
USE INDEX(PRIMARY);
獲取記錄
下面進(jìn)入這篇文章最重要的部分，獲取分頁(yè)要展示的記錄。上面已經(jīng)說(shuō)過(guò)了，大的偏移量會(huì)影響性能，所以我們要重寫查詢語(yǔ)句。為了演示，我們創(chuàng)建一個(gè)新的表“news”，按照時(shí)事性排序(最新發(fā)布的在最前面)，實(shí)現(xiàn)一個(gè)高性能的分頁(yè)。為了簡(jiǎn)單，我們就假設(shè)最新發(fā)布的新聞的Id也是最大的。
CREATE TABLE news(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(128) NOT NULL
) ENGINE=InnoDB;
一個(gè)比較高效的方式是基于用戶展示的最后一個(gè)新聞Id。查詢下一頁(yè)的語(yǔ)句如下，需要傳入當(dāng)前頁(yè)面展示的最后一個(gè)Id。
SELECT *
FROM news WHERE id $last_id
ORDER BY id DESC
LIMIT $perpage
查詢上一頁(yè)的語(yǔ)句類似，只不過(guò)需要傳入當(dāng)前頁(yè)的第一個(gè)Id，并且要逆序。
SELECT *
FROM news WHERE id $last_id
ORDER BY id ASC
LIMIT $perpage
上面的查詢方式適合實(shí)現(xiàn)簡(jiǎn)易的分頁(yè)，即不顯示具體的頁(yè)數(shù)導(dǎo)航，只顯示“上一頁(yè)”和“下一頁(yè)”，例如博客中頁(yè)腳顯示“上一頁(yè)”，“下一頁(yè)”的按鈕。但如果要實(shí)現(xiàn)真正的頁(yè)面導(dǎo)航還是很難的,下面看看另一種方式。
SELECT id
FROM (
SELECT id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt
FROM news
JOIN (SELECT @cnt:= 0)T
WHERE id $last_id
ORDER BY id DESC
LIMIT $perpage * $buttons
)C
WHERE cnt = 0;
通過(guò)上面的語(yǔ)句可以為每一個(gè)分頁(yè)的按鈕計(jì)算出一個(gè)offset對(duì)應(yīng)的id。這種方法還有一個(gè)好處。假設(shè)，網(wǎng)站上正在發(fā)布一片新的文章，那么所有文章的位置都會(huì)往后移一位，所以如果用戶在發(fā)布文章時(shí)換頁(yè)，那么他會(huì)看見一篇文章兩次。如果固定了每個(gè)按鈕的offset Id，這個(gè)問(wèn)題就迎刃而解了。Mark Callaghan發(fā)表過(guò)一篇類似的博客，利用了組合索引和兩個(gè)位置變量，但是基本思想是一致的。
如果表中的記錄很少被刪除、修改，還可以將記錄對(duì)應(yīng)的頁(yè)碼存儲(chǔ)到表中，并在該列上創(chuàng)建合適的索引。采用這種方式，當(dāng)新增一個(gè)記錄的時(shí)候，需要執(zhí)行下面的查詢重新生成對(duì)應(yīng)的頁(yè)號(hào)。
SET p:= 0;
UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;
當(dāng)然，也可以新增一個(gè)專用于分頁(yè)的表，可以用個(gè)后臺(tái)程序來(lái)維護(hù)。
UPDATE pagination T
JOIN (
SELECT id, CEIL((p:= p + 1) / $perpage) page
FROM news
ORDER BY id
)C
ON C.id = T.id
SET T.page = C.page;
現(xiàn)在想獲取任意一頁(yè)的元素就很簡(jiǎn)單了：
SELECT *
FROM news A
JOIN pagination B ON A.id=B.ID
WHERE page=$offset;
還有另外一種與上種方法比較相似的方法來(lái)做分頁(yè)，這種方式比較試用于數(shù)據(jù)集相對(duì)小，并且沒(méi)有可用的索引的情況下—比如處理搜索結(jié)果時(shí)。在一個(gè)普通的服務(wù)器上執(zhí)行下面的查詢，當(dāng)有2M條記錄時(shí)，要耗費(fèi)2sec左右。這種方式比較簡(jiǎn)單，創(chuàng)建一個(gè)用來(lái)存儲(chǔ)所有Id的臨時(shí)表即可(這也是最耗費(fèi)性能的地方)。
CREATE TEMPORARY TABLE _tmp (KEY SORT(random))
SELECT id, FLOOR(RAND() * 0x8000000) random
FROM city;
ALTER TABLE _tmp ADD OFFSET INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, DROP INDEX SORT,ORDER BY random;
接下來(lái)就可以向下面一樣執(zhí)行分頁(yè)查詢了。
SELECT *
FROM _tmp
WHERE OFFSET = $offset
ORDER BY OFFSET
LIMIT $perpage;
簡(jiǎn)單來(lái)說(shuō)，對(duì)于分頁(yè)的優(yōu)化就是。。。避免數(shù)據(jù)量大時(shí)掃描過(guò)多的記錄。
假設(shè)是數(shù)組形式如:需要查1,2,3,4,5,6的數(shù)據(jù)就用in :select * from table where num in(1,2,3,4,5,6)
如果需要查詢范圍內(nèi)的，如:查詢1-6范圍內(nèi)的可以:
select * from table where num 1
and num 6
做一些數(shù)據(jù)庫(kù)查詢，不僅希望得到要查詢的結(jié)果，還希望方便地計(jì)算一下查詢結(jié)果中有多少條記錄。我通常的做法是：
$q = "select * from $fromTable where $where limit $start,$pageSize";
$r = mysql_query($q);
$q = "select count(*) from $fromTable where $where";
$cnt = mysql_query($q);
當(dāng) 然可以用mysql_num_rows()或者mysql_affected_rows()來(lái)在第一次查詢后得到記錄數(shù)目，但是這兩個(gè)函數(shù)返回的都是查詢 后得到的結(jié)果的數(shù)目，是受limit語(yǔ)句的影響的。很多情況下，需要知道這條查詢語(yǔ)句在沒(méi)有l(wèi)imit的情況下結(jié)果總數(shù)，比如分頁(yè)查詢。
mysql 中本身支持一種更好的方法來(lái)達(dá)到上面的效果，那就是使用SQL_CALC_FOUND_ROWS和FOUND_ROWS()函數(shù)。
一、MySQL數(shù)據(jù)庫(kù)有幾個(gè)配置選項(xiàng)可以幫助我們及時(shí)捕獲低效SQL語(yǔ)句
1，slow_query_log
這個(gè)參數(shù)設(shè)置為ON，可以捕獲執(zhí)行時(shí)間超過(guò)一定數(shù)值的SQL語(yǔ)句。
2，long_query_time
當(dāng)SQL語(yǔ)句執(zhí)行時(shí)間超過(guò)此數(shù)值時(shí)，就會(huì)被記錄到日志中，建議設(shè)置為1或者更短。
3，slow_query_log_file
記錄日志的文件名。
4，log_queries_not_using_indexes
這個(gè)參數(shù)設(shè)置為ON，可以捕獲到所有未使用索引的SQL語(yǔ)句，盡管這個(gè)SQL語(yǔ)句有可能執(zhí)行得挺快。
二、檢測(cè)mysql中sql語(yǔ)句的效率的方法
1、通過(guò)查詢?nèi)罩?/p>
（1）、Windows下開啟MySQL慢查詢
MySQL在Windows系統(tǒng)中的配置文件一般是是my.ini找到[mysqld]下面加上
代碼如下
log-slow-queries = F:/MySQL/log/mysqlslowquery。log
long_query_time = 2
（2）、Linux下啟用MySQL慢查詢
MySQL在Windows系統(tǒng)中的配置文件一般是是my.cnf找到[mysqld]下面加上
代碼如下
log-slow-queries=/data/mysqldata/slowquery。log
long_query_time=2
說(shuō)明
log-slow-queries = F:/MySQL/log/mysqlslowquery。
為慢查詢?nèi)罩敬娣诺奈恢?，一般這個(gè)目錄要有MySQL的運(yùn)行帳號(hào)的可寫權(quán)限，一般都將這個(gè)目錄設(shè)置為MySQL的數(shù)據(jù)存放目錄；
long_query_time=2中的2表示查詢超過(guò)兩秒才記錄；
2.show processlist 命令
SHOW PROCESSLIST顯示哪些線程正在運(yùn)行。您也可以使用mysqladmin processlist語(yǔ)句得到此信息。
各列的含義和用途：
ID列
一個(gè)標(biāo)識(shí)，你要kill一個(gè)語(yǔ)句的時(shí)候很有用，用命令殺掉此查詢 /*/mysqladmin kill 進(jìn)程號(hào)。
user列
顯示單前用戶，如果不是root，這個(gè)命令就只顯示你權(quán)限范圍內(nèi)的sql語(yǔ)句。
host列
顯示這個(gè)語(yǔ)句是從哪個(gè)ip的哪個(gè)端口上發(fā)出的。用于追蹤出問(wèn)題語(yǔ)句的用戶。
db列
顯示這個(gè)進(jìn)程目前連接的是哪個(gè)數(shù)據(jù)庫(kù)。
command列
顯示當(dāng)前連接的執(zhí)行的命令，一般就是休眠（sleep），查詢（query），連接（connect）。
time列
此這個(gè)狀態(tài)持續(xù)的時(shí)間，單位是秒。
state列
顯示使用當(dāng)前連接的sql語(yǔ)句的狀態(tài)，很重要的列，后續(xù)會(huì)有所有的狀態(tài)的描述，請(qǐng)注意，state只是語(yǔ)句執(zhí)行中的某一個(gè)狀態(tài)，一個(gè) sql語(yǔ)句，以查詢?yōu)槔赡苄枰?jīng)過(guò)copying to tmp table，Sorting result，Sending data等狀態(tài)才可以完成
info列
顯示這個(gè)sql語(yǔ)句，因?yàn)殚L(zhǎng)度有限，所以長(zhǎng)的sql語(yǔ)句就顯示不全，但是一個(gè)判斷問(wèn)題語(yǔ)句的重要依據(jù)。
這個(gè)命令中最關(guān)鍵的就是state列，mysql列出的狀態(tài)主要有以下幾種：
Checking table
正在檢查數(shù)據(jù)表（這是自動(dòng)的）。
Closing tables
正在將表中修改的數(shù)據(jù)刷新到磁盤中，同時(shí)正在關(guān)閉已經(jīng)用完的表。這是一個(gè)很快的操作，如果不是這樣的話，就應(yīng)該確認(rèn)磁盤空間是否已經(jīng)滿了或者磁盤是否正處于重負(fù)中。
Connect Out
復(fù)制從服務(wù)器正在連接主服務(wù)器。
Copying to tmp table on disk
由于臨時(shí)結(jié)果集大于tmp_table_size，正在將臨時(shí)表從內(nèi)存存儲(chǔ)轉(zhuǎn)為磁盤存儲(chǔ)以此節(jié)省內(nèi)存。
Creating tmp table
正在創(chuàng)建臨時(shí)表以存放部分查詢結(jié)果。
deleting from main table
服務(wù)器正在執(zhí)行多表刪除中的第一部分，剛刪除第一個(gè)表。
deleting from reference tables
服務(wù)器正在執(zhí)行多表刪除中的第二部分，正在刪除其他表的記錄。
Flushing tables
正在執(zhí)行FLUSH TABLES，等待其他線程關(guān)閉數(shù)據(jù)表。
Killed
發(fā)送了一個(gè)kill請(qǐng)求給某線程，那么這個(gè)線程將會(huì)檢查kill標(biāo)志位，同時(shí)會(huì)放棄下一個(gè)kill請(qǐng)求。MySQL會(huì)在每次的主循環(huán)中檢查kill標(biāo)志位，不過(guò)有些情況下該線程可能會(huì)過(guò)一小段才能死掉。如果該線程程被其他線程鎖住了，那么kill請(qǐng)求會(huì)在鎖釋放時(shí)馬上生效。
Locked
被其他查詢鎖住了。
Sending data
正在處理SELECT查詢的記錄，同時(shí)正在把結(jié)果發(fā)送給客戶端。
Sorting for group
正在為GROUP BY做排序。
Sorting for order
正在為ORDER BY做排序。
Opening tables
這個(gè)過(guò)程應(yīng)該會(huì)很快，除非受到其他因素的干擾。例如，在執(zhí)ALTER TABLE或LOCK TABLE語(yǔ)句行完以前，數(shù)據(jù)表無(wú)法被其他線程打開。正嘗試打開一個(gè)表。
Removing duplicates
正在執(zhí)行一個(gè)SELECT DISTINCT方式的查詢，但是MySQL無(wú)法在前一個(gè)階段優(yōu)化掉那些重復(fù)的記錄。因此，MySQL需要再次去掉重復(fù)的記錄，然后再把結(jié)果發(fā)送給客戶端。
Reopen table
獲得了對(duì)一個(gè)表的鎖，但是必須在表結(jié)構(gòu)修改之后才能獲得這個(gè)鎖。已經(jīng)釋放鎖，關(guān)閉數(shù)據(jù)表，正嘗試重新打開數(shù)據(jù)表。
Repair by sorting
修復(fù)指令正在排序以創(chuàng)建索引。
Repair with keycache
修復(fù)指令正在利用索引緩存一個(gè)一個(gè)地創(chuàng)建新索引。它會(huì)比Repair by sorting慢些。
Searching rows for update
正在講符合條件的記錄找出來(lái)以備更新。它必須在UPDATE要修改相關(guān)的記錄之前就完成了。
Sleeping
正在等待客戶端發(fā)送新請(qǐng)求.
System lock
正在等待取得一個(gè)外部的系統(tǒng)鎖。如果當(dāng)前沒(méi)有運(yùn)行多個(gè)mysqld服務(wù)器同時(shí)請(qǐng)求同一個(gè)表，那么可以通過(guò)增加--skip-external-locking參數(shù)來(lái)禁止外部系統(tǒng)鎖。
Upgrading lock
INSERT DELAYED正在嘗試取得一個(gè)鎖表以插入新記錄。
Updating
正在搜索匹配的記錄，并且修改它們。
User Lock
正在等待GET_LOCK()。
Waiting for tables
該線程得到通知，數(shù)據(jù)表結(jié)構(gòu)已經(jīng)被修改了，需要重新打開數(shù)據(jù)表以取得新的結(jié)構(gòu)。然后，為了能的重新打開數(shù)據(jù)表，必須等到所有其他線程關(guān)閉這個(gè)表。以下幾種情況下會(huì)產(chǎn)生這個(gè)通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。
waiting for handler insert
INSERT DELAYED已經(jīng)處理完了所有待處理的插入操作，正在等待新的請(qǐng)求。
大部分狀態(tài)對(duì)應(yīng)很快的操作，只要有一個(gè)線程保持同一個(gè)狀態(tài)好幾秒鐘，那么可能是有問(wèn)題發(fā)生了，需要檢查一下。
還有其他的狀態(tài)沒(méi)在上面中列出來(lái)，不過(guò)它們大部分只是在查看服務(wù)器是否有存在錯(cuò)誤是才用得著。
例如如圖：
3、explain來(lái)了解SQL執(zhí)行的狀態(tài)
explain顯示了mysql如何使用索引來(lái)處理select語(yǔ)句以及連接表?？梢詭椭x擇更好的索引和寫出更優(yōu)化的查詢語(yǔ)句。
使用方法，在select語(yǔ)句前加上explain就可以了：
例如：
explain select surname,first_name form a,b where a.id=b.id
結(jié)果如圖
EXPLAIN列的解釋
table
顯示這一行的數(shù)據(jù)是關(guān)于哪張表的
type
這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為const、eq_reg、ref、range、indexhe和ALL
possible_keys
顯示可能應(yīng)用在這張表中的索引。如果為空，沒(méi)有可能的索引?？梢詾橄嚓P(guān)的域從WHERE語(yǔ)句中選擇一個(gè)合適的語(yǔ)句
key
實(shí)際使用的索引。如果為NULL，則沒(méi)有使用索引。很少的情況下，MYSQL會(huì)選擇優(yōu)化不足的索引。這種情況下，可以在SELECT語(yǔ)句 中使用USE INDEX（indexname）來(lái)強(qiáng)制使用一個(gè)索引或者用IGNORE INDEX（indexname）來(lái)強(qiáng)制MYSQL忽略索引
key_len
使用的索引的長(zhǎng)度。在不損失精確性的情況下，長(zhǎng)度越短越好
ref
顯示索引的哪一列被使用了，如果可能的話，是一個(gè)常數(shù)
rows
MYSQL認(rèn)為必須檢查的用來(lái)返回請(qǐng)求數(shù)據(jù)的行數(shù)
Extra
關(guān)于MYSQL如何解析查詢的額外信息。將在表4.3中討論，但這里可以看到的壞的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，結(jié)果是檢索會(huì)很慢
extra列返回的描述的意義
Distinct
一旦MYSQL找到了與行相聯(lián)合匹配的行，就不再搜索了
Not exists
MYSQL優(yōu)化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標(biāo)準(zhǔn)的行，就不再搜索了
Range checked for each Record（index map:#）
沒(méi)有找到理想的索引，因此對(duì)于從前面表中來(lái)的每一個(gè)行組合，MYSQL檢查使用哪個(gè)索引，并用它來(lái)從表中返回行。這是使用索引的最慢的連接之一
Using filesort
看到這個(gè)的時(shí)候，查詢就需要優(yōu)化了。MYSQL需要進(jìn)行額外的步驟來(lái)發(fā)現(xiàn)如何對(duì)返回的行排序。它根據(jù)連接類型以及存儲(chǔ)排序鍵值和匹配條件的全部行的行指針來(lái)排序全部行
Using index
列數(shù)據(jù)是從僅僅使用了索引中的信息而沒(méi)有讀取實(shí)際的行動(dòng)的表返回的，這發(fā)生在對(duì)表的全部的請(qǐng)求列都是同一個(gè)索引的部分的時(shí)候
Using temporary
看到這個(gè)的時(shí)候，查詢需要優(yōu)化了。這里，MYSQL需要?jiǎng)?chuàng)建一個(gè)臨時(shí)表來(lái)存儲(chǔ)結(jié)果，這通常發(fā)生在對(duì)不同的列集進(jìn)行ORDER BY上，而不是GROUP BY上
Where used
使用了WHERE從句來(lái)限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，并且連接類型ALL或index，這就會(huì)發(fā)生，或者是查詢有問(wèn)題不同連接類型的解釋（按照效率高低的順序排序）
const
表中的一個(gè)記錄的最大值能夠匹配這個(gè)查詢（索引可以是主鍵或惟一索引）。因?yàn)橹挥幸恍校@個(gè)值實(shí)際就是常數(shù)，因?yàn)镸YSQL先讀這個(gè)值然后把它當(dāng)做常數(shù)來(lái)對(duì)待
eq_ref
在連接中，MYSQL在查詢時(shí)，從前面的表中，對(duì)每一個(gè)記錄的聯(lián)合都從表中讀取一個(gè)記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時(shí)使用
ref
這個(gè)連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如，利用最左邊前綴）時(shí)發(fā)生。對(duì)于之前的表的每一個(gè)行聯(lián)合，全部記錄都將從表中讀出。這個(gè)類型嚴(yán)重依賴于根據(jù)索引匹配的記錄多少—越少越好
range
這個(gè)連接類型使用索引返回一個(gè)范圍中的行，比如使用或查找東西時(shí)發(fā)生的情況
index
這個(gè)連接類型對(duì)前面的表中的每一個(gè)記錄聯(lián)合進(jìn)行完全掃描（比ALL更好，因?yàn)樗饕话阈∮诒頂?shù)據(jù)）
ALL
這個(gè)連接類型對(duì)于前面的每一個(gè)記錄聯(lián)合進(jìn)行完全掃描，這一般比較糟糕，應(yīng)該盡量避免
可以用 命令"show PROCEDURE status"查看所有的存儲(chǔ)過(guò)程或檢索系統(tǒng)表"mysql.proc"來(lái)查詢已有的存儲(chǔ)過(guò)程。
例如：
用show PROCEDURE status命令查看：
-- 查看所有的存儲(chǔ)過(guò)程
show PROCEDURE status;
-- 查看特定數(shù)據(jù)庫(kù)存儲(chǔ)過(guò)程
show PROCEDURE status where db='test';
-- 用指定的登錄名查看該用戶創(chuàng)建的存儲(chǔ)過(guò)程
show PROCEDURE status where definer='root@localhost'; -- @localhost為用戶登錄位置(本地登錄)
-- 查看指定時(shí)間段創(chuàng)建存儲(chǔ)過(guò)程
show PROCEDURE status where created between '2017-02-17 00:00:00'
and '2017-02-17 23:59:59';
用系統(tǒng)表mysql.proc來(lái)查看：
-- 查看所有的存儲(chǔ)過(guò)程信息
select * from mysql.proc;
-- 查看特定數(shù)據(jù)庫(kù)里的存儲(chǔ)過(guò)程
select * from mysql.proc where db='test';
-- 查看某個(gè)用戶定義的存儲(chǔ)過(guò)程
select * from mysql.proc where definer='root@localhost';
-- 查看某時(shí)間段創(chuàng)建的存儲(chǔ)過(guò)程
select * from mysql.proc where created between '2017-02-17 00:00:00'
and '2017-02-17 23:59:59';
重慶分公司
重慶分公司
