聯(lián)結

SQL最強大的功能之一就是能在數(shù)據(jù)檢索查詢的執(zhí)行中聯(lián)結表；

關系表

為什么要使用關系表？

• 使用關系表可以儲存數(shù)據(jù)不重復，從而不浪費時間和空間；
• 如果有數(shù)據(jù)信息變動，只需更新一個表中的單個記錄，相關表中的數(shù)據(jù)不用改動；
• 由于數(shù)據(jù)無重復，顯然數(shù)據(jù)是一致的，這使得處理數(shù)據(jù)更簡單。

總之，關系表可以有效低存儲和方便的處理，因此，關系數(shù)據(jù)庫的可伸縮性遠比非關系數(shù)據(jù)庫要好。

可伸縮性：能夠適應不斷增加的工作量而不失敗。涉及良好的數(shù)據(jù)庫或應用程序稱之為可伸縮性好；?

這是一個例子，他找出了群號為49289306112的群里面的所有群聊成員；

在使用聯(lián)結查詢的時候，一定要有where語句，如果沒有的話就會輸出巨多的沒用的數(shù)據(jù)，有了where語句還不行，還要保證where語句的準確性，如果你的where語句不準確的話，不正確的過濾條件將導致MySQL返回不正確的數(shù)據(jù)；

除了上面的語法，還有一種寫法，能夠實現(xiàn)一樣的功能；

?這里與前面的區(qū)別就是FROM子句不同，這里，兩個表之間的關系是from子句的組成部分，以INNER JOIN指定。在使用這種語法時，聯(lián)結條件用特定的ON子句而不是WHERE子句給出。傳遞ON的實際條件與傳遞給WHERE的相同。

至于這兩種語法選擇哪一種，ANSI SQL規(guī)范首選INNER JOIN語法，此外，盡管使用WHERE子句定義聯(lián)結的確比較簡單，但是使用明確的聯(lián)結語法能夠確保不會忘記聯(lián)結條件，有時候這樣做也能影響性能；

聯(lián)結多個表

SQL對一條SELECT語句中可以聯(lián)結的表的數(shù)目沒有限制。創(chuàng)建聯(lián)結的基本規(guī)則也相同，都是先列出所有表，然后定義表之間的關系；

性能考慮：MySQL在運行時對聯(lián)結表的處理時非常的耗費資源的，因此不要聯(lián)結不必要的表，聯(lián)結的表越多，性能下降越厲害。

?在之前的學習中我們學習了子查詢，子查詢和聯(lián)結都能達到目的，但是他們兩個不是說哪個一定好，這個要看情況而定；

創(chuàng)建高級聯(lián)結

?之前學習的AS可以為列創(chuàng)建別名，但是其實AS也能夠給表建立別名；

注意：表別名只在查詢執(zhí)行中使用。與列別名不一樣，表別名不返回到客戶機。

聯(lián)結使用的某些要點

• 注意所使用的聯(lián)結類型，一般我們使用內部聯(lián)結，但使用外部聯(lián)結也是有效的。
• 保證使用正確的聯(lián)結條件，否則會返回不正確的數(shù)據(jù)。
• 應該總是提取聯(lián)結條件，否者會得出迪卡爾積。（兩個表的所有組合情況，大量數(shù)據(jù)）
• 在一個聯(lián)結中可以包含多個表，甚至對于每個聯(lián)結可以采用不同的聯(lián)結類型。雖然這樣做是合法的，一般也很有用，但是應該在一起測試它們之前，分別測試每個聯(lián)結。這樣可以使得故障排除更為簡單。

組合查詢

組合查詢就是利用UNION操作符將多條select語句組合成一個結果集

在下面兩個基本情況里面要用到組合查詢：

• 在單個查詢中從不同的表返回類似結構的數(shù)據(jù)；
• 對單個表執(zhí)行多個查詢，按單個查詢返回數(shù)據(jù)；

?在寫qq聊天室項目時，我用到了組合查詢，因為在好友關系表里面A是B的好友，那么B也是A的好友，所以在查詢時，我們即要查看自己在A時有多少個B好友，又要查找自己為B時有多少給A好友；

這個UNION就是查詢了存款大于2000和年齡小于19的結果；

UNION使用規(guī)則：

• UNION必須由兩條或者兩條以上的select語句組成，語句之間用關鍵字UNION分隔（因此，如果組合四條select語句，就要使用3個UNION語句）。
• UNION的每個查詢必須包含相同的列，表達式或者聚集函數(shù)（不過各個列不需要以相同的次序列出）
• 列數(shù)據(jù)類型必須兼容；類型不必完全相同，但必須時DBMS可以隱含的轉換的類型（例如：不同的數(shù)值或不同的日期類型）。

?小細節(jié)：

使用UNION時，它會默認將多條select語句查詢到的重復的行去重，所以在使用UNION時，重復的行會被去除，但是我們需要的話，也可以使用UNION ALL來獲得所有的匹配行；

當我們想要對組合查詢結果進行排序的時候，只能使用一條ORDER BY子句，它必須出現(xiàn)在最后一條select語句之后，對于結果集，不存在用一種方式排序一部分，而又用另一種方式排序寧一部分的情況，因此不允許使用多條ORDER BY語句；

上面的例子中的組合查詢使用的均是demo1表，但是UNION可以用于組合查詢不同的表；

全文本搜索

并非所有的引擎都支持全文本搜索，兩個最常用的引擎為MyISAM和InnoDB，前者支持全文本搜索，而后者不支持。

在之前我們學習了使用LIKE和通配符來搜索文本，還有REGEXP操作符后面加正則表達式來搜索行；雖然這些搜索機制很有用，但是存在幾個重要的限制：

• 性能——通配符和正則表達式匹配通常要求MySQl嘗試匹配表中所有行（而且這些搜索極少使用表索引）。因此，由于被搜索行數(shù)不斷增加，這些搜索可能會非常耗時；
• 明確控制——使用通配符和正則表達式匹配，很難（而且并不總是能）明確地控制匹配什么和不匹配什么。例如，指定一個詞必須匹配，一個詞必須不匹配，而一個詞僅在第一個詞確實匹配的情況下才可以匹配或者才可以不匹配。
• 智能化的結果——雖然基于通配符和正則表達式的搜索提供了非常靈活的搜索，但是它們都不能提供一種智能化的選擇結果的方法。例如，一個特殊值的搜索會返回包含該詞的所有行，而不區(qū)分包含單個匹配的行和包含多個匹配的行（按照可能是更好的匹配來排列它們）。類似，一個特殊詞的搜索將不會找出不包含該詞但是包含其他相關詞的行。

?首先，我們先建一個表：

?這里FULLTEXT（note_text）?表示將note_text設置為全文本查找的字段；

然后就是插入數(shù)據(jù)：

?然后首先測試like模糊查詢

?查詢結果分析：應為like模糊查詢是在整個數(shù)據(jù)中查看有沒有包含'fiction'這個單詞的，如果有就過濾出來，而在我插入的數(shù)據(jù)中，1和5是有的；

?然后再是全文本搜索

結果：

再測試全文本搜索-布爾文本搜索

?在全文本搜索中常用的布爾運算符

結果：

?使用擴展查詢

?這個會根據(jù)包含fiction的兩條行中的數(shù)據(jù)中的其他單詞來對其他行進行匹配，相當與找到了正確答案還要找與正確答案類似的答案；

結果：

?全文本搜索-顯示排名字段，按照匹配度由高到低排序

?結果：

?細節(jié)：Match( )和Against( )出現(xiàn)的位置對結果的影響較大，當Match( )和Against( )出現(xiàn)在where子句中時，只會返回匹配到的行，但是如果Match( )和Against( )出現(xiàn)在SELECT中的話，就會使得所有的行全部被返回，Match( )和Against( )用來建立一個計算列（別名為rank），此列包含全文本搜索計算出的等級值。等級由MySQL根據(jù)行中詞的數(shù)目，唯一詞的數(shù)目，整個索引中詞的總數(shù)以及包含該詞的行的數(shù)目計算出來，并且這個值還與唯一詞所處的位置有關，唯一詞靠前的值較高，靠后的值較低。