大家應該都對sql語句特別熟悉，但是對於不同的人來說用sql語句操作資料庫取出自己想要的資料及資料格式的方式都不盡相同。那麼，我在這裡拋磚引玉的介紹一下我在面對特定的某些需求資料的時候是如何使用sql語句完成功能的（可能效率不是最高的，但是在我看來是我目前能想到的效率不低且可讀性高的了，歡迎大家批評指正，我也可以跟著多學一下）。廢話不多說，上點乾貨：

1.在專案的實際開發過程中，我們經常會遇到這樣的情況（例：我們需要某個時間段使用者名稱字，使用者釋出的有效需求數，使用者需求中標數，使用者釋出產品數，使用者購買產品數；而我們現在有的表有（僅列出有效欄位）：使用者資訊表（使用者id，使用者名稱字），需求表（使用者id，需求id，需求稽核狀態），需求中標表（使用者id，中標狀態），產品表（使用者id，產品id，產品稽核狀態），訂單表（使用者id，訂單編號））

一看到這幾個表，不知道有沒有人第一反應就是把表分開得到要顯示的欄位及使用者id再for迴圈拼起來的（或者與使用者資訊表聯查再拼接），雖然我開始第一想法就想寫這個，但是後來一想，感覺這樣為了得到幾個數要查庫這麼多次還要for迴圈，資料小還看不出來，如果表資料量大，那使用者體驗得多差。。其實主要是我懶得寫這麼多程式碼，以後要改看起來也很麻煩。本著懶人創造世界的原則，我就想把這幾張表的查詢結果直接懟成一張大表，合併使用者id重複的行就得到我們想要的資料了。OK，話不多說，我先上sql再解釋：

SELECT user_id, user, sum( need_count ) , sum( t_count ),sum
 
(goods_count), (sum( need_count )+sum( t_count )+sum(goods_count)) total_num, sum(data)
                    FROM (
                    (

                    SELECT user_id, count( id ) AS need_count, 0 AS t_count , 0 AS goods_count , 0 AS data
                    FROM btb_leader_task
                    WHERE
 
 examine =1 and time > 1493136000 and time < 1495814400
                    GROUP BY user_id
                    )
                    UNION ALL (

                    SELECT t_user_id AS user_id, 0 AS need_count, count( id ) AS t_count , 0 AS goods_count , 0 AS data
                    FROM btb_leader_submission
                    WHERE state =1 and winning_time > 1493136000 and winning_time < 1495814400
                    GROUP BY t_user_id
                    )
                    UNION ALL(
                    SELECT user_id, 0 AS need_count, 0 AS t_count , count( id ) AS goods_count , 0 AS data
                    FROM btb_shop_details
                    WHERE examine =1 and sales_categories = 1 and time > 1493136000 and time < 1495814400
                    GROUP BY user_id
                    )
                    UNION ALL(
                    SELECT user_id, 0 AS need_count, 0 AS t_count , 0 AS goods_count , data
                    FROM btb_activity_optimization
                    where time > 1493136000 and time < 1495814400
                    )
                    )a
                    LEFT JOIN btb_user bu
                    ON user_id = bu.id
                    GROUP BY user_id

看完sql不知道是不是有存有疑惑的小夥伴，讓我們先來看看mysql拼接表的一些關鍵字特性，或許就會有一些理解了。

關鍵字 join 用於多表中欄位之間的聯絡，語法如下：

... FROM table1 INNER|LEFT|RIGHT JOIN table2 ON conditiona

table1:左表；table2:右表。

JOIN 按照功能大致分為如下三類：

INNER JOIN（內連線,或等值連線）：取得兩個表中存在連線匹配關係的記錄。即：取交集
CROSS JOIN（交叉連線）：得到的結果是兩個表的乘積，即笛卡爾積
（PS:在 MySQL 中（僅限於 MySQL） CROSS JOIN 與 INNER JOIN 的表現是一樣的，在不指定 ON 條件得到的結果都是笛卡爾積，反之取得兩個表完全匹配的結果INNER JOIN 與 CROSS JOIN 可以省略 INNER 或 CROSS 關鍵字）
LEFT JOIN（左連線）：取得左表（table1）完全記錄，即使右表（table2）並無對應匹配記錄。

RIGHT JOIN（右連線）：與 LEFT JOIN 相反，取得右表（table2）完全記錄，即是左表（table1）並無匹配對應記錄。

注意：mysql不支援Full join,不過可以通過UNION 關鍵字來合併 LEFT JOIN 與 RIGHT JOIN來模擬FULL join.（ps：full join在sql server中是取左右兩表的並集）
普遍用於模擬full join 的sql語句如下：

mysql> select * from A left join B on B.name = A.name 
    -> union 
    -> select * from A right join B on B.name = A.name;

PS：可以不用顯示全部欄位，只顯示你需要的欄位就行。但是一定要注意了。UNION內部的 SELECT 語句必須擁有相同數量的列，列也必須擁有相似的資料型別。同時，每條 SELECT 語句中的列的順序必須相同.（多次sql語句取出的列名可以不一致，此時以第一個sql語句的列名為準）
註釋：UNION 用於合併兩個或多個 SELECT 語句的結果集，並消去表中任何重複行。如果允許重複的值，請使用 UNION ALL。
當 ALL 隨 UNION 一起使用時（即 UNION ALL），不消除重複行

我在使用的時候覺得又left join 又 right join 的，如果多表查詢結果拼接的話我怕自己寫著寫著就亂了，所以就想了一個我認為特別好理解又簡單的方式實現full join。不知道效率會不會比通用的替代sql高，但是至少不會低，主要是看著容易理解。A,B分別單表查詢出結果再拼接最容易出現明明是想顯示id,A.name,B.name三列，結果出來的卻只有兩列，這就是在A,B表分表進行單表查詢的時候select語句中
沒有為對方表中要顯示的欄位預留出對應的位置，所以被UNION到同一列去了。所以這種情況我們就需要在select語句中佔位，顯式增加一個值為0的列，這樣就能把A,B表的欄位區分到不同的列，注意：這個時候需要使用UNION ALL保留重複的行再根據需要保留的資料型別使用mysql中相對應的函式在group by id 的時候去掉佔位符0，保留你想要的結果即可。例：need_count 裡面放的是資料型別是數字型別，所以我選用求和函式sum( need_count )去掉0這個佔位符，留下我需要的資料。這樣就搞定了。

既然都說了並集，交集，乘集，那我也把差集的sql也說說，這個是沒有關鍵字的，同理也可以像FULL JOIN一樣用其他的關鍵字組合得到，直接上sql：

SELECT * FROM A LEFT JOIN B ON A.name = B.name
WHERE B.id IS NULL
union
SELECT * FROM A right JOIN B ON A.name = B.name
WHERE A.id IS NULL;

2.這個估計碰到的情況會更多。產品經理提需求的時候各種提要求說什麼為了使用者體驗這個頁面一定只能顯示滿足什麼條件什麼條件的資料（重點條件：已經截止的就不再顯示），不滿足的不顯示，結果出來一看，滿足條件的結果只有寥寥幾條整個頁面又空又醜，然後想了一下丟下一句：“如果結果不滿足20條，就取幾條已經截止的湊數，其他條件不變”之後揚長而去。這個時候我們要怎麼辦呢。難道每次取出符合條件的資料集都count一下，不滿20，然後差多少條就去資料庫裡再取一次只有‘已截止的不顯示’不符合其他條件符合的資料？這樣又要多查一次表，好像不太划算。那怎麼能一次查表按照順序先取出滿足條件的再取不滿足條件的20條資料呢？我做的時候是吧where語句中判斷該條資料是否已截止的條件刪除，在select語句中加入一個判斷是否截止的標誌欄位，然後放入order by中進行優先排序即可。sql語句如下：

select lt.id,lt.title,description,industry_id,lt.end_time,lt.time,lt.project_end_time,lt.budget,user.user,user.head_img,lt.bid, lt.home_recommended, if(lt.end_time - UNIX_TIMESTAMP(now())>0,1,0) as end_state 
from {{leader_task}} lt left join {{user}} user on lt.user_id=user.id where lt.finish!=3 and lt.examine=1
order by end_state desc, lt.home_recommended desc, lt.time desc, lt.bid asc

這樣就完美的完成了預期效果。

最後呢，給大家推薦一下我覺得寫的很好的部落格裡寫的如何提高mysql查詢速度的注意事項和方法
blog地址: http://blog.sina.com.cn/s/blog_61c9c41e0100v3m5.html
一下是我拷貝的人家文章的內容（非原創，只為了自己以後能方便查閱）
1.對查詢進行優化，應儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設定預設值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
3.應儘量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應儘量避免在 where 子句中使用 or 來連線條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查詢也將導致全表掃描：
select id from t where name like ‘%c%’
若要提高效率，可以考慮全文檢索。
7.如果在 where 子句中使用引數，也會導致全表掃描。因為SQL只有在執行時才會解析區域性變數，但優化程式不能將訪問計劃的選擇推遲到執行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where [email protected]
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where [email protected]
8.應儘量避免在 where 子句中對欄位進行表示式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9.應儘量避免在where子句中對欄位進行函式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)=’abc’–name以abc開頭的id
select id from t where datediff(day,createdate,’2005-11-30’)=0–‘2005-11-30’生成的id
應改為:
select id from t where name like ‘abc%’
select id from t where createdate>=’2005-11-30’ and createdate<’2005-12-1’
10.不要在 where 子句中的“=”左邊進行函式、算術運算或其他表示式運算，否則系統將可能無法正確使用索引。
11.在使用索引欄位作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓欄位順序與索引順序相一致。
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類程式碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(…)
13.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14.並不是所有索引對查詢都有效，SQL是根據表中資料來進行查詢優化的，當索引列有大量資料重複時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
16.應儘可能的避免更新 clustered 索引資料列，因為 clustered 索引資料列的順序就是表記錄的物理儲存順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引資料列，那麼需要考慮是否應將該索引建為 clustered 索引。
17.儘量使用數字型欄位，若只含數值資訊的欄位儘量不要設計為字元型，這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連線時會逐個比較字串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18.儘可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位儲存空間小，可以節省儲存空間，其次對於查詢來說，在一個相對較小的欄位內搜尋效率顯然要高些。
19.任何地方都不要使用 select * from t ，用具體的欄位列表代替“*”，不要返回用不到的任何欄位。
20.儘量使用表變數來代替臨時表。如果表變數包含大量資料，請注意索引非常有限（只有主鍵索引）。
21.避免頻繁建立和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重複引用大型表或常用表中的某個資料集時。但是，對於一次性事件，最好使用匯出表。
23.在新建臨時表時，如果一次性插入資料量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果資料量不大，為了緩和系統表的資源，應先create table，然後insert。
24.如果使用到了臨時表，在儲存過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
25.儘量避免使用遊標，因為遊標的效率較差，如果遊標操作的資料超過1萬行，那麼就應該考慮改寫。
26.使用基於遊標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27.與臨時表一樣，遊標並不是不可使用。對小型資料集使用 FAST_FORWARD 遊標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的資料時。在結果集中包括“合計”的例程通常要比使用遊標執行的速度快。如果開發時間允許，基於遊標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28.在所有的儲存過程和觸發器的開始處設定 SET NOCOUNT ON ，在結束時設定 SET NOCOUNT OFF 。無需在執行儲存過程和觸發器的每個語句後向客戶端傳送 DONE_IN_PROC 訊息。
29.儘量避免大事務操作，提高系統併發能力。
30.儘量避免向客戶端返回大資料量，若資料量過大，應該考慮相應需求是否合理。

至此，我想要記錄和說明的都表達完了，以後若發現什麼新的好玩的sql語句，我再回來繼續增加。希望小夥伴們多給一些意見，多多交流學習，感激不盡~（我要回去繼續敲程式碼了，最近工作忙到沒有時間把想跟大家一起分享交流的東西整理出來，等這段時間忙過去，一定回來好好整理。mark）

時隔這麼久，我回來繼續更新一下我在工作中用到的關於mysql的其他好玩的一氣呵成的用法：
No.1 MySQL自定義排序函式FIELD()
在之前做關聯搜尋的時候，需要對搜尋的關鍵詞進行切詞匹配，匹配結果的顯示規則是精準匹配的結果顯示優先順序最高，切詞結果越細，優先順序越低，這個匹配的結果邏輯我是在Java裡寫的，但是顯示的邏輯是在php中完成的，這個時候我是將排好序的資訊id陣列返回給PHP程式進行後續顯示邏輯使用。但是php程式執行結果與我想要的資訊排序結果不一致，原因就是php在執行原有的sql語句的時候排序按照初始的排序規則進行排序的，並不是指定順序的排序規則，那如何實現這樣的特定序列排序呢，這個時候就用得上mysql 的這個FIELD()函數了。那麼這個函式如何使用呢，我們來看field()函式的語法。
field(column,value1,value2,value3,……)
column代表要排序的列，value1…… 代表自定義的順序：order by field(type,2,3,1)就是按2在前，3次之，1最後的順序，這樣就實現了我們想要的效果了。
No.2 善用Mysql的Case…when…多條件判斷
在做需求的時候，我遇到了這麼一個需求，我要算使用者在一級分類下的行為積分，然後將文章根據使用者的分類積分從高到低排序顯示，但是文章的分類是按照最小一級分類儲存的。則在使用該分數進行排序的時候需要將最小一級分類轉化為第一級分類進行積分排序。最常用的做法是把資料先取出來用for迴圈將分數新增到每一條資料裡，然後再寫一個排序方法進行排序，最後輸出顯示。但是我覺得如果遇到需要分頁的情況下，每次都得這麼來一遍太費勁，如果能在mysql裡直接做完這一套就好了。這個時候case..when..就起了大作用了。那麼它是如何執行的呢，看下面這段程式碼就知道了：

public function sql_par($word_name,$type=0){//$type
        $this->init();
        if(!$this->isValid())
            return '';
        //建立自定義排序的權重引數
        $weight_sort = ', (CASE';
        foreach($this->class_weight as $p_id => $weight_score){
            $weight_sort .= " WHEN ".$word_name." in (".implode(',', $this->class_order[$p_id]).") THEN ".$weight_score." ";
        }
        $weight_sort .= "ELSE 0 END) as weight_sort ";
        return $weight_sort;
    }

    /**
     * 
     * @param number $type
     * @param string $sort_name原有排序積分,用來與weight_sort求和。
     * @return string
     */
    public function sql_order($type=0,$sort_name=''){//$type:0需求，1產品
        $this->init();
        if(!$this->isValid())
            return '';
        if($type){
            return ', (weight_sort + '.$sort_name.') desc';
        }else{
            return ', weight_sort desc';
        }
    }

    public function shop_list($origin_order='', $limit=''){
        $this->init();
        if(!$this->isValid())
            return '';
        $sql = "select * from (select * , sum(weight_sort) as total_score from (select shop.*".$this->sql_par('industry.industry_id')." from shopinformation shop left join btb_industry industry on shop.user_id = industry.user_id)b group by user_id)a order by ";
        if($origin_order != '')
            $sql .= $origin_order.',';
        $sql .= 'total_score desc limit '.$limit;
        return Yii::app()->db->createCommand($sql)->queryAll();

    }

在這裡可能會有人有疑問，為什麼(weight_sort + '.$sort_name.')求和我要放到order by裡面去執行呢，這個是跟mysql 的語句執行順序有關的。weight_sort這個別名生效是再select語句執行完成之後執行的，所以如果把(weight_sort + '.$sort_name.')求和放到select語句中當作欄位使用，則mysql會報找不到weight_sort這個column的錯誤。在此注意一下。

No.3 改寫yii中原有的queryPage方法適配複雜的sql語句進行分頁顯示（懶人創造世界之一）、
改寫queryPage方法的初衷是為了不要多寫分頁的程式碼，使查詢出來的資料可以直接複用原來的分頁邏輯。一句話就是：懶得寫。所以就誕生了這個克隆兄弟，嗯，雖然和他原來的樣子差的有點大，但是效果是一樣的就夠了~程式碼如下：

//原來的queryPage方法
/**
     * query current page
     * @param integer $pageSize page size
     * @param CActiveRecord $model table model
     * @param mixed $condition query condition or criteria.
     * @param array $params parameters to be bound to an SQL statement.
     */
    function queryPage($pageSize,$model,$fields,$condition='',$params=array(),$orderby = "",$leftjoin = "", $joinon = ""){//分頁
        $result = Yii::app()->db->createCommand()->select("count(*)")->from($model->tableName());
        if(!is_array($leftjoin) && strlen($leftjoin)!=0)
            $result = $result->leftJoin($leftjoin, $joinon);
        else if(is_array($leftjoin)){
            for($i = 0; $i < count($leftjoin); $i++){
                $result = $result->leftJoin($leftjoin[$i], $joinon[$i]);
            }
        }
        $result = $result->where($condition,$params);
        $rowCount = $model->countBySql($result->getText(),$params);
        $criteria=new CDbCriteria();
        $pages=new CPagination($rowCount);
        $pages->pageSize=$pageSize;
        $pages->applyLimit($criteria);
        $result = Yii::app()->db->createCommand()->select($fields)->from($model->tableName());
        if(!is_array($leftjoin) && strlen($leftjoin)!=0)
            $result = $result->leftJoin($leftjoin, $joinon);
        else if(is_array($leftjoin)){
            for($i = 0; $i < count($leftjoin); $i++){
                $result = $result->leftJoin($leftjoin[$i], $joinon[$i]);
            }
        }
        $result = $result->where($condition,$params)->order($orderby)->limit($pages->pageSize,$pages->currentPage*$pages->pageSize);
        $posts = $result->query();
        $page['posts']=$posts;
        $page['pages']=$pages;
        $page['zs']=$pages->itemCount;
        return $page;
    }

我修改之後的queryPage方法：

/**
     * query current page
     * @param integer $pageSize page size
     * @param CActiveRecord $model table model
     * @param mixed $condition query condition or criteria.
     * @param array $params parameters to be bound to an SQL statement.
     */
    public function queryPage($pageSize,$where='',$params=array(),$orderby = ""){//分頁
        $this->init();
        if(!$this->isValid())
            return '';
        $sql = "select count(*) from btb_shop_information where ".$where;
        $result = Yii::app()->db->createCommand($sql)->select();
        $rowCount = ShopInformation::model()->countBySql($result->getText(),$params);
        $criteria=new CDbCriteria();
        $pages=new CPagination($rowCount);
        $pages->pageSize=$pageSize;
        $pages->applyLimit($criteria);
        $sql1 = "select information.*,user.user_type from (select * , sum(weight_sort) as total_score from (select shop.*".$this->sql_par('industry.id')." from shop left join btb_industry industry on shop.user_id = industry.user_id)b group by id)information left join user on user.id = information.user_id where ".$where." order by ";
        $sql1 .= '(total_score+information.sort_integral) desc limit '.$pages->currentPage*$pages->pageSize.','.$pages->pageSize;
        $result = Yii::app()->db->createCommand($sql1);
        $posts = $result->queryAll();
        $page['posts']=$posts;
        $page['pages']=$pages;
        $page['zs']=$pages->itemCount;
        return $page;
    }

ps：在改造後的方法使用時，$posts= $Page['posts']->readAll();改為$posts= $Page['posts']; 其餘一樣使用即可。
後續再有新的內容再新增~（修改日期為2018/5/23）