溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“MySQL必須了解的關鍵字有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL必須了解的關鍵字有哪些”吧!
第一范式：每個表的每一列都要保持它的原子性，也就是表的每一列是不可分割的；
第二范式：在滿足第一范式的基礎上，每個表都要保持唯一性，也就是表的非主鍵字段完全依賴于主鍵字段；
第三范式：在滿足第一范式和第二范式的基礎上，表中不能產生傳遞關系，要消除表中的冗余性；
字符集規定了字符在數據庫中的存儲格式，比如占多少空間，支持哪些字符等等。不同的字符集有不同的編碼規則，在有些情況下，甚至還有校對規則的存，校對規則是指一個字符集的排序，在運維和使用MySQL數據庫中，選取合適的字符集非常重要，如果選擇不恰當，輕則影響數據庫性能，嚴重的可能導致數據存儲亂碼。
常見的MySQl字符集主要有以下四種：
| 字符集 | 長度 | 說明 |
|---|---|---|
| GBK | 2 | 支持中文，但不是國際通用字符集 |
| UTF-8 | 3 | 支持中英文混合場景，是國際通用字符集 |
| latin1 | 1 | MySQL默認字符集 |
| utf8mb4 | 4 | 完全兼容UTF-8，用四個字節存儲更多的字符 |
MySQL數據庫在開發運維中，字符集選用規則如下：
如果系統開發面向國外業務，需要處理不同國家、不同語言，則應該選擇utf-8或者utf8mb4；
如果只需要支持中文，沒有國外業務，則為了性能考慮，可以采用GBK；
自定義變量是一個用來存儲內容的臨時容器，在連接MySQL的整個過程中都存在。可以使用set的方式定義。
SET @last_week := CURRENT_DATE-INTERVAL 1 WEEK;SELECT id,name from user where create_time > @last_week;
使用自定義變量的注意事項：
使用自定義變量的查詢，無法使用緩存；
不能在使用常量或標識符的地方使用自定義變量，比如表名、列名和limit子句中；
自定義變量的生命周期實在一個連接中有效，不能用它們做連接間的通信；
避免重復查詢剛剛更新的數據
如果在更新行的同時又想獲得該行的信息，要怎么做才能避免重復的查詢呢？
一般都這樣做：
update user set update_time = now() where id = 1;select update_time from user where id = 1;
使用自定義變量可以對其進行優化：
看上去還是兩個查詢，但是第二次查詢無須訪問任何數據表，所以會快很多。update user set update_time = now() where id = 1 and @now := now();select @now;
MySQL支持的數據類型非常多，選擇正確的數據類型對于獲得高性能至關重要。
一般情況下，應該盡量使用較小的數據類型，更小的數據類型通常更快，因為占用更少的磁盤、內存和CPU緩存，處理時需要的CPU周期更短。
簡單的數據類型通常需要更少的CPU周期，整形比字符串類型代價更低，因為字符集和校驗規則使字符比較比整形比較更復雜。
很多表都包含可為NULL的列，即使應用程序并不需要保存NULL也是如此，因為可為NULL是列的默認屬性，通常情況下，最好指定列為NOT NULL。
如果查詢中包含可為NULL的列，對MySQL來說更難優化，因為可為NULL的列使索引、索引統計和值的比較都更復雜。可為NULL的列會使用更多的存儲空間，在MySQL里也需要特殊處理，可為NULL的列被索引時，每個索引記錄需要一個額外的字節，在MyISAM里甚至還可能導致固定大小的索引變成可變大小的索引。
視圖（view）是一種虛擬存在的表，是一個邏輯表，本身并不包含數據。作為一個select語句保存在數據字典中的。對多張表的復雜查詢，使用視圖可以簡化查詢，當視圖使用臨時表時，無法使用where條件，也不能使用索引。
單表視圖一般用于查詢和修改，會改變基本表的數據，多表視圖一般用于查詢，不會改變基本表的數據。
使用視圖的目的是為了保障數據安全性，提高查詢效率。
使用視圖的用戶完全不需要關心后面對應的表的結構、關聯條件和篩選條件，對用戶來說已經是過濾好的復合條件的結果集。
使用視圖的用戶只能訪問他們被允許查詢的結果集，對表的權限管理并不能限制到某個行某個列，但是通過視圖就可以簡單的實現。
一旦視圖的結構確定了，可以屏蔽表結構變化對用戶的影響，源表增加列對視圖沒有影響；源表修改列名，則可以通過修改視圖來解決，不會造成對訪問者的影響。
有時提升性能最好的方法是在同一張表中保存衍生的冗余數據，有時候還需要創建一張完全獨立的匯總表或緩存表。
緩存表用來存儲那些獲取很簡單，但速度較慢的數據；
匯總表用來保存使用group by語句聚合查詢的數據；
對于緩存表，如果主表使用InnoDB，用MyISAM作為緩存表的引擎將會得到更小的索引占用空間，并且可以做全文檢索。
在使用緩存表和匯總表時，必須決定是實時維護數據還是定期重建。哪個更好依賴于應用程序，但是定期重建并不只是節省資源，也可以保持表不會有很多碎片，以及有完全順序組織的索引。
當重建匯總表和緩存表時，通常需要保證數據在操作時依然可用，這就需要通過使用影子表來實現，影子表指的是一張在真實表背后創建的表，當完成了建表操作后，可以通過一個原子的重命名操作切換影子表和原表。
為了提升讀的速度，經常建一些額外索引，增加冗余列，甚至是創建緩存表和匯總表，這些方法會增加寫的負擔媽也需要額外的維護任務，但在設計高性能數據庫時，這些都是常見的技巧，雖然寫操作變慢了，但更顯著地提高了讀的性能。
通常情況下，同一張表的數據在物理層面都是存放在一起的。隨著業務增長，當同一張表的數據量過大時，會帶來管理上的不便。而分區特性可以將一張表從物理層面根據一定的規則將數據劃分為多個分區，多個分區可以單獨管理，甚至存放在不同的磁盤/文件系統上，提升效率。
數據可以跨磁盤存儲，適合存儲大量數據；
數據管理起來很方便，以分區為單位操作數據，不影響其他分區的正常運行；
查詢時可以通過鎖定分區的特性，縮小查詢范圍，提高查詢性能；
外鍵通常都要求每次在修改數據時都要在另外一張表中進行一次額外的查詢操作，雖然InnoDB強制外鍵使用索引，但還是無法消除這種約束檢查的開銷。如果外鍵的選擇性很低，則會導致一個選擇性很低的索引。
不過在某些場景下，外鍵會提升一些性能，比如想確保兩個相關表始終有一致的數據，那么使用外鍵比在應用程序中檢查一致性的性能要高的多，此外。外鍵在相關數據的刪除和更新上，也比在應用中維護要更高效，不過，外鍵維護操作時逐行進行的，這樣的更新會比批量刪除和更新要慢些。
外鍵約束使查詢時額外訪問一些別的表，也就是需要額外的鎖。如果向子表中寫入一條記錄，外鍵約束會讓InnoDB檢查對應的父表的記錄，也就是需要對父表的對應記錄進行加鎖操作，來確保這條記錄不會在這個事務完成之時就被刪除了。這會導致額外的鎖等待，甚至會導致一些死鎖。因為沒有直接訪問這些表，所以這類死鎖問題很難排查。
所以，在目前的很多項目中，為了性能的考慮，已經不使用外鍵了。
MySQL查詢緩存保存查詢返回的完整結果，當查詢命中該緩存，MySQL會立刻返回結果，跳過解析、優化和執行過程。
查詢緩存系統會跟蹤查詢中涉及的每個表，如果這些表發生變化，那么和這個表相關的所有的緩存數據都將失效，這種機制效率看起來比較低，因為數據表變化時可能對查詢結果并沒有影響，但是這種簡單實現代價很小，而這點對于一個非常繁忙的系統來說非常重要。
判斷是否命中時，MySQL不會解析，而是直接使用SQL語句和客戶端發送過來的其它原始信息。任何字符上的不同，例如空格、注釋，丟回導致緩存的不命中。通常使用統一的編碼規則是一個好的習慣，會讓你的系統運行的更快。
當查詢語句中有一些不確定的數據時，不會被緩存，比如函數now()。實際上，如果緩存中包含任何用戶自定義函數、存儲函數、用戶變量、臨時表、MySQL系統表、或者任何包含列級別權限的表，都不會被緩存。
打開查詢緩存對讀和寫操作都會帶來額外的消耗：
讀查詢在執行之前要先檢查是否命中緩存；
如果讀查詢可以被緩存，那么當完成執行后，MySQL如果發現緩存中沒有這個查詢，會將其結果存入查詢緩存，這會帶來額外的系統消耗；
對寫操作也有影響，因為當向某個表寫入數據的時候，MySQL必須將對應表的所有緩存設置失效。如果查詢緩存非常大或者碎片很多，這個操作就可能會帶來很大的系統消耗；
雖然如此，查詢緩存仍然會給系統帶來性能的提升。但是，上述的額外消耗也可能不斷增加，再加上對查詢緩存操作是一個加鎖排它操作，這個消耗也不小。
對InnoDB用戶來說，事務的一些特性會限制查詢緩存的使用。當一個語句在事務中修改了某個表，在事務提交前，MySQL都會將這個表對應的查詢緩存設置失效，因此，長時間運行的事務，會大大降低查詢緩存的命中率。
存儲過程是一組為了完成特定功能的SQL 語句集合，經編譯后保存在數據庫中，通過指定存儲過程的名字并給出參數的值，也可以返回結果。
減少網絡流量
提高執行速度
減少數據庫連接次數
安全性高
復用性高
可移植性差
事務內的語句，要么全執行，要么全不執行。事務具有ACID特性，ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）、持久性（durability）。
一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要么全執行提交成功，要么全不失敗回滾。
數據庫總是從一個一致性的狀態轉換到另一個一致性的狀態。
一個事務所做的修改在最終提交以前，對其它事務是不可見的。
事務一旦提交，則七所做的修改就會永久的保存在數據庫中。
索引是存儲引擎用于快速查找記錄的一種數據結構。我覺得數據庫中最重要的知識點，就是索引。
存儲引擎以不同的方式使用B-Tree索引，性能也各有不同，各有優劣。例如MyISAM使用前綴壓縮技術使得索引更小，但InnoDB則按照原數據格式進行存儲。MyISAM索引通過數據的物理位置引用被索引的行，而InnoDB則根據主鍵引用被索引的行。
B-Tree通常意味著所有的值都是按順序存儲的，并且每一個葉子頁到根的距離相同。
B-Tree索引能夠加快訪問數據的速度，因為存儲引擎不再需要進行全表掃描來獲取需要的數據，取而代之的是從索引的根結點開始進行搜索。根結點的槽中存放了指向子結點的指針，存儲引擎根據這些指針向下層查找。通過比較節點頁的值和要查找的值可以找到合適的指針進入下層子節點，這些指針實際上定義了子節點頁中值的上限和下限。最終存儲引擎要么找到對應的值，要么該記錄不存在。
葉子節點比較特別，它們的指針指向的是被索引的數據，而不是其他的節點頁。B-Tree對索引列是順序組織存儲的，所有很適合查找范圍數據。B-Tree適用于全鍵值、鍵值范圍或鍵前綴查找。
因為索引樹中的節點是有序的，所以除了按值查找之外，索引還可以用于查詢中的order by操作。一般來說，如果B-Tree可以按照某種方式查找到值，那么也可以按照這種方式用于排序。
全文索引的目的是 通過關鍵字的匹配進行查詢過濾，基于相似度的查詢，而不是精確查詢。
全文索引利用分詞技術分析出文字中某關鍵字的頻率和重要性，并按照一定的算法智能的篩選出我們想要的結果。
全文索引一般用于字符串中某關鍵字的查詢，比如char、varchar、text，也支持自然語言全文索引和布爾全文索引。
到此，相信大家對“MySQL必須了解的關鍵字有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
