MySQL_基礎知識

-----基礎知識

一、什麼是數據庫？

    數據庫(Database)是按照數據結構來組織、存儲和管理數據的倉庫

 

二、什麼是關係型數據庫、主鍵，外鍵，索引分別是什麼？

        關係型數據庫是由多張能互相聯接的二維行列表格組成的數據庫

       主關鍵字(primary key)是表中的一個或多個字段，它的值用於惟一地標識表中的某一條記錄

       外鍵表示了兩個關係之間的相關聯繫。以另外一個關係的外鍵做主關鍵字的表被稱爲主表，具備此外鍵的表被稱爲主表的從表。外鍵又稱做外關鍵字

       在關係數據庫中，索引是一種單獨的、物理的對數據庫表中一列或多列的值進行排序的一種存儲結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單

 

三、表的連接查詢方式有那些，有什麼區別？

        交叉鏈接即笛卡兒乘積，是指兩個關係中全部元組的任意組合

       使用內鏈接時，若是兩個表的相關字段知足鏈接條件，就從這兩個表中提取數據並組合成新的記錄

       自鏈接是一種特殊的內鏈接，它是指相互鏈接的表在物理上爲同一張表，但能夠在邏輯上分爲兩張表

       外鏈接是隻限制一張表中的數據必須知足鏈接條件，而另外一張表中的數據能夠不知足鏈接條件的鏈接方式

 

四、SQL的select語句完成的執行順序？

      一、from 子句組裝來自不一樣數據源的數據；

      二、where 子句基於指定的條件對記錄行進行篩選；

　  三、group by 子句將數據劃分爲多個分組；

     四、使用匯集函數進行計算；

     五、使用 having 子句篩選分組；

     六、計算全部的表達式；

     七、select 的字段；

     八、使用 order by 對結果集進行排序。

 

五、MySQL數據庫存儲的原理？

       儲存過程是一個可編程的函數，它在數據庫中建立並保存。它能夠有 SQL 語句和一些特殊的控制結構組成。當但願在不一樣的應用程序或平臺上執行相同的函數，或者封裝特定功能時，存儲過程是很是有用的。數據庫中的存儲過程能夠看作是對編程中面向對象方法的模擬。它容許控制數據的訪問方式。存儲過程一般有如下優勢：

       一、存儲過程能實現較快的執行速度

　    二、存儲過程容許標準組件是編程。

　　三、存儲過程能夠用流程控制語句編寫，有很強的靈活性，能夠完成複雜的判斷和較複雜的運算。

　　四、存儲過程可被做爲一種安全機制來充分利用。

　　五、存儲過程可以減小網絡流量

 

六、事務的特性？

　    一、原子性(Atomicity)：事務中的所有操做在數據庫中是不可分割的，要麼所有完成，要麼均不執行。

　　二、一致性(Consistency)：幾個並行執行的事務，其執行結果必須與按某一順序串行執行的結果相一致。

　　三、隔離性(Isolation)：事務的執行不受其餘事務的干擾，事務執行的中間結果對其餘事務必須是透明的。

　　四、持久性(Durability)：對於任意已提交事務，系統必須保證該事務對數據庫的改變不被丟失，即便數據庫出現 故障

 

七、數據庫索引？

       數據庫索引，是數據庫管理系統中一個排序的數據結構，以協助快速查詢、更新數據庫表中數據。索引的實現一般使用 B_TREE。B_TREE 索引加速了數據訪問，由於存儲引擎不會再去掃描整張表獲得須要的數據；相反，它從根節點開始，根節點保存了子節點的指針，存儲引擎會根據指針快速尋找數據。

 

八、數據庫怎麼優化查詢效率？

　　一、儲存引擎選擇：若是數據表須要事務處理，應該考慮使用 InnoDB，由於它徹底符合 ACID 特性。若是不須要事務處理，使用默認存儲引擎 MyISAM 是比較明智的

　　二、分表分庫，主從。

　　三、對查詢進行優化，要儘可能避免全表掃描，首先應考慮在 where 及 order by 涉及的列上創建索引

　　四、應儘可能避免在 where 子句中對字段進行 null 值判斷，不然將致使引擎放棄使用索引而進行全表掃描

　　五、應儘可能避免在 where 子句中使用!= 或<> 操做符，不然將引擎放棄使用索引而進行全表掃描

　　六、應儘可能避免在 where 子句中使用 or 來鏈接條件，若是一個字段有索引，一個字段沒有索引，將致使引擎放棄使用索引而進行全表掃描

　　七、Update 語句，若是隻更改 一、2 個字段，不要 Update 所有字段，不然頻繁調用會引發明顯的性能消耗，同時帶來大量日誌

　　八、對於多張大數據量（這裏幾百條就算大了）的表 JOIN，要先分頁再 JOIN，不然邏輯讀會很高，性能不好。

 

九、你用的Mysql是哪一個引擎，各引擎之間有什麼區別？

      主要 MyISAM 與 InnoDB 兩個引擎，其主要區別以下：InnoDB 支持事務，MyISAM 不支持，這一點是很是之重要。事務是一種高級的處理方式，如在一些列增刪改中只要哪一個出錯還能夠回滾還原，而 MyISAM 就不能夠了；

MyISAM 適合查詢以及插入爲主的應用，InnoDB 適合頻繁修改以及涉及到安全性較高的應用；

InnoDB 支持外鍵，MyISAM 不支持；

MyISAM 是默認引擎，InnoDB 須要指定；

InnoDB 不支持 FULLTEXT 類型的索引；

InnoDB 中不保存表的行數，如 select count() from table 時，InnoDB；須要掃描一遍整個表來計算有多少行，可是 MyISAM 只要簡單的讀出保存好的行數便可。注意的是，當 count()語句包含 where 條件時 MyISAM 也須要掃描整個表；

       對於自增加的字段，InnoDB 中必須包含只有該字段的索引，可是在 MyISAM 表中能夠和其餘字段一塊兒創建聯合索引；清空整個表時，InnoDB 是一行一行的刪除，效率很是慢。MyISAM 則會重建表；

InnoDB 支持行鎖（某些狀況下仍是鎖整表，如 update table set a=1 where user like '%lee%'

 

 

十、如何對查詢命令進行優化？

　　a. 應儘可能避免全表掃描，首先應考慮在 where 及 order by 涉及的列上創建索。

　　b. 應儘可能避免在 where 子句中對字段進行 null 值判斷，避免使用!=或<>操做符，避免使用 or 鏈接條件，或在 where 子句中使用參數、對字段進行表達式或函數操做，不然會致使權標掃描

　　c. 不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。

　　d. 使用索引字段做爲條件時，若是該索引是複合索引，那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引，不然該索引將不會被使用。

　　e. 不少時候可考慮用 exists 代替 in。

　　f. 儘可能使用數字型字段。

　　g. 儘量的使用 varchar/nvarchar 代替 char/nchar。

　　h. 任何地方都不要使用 select from t ，用具體的字段列表代替「」 ，不要返回用不到的任何字段。

　　i. 儘可能使用表變量來代替臨時表。

　　j. 避免頻繁建立和刪除臨時表，以減小系統表資源的消耗。

　　k. 儘可能避免使用遊標，由於遊標的效率較差。

　　l. 在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF。

　　m. 儘可能避免大事務操做，提升系統併發能力。

　　n. 儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

 

十一、數據庫的優化？

　　1.優化索引、SQL 語句、分析慢查詢；

　　2.設計表的時候嚴格根據數據庫的設計範式來設計數據庫；

　　3.使用緩存，把常常訪問到的數據並且不須要常常變化的數據放在緩存中，能節約磁盤 IO

　　4.優化硬件；採用 SSD，使用磁盤隊列技術(RAID0,RAID1,RDID5)等

　　5.採用 MySQL 內部自帶的表分區技術，把數據分層不一樣的文件，可以提升磁盤的讀取效率；

　　6.垂直分表；把一些不常常讀的數據放在一張表裏，節約磁盤 I/O；

　　7.主從分離讀寫；採用主從複製把數據庫的讀操做和寫入操做分離開來；

　　8.分庫分表分機器（數據量特別大），主要的的原理就是數據路由；

　　9.選擇合適的表引擎，參數上的優化

　　10.進行架構級別的緩存，靜態化和分佈式；

　　11.不採用全文索引；

　　12.採用更快的存儲方式，例如 NoSQL 存儲常常訪問的數據。

 

十二、Sql注入是如何產生的，如何防止？

       程序開發過程當中不注意規範書寫sql 語句和對特殊字符進行過濾，致使客戶端能夠經過全局變量POST 和GET

提交一些 sql 語句正常執行。產生 Sql 注入。下面是防止辦法：

　　a. 過濾掉一些常見的數據庫操做關鍵字，或者經過系統函數來進行過濾。

　　c. SQL 語句書寫的時候儘可能不要省略小引號(tab 鍵上面那個)和單引號

　　d. 提升數據庫命名技巧，對於一些重要的字段根據程序的特色命名，取不易被猜到的

　　e. 對於經常使用的方法加以封裝，避免直接暴漏 SQL 語句

　　g. 打開 magic_quotes_gpc 來防止 SQL 注入

　　h. 控制錯誤信息：關閉錯誤提示信息，將錯誤信息寫到系統日誌。

　　i. 使用 mysqli 或 pdo 預處理。

 

1三、NoSQL 和關係數據庫的區別？

　　a. SQL 數據存在特定結構的表中；而 NoSQL 則更加靈活和可擴展，存儲方式能夠省是 JSON 文檔、哈希表或者其餘方式。

　　b. 在 SQL 中，必須定義好表和字段結構後才能添加數據，例如定義表的主鍵(primary key)，索引(index),觸發器(trigger),存儲過程(stored procedure)等。表結構能夠在被定義以後更新，可是若是有比較大的結構變動的話就會變得比較複雜。在 NoSQL 中，數據能夠在任什麼時候候任何地方添加，不須要先定義表。

　　c. SQL 中若是須要增長外部關聯數據的話，規範化作法是在原表中增長一個外鍵，關聯外部數據表。而在NoSQL 中除了這種規範化的外部數據表作法之外，咱們還能用以下的非規範化方式把外部數據直接放到原數據集中，以提升查詢效率。缺點也比較明顯，更新審覈人數據的時候將會比較麻煩。

　　d. SQL 中可使用 JOIN 表連接方式將多個關係數據表中的數據用一條簡單的查詢語句查詢出來。

NoSQL 暫未提供相似 JOIN 的查詢方式對多個數據集中的數據作查詢。因此大部分 NoSQL 使用非規範化的數據存儲方式存儲數據。

　　e. SQL 中不容許刪除已經被使用的外部數據，而 NoSQL 中則沒有這種強耦合的概念，能夠隨時刪除任何數據。

　　f. SQL 中若是多張表數據須要同批次被更新，即若是其中一張表更新失敗的話其餘表也不能更新成功。這種場景能夠經過事務來控制，能夠在全部命令完成後再統一提交事務。而 NoSQL 中沒有事務這個概念，每個數據集的操做都是原子級的。

　　g. 在相同水平的系統設計的前提下，由於 NoSQL 中省略了 JOIN 查詢的消耗，故理論上性能上是優於 SQL 的。

 

1四、MySQL和MongoDB 本質之間最基本的差異是什麼？

      差異在多方面，例如：數據的表示、查詢、關係、事務、模式的設計和定義、速度和性能。MongoDB 是由 C++語言編寫的，是一個基於分佈式文件存儲的開源數據庫系統。在高負載的狀況下，添加更多的節點，能夠保證服務器性能。

      MongoDB 旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。

      MongoDB 將數據存儲爲一個文檔，數據結構由鍵值(key=>value)對組成。MongoDB 文檔相似於 JSON 對象。字段值能夠包含其餘文檔，數組及文檔數組。

      MongoDB 是一個面向文檔的數據庫，目前由 10gen 開發並維護，它的功能豐富齊全，因此徹底能夠替代MySQL。

      與 MySQL 等關係型數據庫相比，MongoDB 的優勢以下：

          ①弱一致性，更能保證用戶的訪問速度。

          ②文檔結構的存儲方式，可以更便捷的獲取數據。

          ③內置 GridFS，支持大容量的存儲。

          ④內置 Sharding。

          ⑤第三方支持豐富。(這是與其餘的 NoSQL 相比，MongoDB 也具備的優點)

          ⑥性能優越：

      MongoDB 自己它還算比較年輕的一個產品，因此它的問題，就是成熟度確定沒有傳統 MySQL 那麼成熟穩定。因此在使用的時候：

      儘可能使用穩定版，不要在線上使用開發版，這是一個大原則；

      另一點，備份很重要，MongoDB 若是出現一些異常狀況，備份必定是要能跟上。除了經過傳統的複製的方式來作備份，離線備份也仍是要有，無論你是用什麼方式，都要有一個完整的離線備份。每每最後出現了特殊狀況，它能幫助到你；另外，MongoDB 性能的一個關鍵點就是索引，索引是否是能有比較好的使用效率，索引是否是可以放在內存中，這樣可以提高隨機讀寫的性能。若是你的索引不能徹底放在內存中，一旦出現隨機讀寫比較高的時候，它就會頻繁地進行磁盤交換，這個時候，MongoDB 的性能就會急劇降低，會出現波動。

      另外，MongoDB 還有一個最大的缺點，就是它佔用的空間很大，由於它屬於典型空間換時間原則的類型。那麼它的磁盤空間比普通數據庫會浪費一些，並且到目前爲止它尚未實如今線壓縮功能，在 MongoDB 中頻繁的進行數據增刪改時，若是記錄變了，例如數據大小發生了變化，這時候容易產生一些數據碎片，出現碎片引起的結果，一個是索引會出現性能問題。

      另一個就是在必定的時間後，所佔空間會莫明其妙地增大，因此要按期把數據庫作修復，按期從新作索引，這樣會提高 MongoDB 的穩定性和效率。在最新的版本里，它已經在實如今線壓縮，估計應該在 2.0 版左右，應該可以實如今線壓縮，能夠在後臺執行如今 repair DataBase 的一些操做。

      若是那樣，就解決了目前困擾咱們的大問題。