MySQL DBA面試整理

時間 2019-11-10

標籤 mysql dba 面試整理欄目 MySQL 简体版

原文原文鏈接

文檔：MySQL DBA面試整理.note
連接：http://note.youdao.com/noteshare?id=8ac1a828da5dfd0d05d3c2edf2744311&sub=C0463009298A48A4951D3321D406DD59node

MySQL DBA面試整理mysql

主從複製

爲何要進行主從？linux

背景：有一個SQL語句須要進行表鎖ios

影響：表暫停服務，不對外提供服務程序員

目的：讀寫分離，一個庫用來讀，一個用來寫寫面試

工做：據的熱備正則表達式

用途：架構拓展，IO太高，下降IO的頻率，提升單個機器的IO性能算法

優勢：減輕主庫的負載，當主庫宕機，能夠快速切換到從庫sql

主從與集羣的區別shell

主從：配置好主從以後同一張表只能對一個服務器進行寫操做。若是在從上進行了寫操做，以後主也進行了寫的操做，會形成主從不一樣步。宕機以後須要手工切換

集羣：有多臺數據庫服務器組成，數據庫的寫入和查詢隨機到一臺數據庫服務器，其餘的機器會自動同步，單一出現問題不會形成影響

缺點：目前mysql集羣值針對NDB，若是是innodb或其餘存儲引擎不能夠

原理：

一、數據庫有一個binlog文件：最重要的日誌文件，全部的DDL/DML語句以事件的形式記錄

二進制索引文件（xxx.index）用於記錄全部的二進制文件

二進制文件（xxx.000*）記錄DDL/DML

2：基本原理：將binlog文件複製

3：過程：在從庫relay-log中重作日誌文件中執行binlog中的SQL語句

4線程：

一、主庫進行DDL/DML

二、從庫發起鏈接請求

三、主庫開啓Binlog dump thread 將binlog傳輸到從庫relay-log

四、從庫啓動I/Othread線程，將binlog寫入到relay-log

五、從庫建立一個SQL線程，從relay-log中讀取，將內容寫入到從庫的數據庫

方式：

異步

主庫把提交事件寫進binlog

給用戶返回提交成功

異步傳輸給從庫relay-log

從庫應用relay-log

半同步

主庫將提交事件寫進binlog

將binlog傳給從庫relay-log

從庫相應主庫binlog傳輸完成

異步傳輸給從庫relay-log

從庫應用relay-log

延遲問題：

傳輸延遲

產生緣由：

dump是單線程讀取binlog速度慢---------增長物理讀能力

網絡延遲-----------------------------------------增長網絡帶寬

從庫IO線程寫能力小------------------------------raid+flash（緩存）

應用延遲

從庫只有一個SQL線程----------------------------避免主庫有大量的DML

慢查詢-------------------------------------------建立主鍵/索引

從庫性能低---------------------採用mixed：SQL語句（update會丟失）/行（binlog太大）/混合複製

MHA

MHA原理

該軟件由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。MHA
Manager能夠單獨部署在一臺獨立的機器上管理多個master-slave集羣，也能夠部署在一臺slave節點上。MHA
Node運行在每臺MySQL服務器上，MHA
Manager會定時探測集羣中的master節點，當master出現故障時，它能夠自動將最新數據的slave提高爲新的master，而後將全部其餘的slave從新指向新的master。整個故障轉移過程對應用程序徹底透明。

在MHA自動故障切換過程當中，MHA試圖從宕機的主服務器上保存二進制日誌，最大程度的保證數據的不丟失，但這並不老是可行的。例如，若是主服務器硬件故障或沒法經過ssh訪問，MHA無法保存二進制日誌，只進行故障轉移而丟失了最新的數據。使用MySQL
5.5的半同步複製，能夠大大下降數據丟失的風險。MHA能夠與半同步複製結合起來。若是隻有一個slave已經收到了最新的二進制日誌，MHA能夠將最新的二進制日誌應用於其餘全部的slave服務器上，所以能夠保證全部節點的數據一致性。

manager作了幾件事情

一、監控主和從

二、主宕機以後，manager會作幾件事情

找到新的主
1. 若是指定候選，直接使用候選做爲新的主
2. 若是沒有指定候選，或者指定了多個候選，選擇延遲最小的做爲主
從舊的主保存binlog
應用binlog到新的主
在新的主上啓動新的地址，也就是地址的漂移

經過執行一個腳原本實現

三、必定要注意查看manager上面的日誌

如何把壞掉的主加入到 mha 環境中：

mha 默認狀況下，宕掉的舊主經過如下步驟加入到 mha 環境中去，之後不能再充當
master，由於加上了 no_master 參數，認爲從新成爲主可能會形成數據的不一致。

一、讓舊主成爲從

CHANGE MASTER TO MASTER_HOST='192.168.10.52',MASTER_PORT=3306,
MASTER_LOG_FILE='mha-server.000003',MASTER_LOG_POS=154, MASTER_USER='repl',
MASTER_PASSWORD='repl';

確保新主上有舊主能夠使用的複製用戶

二、加入到 manager 的監控中

masterha_conf_host --command=add --conf=/etc/masterha/app1.cnf
--hostname=192.168.10.51 --block=server2 --params="no_master=1;ignore_fail=1"

也能夠手工直接編輯 app1.cnf

如何將失敗的 master 強行加進來

一、刪除 fialover complete 文件

二、dead master 從新安裝 mysql 軟件、使用備份恢復搭建新的主從

三、編輯 app1.cnf，將新的從加入到配置文件中，重啓 manager 進程

一、手工編輯

二、使用命令加入

MHA 平常監控命令：

# masterha_check_status --conf=/etc/masterha/app1.cnf //平常 mha
監控，主要監控manager 節點

# masterha_check_repl --conf=/etc/masterha/app1.cnf

# masterha_check_ssh --conf=/etc/masterha/app1.cnf //常常用來排錯

一、發現舊主已經over，就地保存binlog，指定start-position

二、再次肯定舊主已經over

三、肯定其餘的從的狀態

四、關閉主應用和漂移ip

MHA的優缺點

MHA工具的優勢:

由Perl語言開發的開源工具master自動監控和故障轉移

master crash 不會致使主從數據不一致性

能夠支持基於GTID的複製模式(MySQL 5.7版本)MHA在進行故障轉移時更不易產生數據丟失

同一個監控節點能夠監控多個集羣

MHA增強了數據的安全性

MHA工具的缺點:

須要編寫腳本或利用第三方工具來實現VIP的配置

MHA啓動後只會對主數據庫進行監控

須要基於SSH免認證配置，存在必定的安全隱患

沒有提供從服務器的讀負載均衡功能

mha 由於延遲不能啓動新的主時，解決辦法：

方法 1：

刪除 fialover complete 文件
在但願成爲主的那個下面，添加 check_repl_delay=0
再次啓動 manager
原來的延遲還會繼續跑，新的操做不能進行，由於漂移地址沒有過來，read_only

沒有關閉。mha 也會等到全部的應用日誌都跑完之後，纔會提高新的主。你能夠強行關閉
readonly，鏈接本地地址 50，先進行操做，極可能會發生主鍵衝突。

方法 2：

或者乾等，slave 遇上 master 之後，刪除 error，重啓啓動 manager。
須要等到新主應用全部的 binlog，生產上接受不了。因此對於 mha
來講，若是存在嚴重的延遲的話，基本上不能用。

方法 3：

不依靠 mha，關閉 manager，將其中一個 slave 的 ip 地址進行修改，readolny
參數去掉，提高爲主

MHA能切換幾回

只能一次

3.觸發器的做用域是什麼以及觸發器的最小單位

做用域是表，最小單位是行

讀寫分離

1.應用層解決;

2.中間件實現

應用層實現的的優缺點:

優勢:

一、多數據源切換方便，由程序自動完成;

二、不須要引入中間件;

三、理論上支持任何數據庫;

缺點:

一、由程序員完成，運維參與不到;

二、不能作到動態增長數據源;

SQL的執行順序

一、先執行from、join、where、on
部分，這是最主要的資源消耗點，要合理使用索引，注意表的關聯順序

二、group by、having（分組聚合），要注意優化分組聚合

三、order by，要注意優化order by，使用索引去除磁盤排序

四、執行limit，要注意優化limit，特別是在分頁查詢中，經過limit
實現優化，特別是order by limit，兩種手法：一、前面的頁使用order by limit，走order
by 索引二、後面的頁使用join 的方式來優化

五、最後執行select 列，不要將子查詢放在select 和from
之間，由於對於返回的每一行數據，子查詢都要執行一次

鎖

答：

數據庫是一個多用戶使用的共享資源。當多個用戶併發地存取數據時，在數據庫中就會產生多個事務同時存取同一數據的狀況。若對併發操做不加控制就可能會讀取和存儲不正確的數據，破壞數據庫的一致性。

加鎖是實現數據庫併發控制的一個很是重要的技術。當事務在對某個數據對象進行操做前，先向系統發出請求，對其加鎖。加鎖後事務就對該數據對象有了必定的控制，在該事務釋放鎖以前，其餘的事務不能對此數據對象進行更新操做。

基本鎖類型：鎖包括行級鎖和表級鎖

Mysql中有哪幾種鎖？

1.表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的機率最高，併發度最低。

2.行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的機率最低，併發度也最高。

頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度通常。

一. 如何避免鎖

能夠在修改資源的時候一會兒得到全部須要修改的資源的鎖，之後再也不能得到其它的鎖，直到本次修改完成。
能夠按某種順序依次得到資源的鎖。

二. 若是已經產生了鎖的解決辦法

經過檢查機制找出鎖，而後犧牲掉那個進程。
經過設置超時機制，自動殺掉持鎖時間超時的進程，

Latch，mutex、pin

在innodb 中查詢到須要修改的數據頁
1. 此時會發生latch(r)爭用,由於須要鎖住數據鏈對數據鏈進行遍歷
沒有找到的話釋放latch(r),去磁盤查找,發生物理讀
在磁盤中查找時分爲使用索引和不使用索引
1. 使用索引會提升查詢速度,提升sql的工做效率
2. 不使用索引會發生全表掃描,會致使大量數據涌入innodb_buffer_pool
查找到的數據會放到innodb_buffer_pool裏面
1. 此時須要在innodb_buffer_pool中查找free或者clean頁
2. 在查找free和clean頁時若是free已經所有用完並且在clean不夠用的狀況下會發生磁盤寫,致使db_write工做,而後也會更新redo和ondo,redo的做用是用來記錄未寫入到磁盤的髒數據的日誌,用於後期數據庫將在innodb_buffer_pool中的髒數據更新到磁盤中,ondo的做用是記錄髒數據以前的數據,用於用戶執行rollback操做
3. 此時會發生latch(x)爭用,由於要將磁盤中的數據寫入到innodb_buffer_pool中
在數據從磁盤上將數據寫入到free或者clean中時,會發生waits特別是在數據的查找時沒有使用索引時會致使大量數據涌入innodb_buffer_pool,致使發生waits
釋放全部的latch
1. 寫完數據後釋放latch(x)和latch(s)
將innodb_buffer_pool中的數據進行修改,增長pin鎖
1. Pin鎖的目的是爲了在修改的一瞬間保證這個數據頁不會被進行任何ddl操做,以免修改失敗
2. 在修改開始前會對改數據行所在的數據頁增長表級別的ix鎖,用於避免此時其餘事務對該表執行ddl操做
3. 修改過程當中會對要修改的行添加x鎖,使該行進入到排他狀態,以保證修改數據中,不會再其餘線程不會發生髒讀
此時若是有其餘用戶線程查找該行數據,會讀取到該行數據最新一次commit後的數據,而不會讀取到當前事務修改的數據,這也是爲了不髒讀
修改完數據後釋放pin鎖
當修改完數據後會發生undo和redo
1. Undo記錄修改前的數據用於rollback
2. redo用於記錄修改後的日誌寫入磁盤中的log file以用來慢慢更新髒數據
此時ix鎖和x鎖都沒有釋放,由於沒有發生commit
1. 也就意味着此時該表仍然處於能夠進行的是select和dml不能進行ddl的狀態
2. 固然若是dml中要更新的數據是被加了x鎖的這一行和讀取這一行數據也是不能夠的,由於該行處於x鎖狀態
commit提交
1. 在數據修改爲功後,也就是該事務完成後提交,ix表鎖和x行鎖釋放,但數據不會及時的寫入到磁盤上,由於用經過redo進程中的log
  file來後臺更新磁盤上的數據

事務

事務（transaction）是做爲一個單元的一組有序的數據庫操做。若是組中的全部操做都成功，則認爲事務成功，即便只有一個操做失敗，事務也不成功。若是全部操做完成，事務則提交，其修改將做用於全部其餘數據庫進程。若是一個操做失敗，則事務將回滾，該事務全部操做的影響都將取消。

事務特性：

（1）原子性：即不可分割性，事務要麼所有被執行，要麼就所有不被執行。

（2）一致性或可串性。事務完成時，數據必須處於一致狀態，數據的完整性約束沒有被破壞，事務在執行過程當中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務歷來沒有執行過同樣。

（3）隔離性。在事務正確提交以前，不容許把該事務對數據的任何改變提供給任何其餘事務，

（4）
持久性。事務正確提交後，其結果將永久保存在數據庫中，即便在事務提交後有了其餘故障，事務的處理結果也會獲得保存。

或者這樣理解：

事務就是被綁定在一塊兒做爲一個邏輯工做單元的SQL語句分組，若是任何一個語句操做失敗那麼整個操做就被失敗，之後操做就會回滾到操做前狀態，或者是上有個節點。爲了確保要麼執行，要麼不執行，就能夠使用事務。要將有組語句做爲事務考慮，就須要經過ACID測試，即原子性，一致性，隔離性和持久性。

MVCC

實現了一致性讀:

一、避免髒讀(已提交讀)，寫不阻塞讀

二、實現可重複讀

MVCC 實現原理:

修改刪除一個數據頁裏的數據行，事務開始後，分配一個事務槽，數據頁，先把數據行裏的舊的事務
id 和 roll pointer 和原來的數據寫到數據頁裏去，新的roll pointer
指向新的數據頁的位置，事務提交了，又開啓了一個事務，仍是修改這行數據，至關於新的
roll pointer 從 undo 事務塊指向了舊的 undo 事務塊，這就是多版本控制 MVCC，在
undo 裏面能夠保存數據的不一樣時刻的多個版本。

描述 MVCC

一、MVCC 使得在一個事務中，全部的 select 訪問到的是同一個時刻的數據，
反覆執行一個 select，獲得的數據是一致的

二、經過 undo 來實現

三、實現了 select 的可重複讀隔離級別

四、可重複讀隔離級別經過 MVCC 來實現 select，經過 gap lock 來實現 dml

五、mvcc 會由於長事務、大事務致使 undo 暴漲。undo 在低版本中，沒有辦
法自動回收，在新的版本中，undo 的自動回收機制風險很大，所以也要謹慎使
用。要避免長事務，經過監控 innodb_trx 視圖，裏面有兩個列，一個是事務的開
始時間，一個是事務的修改行數，判斷是長事務仍是大事務，對於長事務，要及
時進行回滾或者提交。

備份

冷備

冷備份發生在數據庫已經正常關閉的狀況下，當正常關閉時會提供給咱們一個完整的數據庫。冷備份時將要害性文件拷貝到另外的位置的一種說法。對於備份MySQL信息而言，冷備份時最快和最安全的方法。

冷備份的優勢是：

　　１、是很是快速的備份方法（只需拷文件）

　　２、輕易歸檔（簡單拷貝便可）

　　３、輕易恢復到某個時間點上（只需將文件再拷貝回去）

　　４、能與歸檔方法相結合，作數據庫「最佳狀態」的恢復。

５、低度維護，高度安全。

但冷備份也有以下不足：

１、單獨使用時，只能提供到「某一時間點上」的恢復。

２、
再實施備份的全過程當中，數據庫必需要做備份而不能做其餘工做。也就是說，在冷備份過程當中，數據庫必須是關閉狀態。

３、若磁盤空間有限，只能拷貝到磁帶等其餘外部存儲設備上，速度會很慢。

４、不能按表或按用戶恢復。

冷備份中必須拷貝的文件包括：

１、全部數據文件

２、全部控制文件

３、全部聯機REDO LOG文件

４、 Init.ora文件（可選）

值得注重的使冷備份必須在數據庫關閉的狀況下進行，當數據庫處於打開狀態時，執行數據庫文件系統備份是無效的

熱備：

熱備份是在數據庫運行的狀況下，採用archivelog
mode方式備份數據庫的方法。即熱備份是系統處於正常運轉狀態下的備份。因此，若是你有一個冷備份並且又有熱備份文件，在發生問題時，就能夠利用這些資料恢復更多的信息。熱備份要求數據庫在Archivelog()方式下操做，並須要大量的檔案空間。一旦數據庫運行在archivelog狀態下，就能夠作備份了。

熱備份的優勢是：

　　1．可在表空間或數據庫文件級備份，備份的時間短。

　　2．備份時數據庫仍可以使用。

　　3．可達到秒級恢復（恢復到某一時間點上）。

　　4．可對幾乎全部數據庫實體作恢復

　　5．恢復是快速的，在大多數狀況下愛數據庫仍工做時恢復。

　　熱備份的不足是：

　　1．不能出錯，不然後果嚴重

2．若熱備份不成功，所得結果不可用於時間點的恢復

（回答要點，概念，區別，包括所使用的原件的優勢和缺點，把本身知道的備份都說出來）

mysql邏輯備份：

mysql邏輯備份是指備份sql語句，再恢復的時候執行備份的sql語句實現數據庫數據的重現

mysqldump：是採用SQL級別的備份機制，他將數據表導成SQL腳本文件，是最經常使用的邏輯備份方法

缺點

對於myisam表：鎖定

對於innodb表，經過undo的mvcc實現一致性，期間不能進行DDL，會致使數據不一致

備份時間長，全部的塊都須要進行讀取，抽取數據行，寫入備份文件

恢復時間長（磁盤IO，索引建立），好比insert
，過程會產生redo、undo、SQL解析、double write、鎖、binlog 等

不適用於大表、大數據庫

優勢

可以實現備份+binlog——恢復到任意時間點

能夠生成CSV、delimited text、XML format

有助於避免數據損壞，若是磁盤驅動器故障複製文件，文件是損壞的

如何進行邏輯備份

舉例：經典用法

mysqldump -uroot -p123 -l -F --single-transaction ceshi>ceshi.sql

-l：鎖住myisam，不鎖innodb

-F：刷新binlog，恢復的時候就能夠直接使用新binlog開始恢復

--single-transaction：innodb不鎖表和行

物理備份：

物理備份就是備份數據文件了，比較形象點就是複製cp數據文件，

物理備份工具

xtrabackup：

缺點：

一、文件大

二、不老是能夠跨平臺、操做系統和MySQL版本

優勢：

一、基於文件的物理備份

二、恢復快，不須要執行任何SQL語句，不須要構建索引，緩存數據等

三、自動完成備份鑑定

一、在線備份，不阻塞任何的SQL語句;

二、備份性能好，備份的實質是複製數據庫文件和重作日誌文件;

三、支持壓縮備份，經過選項，能夠支持不一樣級別的壓縮。

四、跨平臺支持，ibbackup 能夠運行在linux、windows以及主流的unix系統平臺上。

原理

備份全部數據頁和備份期間全部的redo日誌--將數據頁能恢復到備份結束時刻

+binlog，將數據庫恢復到對應的時間點

回滾備份結束時刻未提交的事務

innodb使用redolog保持數據的一致性

myisam使用鎖保持備份的一致性

Xtrabackup的優勢以及機制

工做機制:

對於innodb存儲引擎表其備份工做原理是:

一、記錄備份開始時，innodb存儲引擎重作日誌文件檢查點的LSN;

二、複製共享表空間文件以及獨立表空間文件:

三、記錄複製完表空間文件後，innodb存儲引擎重作日誌文件檢查點的LSN;

四、複製在備份時產生的重作日誌。

五、在備份期間不會對數據庫自己有任何影響，所作的操做只是複製數據庫文件，所以任何對數據庫的操做都是容許的，不會阻塞任何操做。

索引

MySQL索引的創建對於MySQL的高效運行是很重要的，索引能夠大大提升MySQL的檢索速度。

打個比方，若是合理的設計且使用索引的MySQL是一輛跑車的話，那麼沒有設計和使用索引的MySQL就是一個自行車。

索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表能夠有多個單列索引，但這不是組合索引。組合索引，即一個索引包含多個列。

建立索引時，你須要確保該索引是應用在 SQL 查詢語句的條件(通常做爲 WHERE
子句的條件)。

實際上，索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄。上面都在說使用索引的好處，但過多的使用索引將會形成濫用。所以索引也會有它的缺點：雖然索引大大提升了查詢速度，同時卻會下降更新表的速度，如對錶進行INSERT、UPDATE和DELETE。由於更新表時，MySQL不只要保存數據，還要保存一下索引文件。

創建索引會佔用磁盤空間的索引文件。

1.索引的目的是什麼？
快速訪問數據表中的特定信息，提升檢索速度
建立惟一性索引，保證數據庫表中每一行數據的惟一性。
加速表和表之間的鏈接

使用分組和排序子句進行數據檢索時，能夠顯著減小查詢中分組和排序的時間

2.索引對數據庫系統的負面影響是什麼？
負面影響：
建立索引和維護索引須要耗費時間，這個時間隨着數據量的增長而增長；索引須要佔用物理空間，不光是表須要佔用數據空間，每一個索引也須要佔用物理空間；當對錶進行增、刪、改、的時候索引也要動態維護，這樣就下降了數據的維護速度。

3.爲數據表創建索引的原則有哪些？
在最頻繁使用的、用以縮小查詢範圍的字段上創建索引。

在頻繁使用的、須要排序的字段上創建索引

4.什麼狀況下不宜創建索引？
對於查詢中不多涉及的列或者重複值比較多的列，不宜創建索引。

對於一些特殊的數據類型，不宜創建索引，好比文本字段（text）等

Xtrabackup 的優勢以及機制

工做機制:

對於innodb存儲引擎表其備份工做原理是:

一、記錄備份開始時，innodb存儲引擎重作8志文件檢查點的LSN;

二、複製共享表空間文件以及獨立表空間文件;

三、記錄複製完表空間文件後，innodb存儲引擎重作日誌文件檢查點的LSN;

四、複製在備份時產生的重作日誌。

五、在備份期間不會對數據車自己有任何影響，所作的操做只是複製數據庫文件，所以任何對數據庫的操做都是容許的，不會阻塞任何操做。

優勢:

一、在線備份，不阻塞任何的SQL語句;

二、備份性能好，備份的實質是複製數據庫文件和重作日誌文件;

三、支持壓縮備份，經過選項，能夠支持不一樣級別的壓縮。

四、跨平臺支持，ibbackup 能夠運行在linux、windows 以及主流的unix系統平臺上。

Innodb

一、mysql 爲了支持oltp 系統而設計的一個引擎，目前是mysql 的默認引擎

二、支持事務，這是oltp 最基本的要求，事務支持ACID、原子性、一致性、持久性、隔離性

三、支持行鎖，大大提高MySQL 的併發性能

四、經過undo 實現寫不阻塞讀，進一步提高併發性能

五、支持事務的四種隔離級別

六、支持redo、有了redo 之後能夠實現快速提交、髒緩衝區、崩潰恢復

七、change buffer，提高dml 的性能，可以解決二級索引致使的io 問題

八、double write，解決了寫入時數據損壞的問題，可是也放大了寫入的壓力

九、自適應hash 索引,解決了樹高部分的資源消耗

十、異步IO,提高cpu 的使用率，下降wait io 等待，提高系統性能

十一、刷新鄰接頁，加速髒頁的回寫，可是也放大了寫壓力

十二、支持MVCC

特色

一、支持行鎖，併發性能好

二、支持 M CC，支持事務

三、支持外鍵

四、提供一致性非鎖定讀，併發能力更強

五、可以使用大內存和充分利用 c 資源

函數和存儲過程的區別

存儲過程定義：存儲過程就是具備名字的一段代碼，完成一個特定的功能。存儲過程保存在數據字典中

使用存儲過程的緣由：（1）將重複性很高的一些操做封裝到一個存儲過程當中，簡化了對這些SQL的調用，能夠重複使用（2）批量處理【SQL語句+循環語句】
（3）統一接口

函數的特色：函數特色：（1）函數有返回值，兩個return，第一個標誌着返回什麼類型，第二個是實際的返回值。（2）調用函數，函數須要出如今等號的右邊。（3）其餘地方與定義存儲過程同樣

二者區別：

存儲過程實現的過程要複雜一些，而函數的針對性比較強。

存儲過程能夠經過 out參數有多個返回值，而函數只有一個返回值；

存儲過程通常的獨立的來執行，而函數每每是做爲其餘SQL語句的一部分來使用；

函數使用select調用，存儲過程使用call調用

存儲過程創建是 create procedure 函數創建是create function

咱們比較喜歡使用存儲過程緣由以下：

自定義函數的使用比較麻煩

（2）存儲過程的out參數也能夠返回值，並且能夠返回多個值

性能定位的問題

一、OS 層面定位性能問題：

一、top、H：是否有過載線程（大於75%有異常，大於90%必須查看），根據線程ID
找到對應的會話，找到對應的sql，看sql 的執行計劃，而後進行優化。

二、vmstat：r 隊列是否有過多的r 線程（是否有異常SQL 或者tps
增長）以及是否在使用swap。

一、若是有過多的r，說明有大量的用戶鏈接正在執行，這頗有可能說明出現了異常SQL
而且頻繁執行，執行時間過長，佔用會話不釋放，會致使會話異常高，r
隊列暴增。經過show processlist 找到對應的SQL，看執行計劃，進行優化。

二、若是swap
在使用，多是用戶線程暴增（致使使用物理內存短缺，使用到swap），或者在系統上執行大量的文件操做（致使active
內存過多，free內存減小，swap 被使用）

三、iostat：io 是否過載（io 量很大，高出正常值不少，多是異常的SQL 致使IO
過載）、io 是否有問題（iops 達不到平時高度，可是繁忙度已經100%，即io
低但繁忙度高，找硬件工程師）、寫性能是否差（查看service time
列，是否配置寫緩存、寫閃存）

四、free：空閒內存是否夠用，free
內存短缺不必定有事，若是過多使用到swap，纔是內存真正短缺，形成內存短缺的三種狀況

一、線程（用戶鏈接）忽然增長

二、對文件進行操做（好比對大文件進行備份，而且經過網絡拖走）

三、應用服務器在數據庫服務器上）

五、cat /proc/meminfo 裏面active 內存是否過多

二、數據庫層面定位異常SQL：

一、鏈接線程是否大幅增長：

一、慢sql（異常SQL，個別線程負載太高必定是異常SQL 致使的）

二、鎖（在數據字典級別能夠查到事務鎖）

三、tps、qps 大幅增長（業務高）

鏈接線程的暴增，可能會致使系統內存的耗盡

二、找出異常SQL：

一、慢查詢日誌——已經慢

二、show processlist——正在慢

三、監控(zabbix 等)數據庫當前負載是否忽然增長:

Innodb_rows_deleted

Innodb_rows_inserted

Innodb_rows_read

Innodb_rows_updated

Binlog太多怎麼刪除

一、若是數據庫沒有搭建主從同步這樣的服務 , binlog 日誌也不用的狀況下 , 你能夠將
/etc/my.cnf 文件下面行刪除或註釋掉log-bin=mysql-bin

二、若是你須要這樣的文件,那麼在主配置文件 /etc/my.cnf
中添加行,來限制binlog日誌文件存在時間,過時自動刪除expire_logs_days = 7 # 只保留
7 天的日誌文件

三、若是直接獲得一臺服務器,上面的 binlog
日誌已經影響到了磁盤空間,那麼你將使用下面命令清除mysql> reset master; #
清空全部 binlog 文件

四、若是服務器mysql 還作了主從同步 ,由於 binlog 文件刪除過多的話 ,
會致使數據不一樣步

mysql> show slave status\G # 你首先要來 slave 上查看從庫讀 binlog 到了哪裏

Master_Log_File: mysql-bin.000009 # 咱們能夠看到是 mysql-bin.000009

mysql> purge master logs to 'mysql-bin.000009'; # 咱們能夠在 master
中執行這條指令 , 將 binlog 文件刪除至 mysql-bin.000009 前

mysql> purge master logs before '2014-11-18 00:00:00'; # 將 binlog
文件刪除至此日期前

linux怎麼開放一個端口

開放端口的方法：

方法一：命令行方式

開放端口命令： /sbin/iptables -I INPUT -p tcp --dport 8080 -j ACCEPT

2.保存：/etc/rc.d/init.d/iptables save

3.重啓服務：/etc/init.d/iptables restart

4.查看端口是否開放：/sbin/iptables -L -n

方法二：直接編輯/etc/sysconfig/iptables文件

1.編輯/etc/sysconfig/iptables文件：vi /etc/sysconfig/iptables加入內容並保存：-A
RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT

2.重啓服務：/etc/init.d/iptables restart

3.查看端口是否開放：/sbin/iptables -L -n

主鍵和惟一鍵的區別

區別項	Primary Key（主鍵）	Unique（惟一建）
惟一性	能夠	能夠
是否能夠爲空	不能夠	能夠
容許個數	只能有1個	容許多個
是否容許多列組合	容許	容許

mysql優勢

MySQL是一個小型關係型數據庫管理系統,MySQL被普遍地應用在Internet上的中小型網站中。因爲其體積小、速度快、整體擁有成本低，尤爲是開放源碼這一特色，許多中小型網站爲了下降網站整體擁有成本而選擇了MySQL做爲網站數據庫。

1．它使用的核心線程是徹底多線程，支持多處理器。

2．
有多種列類型：一、二、三、四、和8字節長度自有符號／無符號整數、FLOAT、DOUBLE、CHAR、VARCHAR、TEXT、BLOB、DATE、TIME、DATETIME、
TIMESTAMP、YEAR、和ENUM類型。

3．
它經過一個高度優化的類庫實現SQL函數庫並像他們能達到的同樣快速，一般在查詢初始化後不應有任何內存分配。沒有內存漏洞。

4．全面支持SQL的GROUP BY和ORDER
BY子句，支持聚合函數(COUNT()、COUNT(DISTINCT)、AVG()、STD()、SUM()、MAX()和MIN())。你能夠在同一查詢中混來自不一樣數據庫的表。

5．支持ANSI SQL的LEFT 0UTER JOIN和ODBC。

6．
全部列都有缺省值。你能夠用INSERT插入一個表列的子集，那些沒用明確給定值的列設置爲他們的決省值。

7． MySQL能夠工做在不一樣的平臺上。支持C、C＋＋、Java、Perl、PHP、Python和TCL
API。

避免全盤掃描

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

嘗試下面的技巧以免優化器錯選了表掃描：

使用ANALYZE TABLE tbl_name爲掃描的表更新關鍵字分佈。

對掃描的表使用FORCE INDEX告知MySQL，相對於使用給定的索引表掃描將很是耗時。

SELECT * FROM t1, t2 FORCE INDEX (index_for_column)

WHERE t1.col_name=t2.col_name；

用--max-seeks-for-key=1000選項啓動mysqld或使用SET
max_seeks_for_key=1000告知優化器假設關鍵字掃描不會超過1,000次關鍵字搜索。

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

如：

select id from t where num is null

NULL對於大多數數據庫都須要特殊處理，MySQL也不例外，它須要更多的代碼，更多的檢查和特殊的索引邏輯，有些開發人員徹底沒有意識到，建立表時NULL是默認值，但大多數時候應該使用NOT
NULL，或者使用一個特殊的值，如0，-1做爲默認值。

不能用null做索引，任何包含null值的列都將不會被包含在索引中。即便索引有多列這樣的狀況下，只要這些列中有一列含有null，該列
就會從索引中排除。也就是說若是某列存在空值，即便對該列建索引也不會提升性能。
任何在where子句中使用is null或is not null的語句優化器是不容許使用索引的。

此例能夠在num上設置默認值0，確保表中num列沒有null值，而後這樣查詢：

select id from t where num=0

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

MySQL只有對如下操做符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些時候的LIKE。能夠在LIKE操做中使用索引的情形是指另外一個操做數不是以通配符（%或者_）開頭的情形。例如，「SELECT
id FROM t WHERE col LIKE 'Mich%';」這個查詢將使用索引，但「SELECT id FROM t WHERE
col LIKE '%ike';」這個查詢不會使用索引。

應儘可能避免在 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

4 .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

5.下面的查詢也將致使全表掃描：

select id from t where name like '%abc%' 或者

select id from t where name like '%abc' 或者

若要提升效率，能夠考慮全文檢索。

而select id from t where name like 'abc%' 纔用到索引

若是在 where
子句中使用參數，也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量，但優化程序不能將訪問計劃的選擇推
遲到運行時；它必須在編譯時進行選擇。然而，若是在編譯時創建訪問計劃，變量的值仍是未知的，於是沒法做爲索引選擇的輸入項。以下面語句將進行全表掃描：

select id from t where num=@num

能夠改成強制查詢使用索引： select id from t with(index(索引名)) where num=@num

8.應儘可能避免在 where
子句中對字段進行表達式操做，這將致使引擎放棄使用索引而進行全表掃描。

如：

select id from t where num/2=100

應改成:

select id from t where num=100*2

應儘可能避免在where子句中對字段進行函數操做，這將致使引擎放棄使用索引而進行全表掃描。

如：

select id from t where substring(name,1,3)='abc'--name

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.儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

遊標

在存儲過程當中，若是某條select語句返回的結果集中只有1行，能夠使用select
into語句來獲得該行進行處理。若是結果集中有多行，又該如何獲得其中的每一行進行處理呢？這必須使用遊標

遊標cursor：

能夠看作是指向查詢結果集的指針。經過它，就能夠一次一行的從結果集中把行拿出來處理

遊標的處理過程：4步

聲明遊標

打開遊標

檢索遊標

關閉遊標

（1）聲明遊標

DECLARE cursor_name CURSOR FOR select_statement;

語義：聲明一個遊標cursor_name，讓它指向查詢select_statement的結果集

遊標聲明必須出如今變量和條件聲明的後面，可是在異常處理聲明前面

一個過程當中能夠有多個遊標聲明

（2）打開遊標

OPEN cursor_name;

打開遊標時才執行相應的select_statement

（3）檢索遊標

FETCH cursor_name INTO var_name [, var_name] ...

從遊標cursor_name中拿出一行，把該行的各個列值保存到各個變量中

一次只拿一行。拿完後，自動移動指針到下一行

若是沒有拿到行，會拋出異常，其SQLSTATE代碼值爲
‘02000‘。要檢測到該狀況，須要聲明異常處理程序 (針對條件 NOT FOUND 也能夠)

一般須要在一個循環中來執行fetch語句，經過檢測以上異常來結束循環

（4）關閉遊標

CLOSE cursor_name;

收回遊標佔用的內存

示例：

DELIMITER $$

CREATE PROCEDURE number_of_players(

OUT pnumber INTEGER

)

BEGIN

DECLARE a_playerno INTEGER; ##定義一個局部變量，數據類型是int

DECLARE FOUND BOOLEAN DEFAULT TRUE;
##定義局部變量，數據類型是boolean，默認值是ture

DECLARE c_players CURSOR FOR ##定義遊標，關鍵字是cursor for

SELECT playerno FROM PLAYERS; ##將遊標的值和select語句返回的結果集關聯起來

DECLARE CONTINUE HANDLER FOR NOT FOUND

SET FOUND = FALSE;
##異常處理，全部以2開頭的錯誤均可以捕獲到，將found值設置爲false

SET pnumber = 0;

OPEN c_players; ##打開遊標

FETCH c_players INTO a_playerno; ##將第一行的數據給變量，而後指向第二行

WHILE FOUND DO ##循環，found爲真時執行

SET pnumber = pnumber + 1;

FETCH c_players INTO a_playerno;
##將第二行的數據給變量，而後指向第三行，執行循環，執行完最後一行的值，沒有值就會報錯，而後會被異常處理捕獲

END WHILE;

CLOSE c_players; ##關閉遊標

END$$

DELIMITER ;

mysql> call number_of_players(@pnumber);

Query OK, 0 rows affected (0.00 sec)

mysql> select @pnumber;

+----------+

| @pnumber |

+----------+

| 14 |

+----------+

1 row in set (0.00 sec)

經過示例咱們瞭解到的遊標的四個步驟

定義遊標

將一個遊標的和一個select進行關聯

打開遊標

將一個遊標和一個結果集關聯，執行了select

獲取遊標

須要使用循環進行數據的獲取

當獲取到最後一個結果之後，再次執行循環的時候，就會報錯，這個錯誤以2開頭。

這個時候，咱們須要定義一個對2開頭的錯誤的捕獲

關閉遊標，結果集消失

釋放資源

SSH怎麼配置免密登陸

Root/. ssh配置文件

一、服務器 master 上生成密鑰，執行命令 ssh-keygen -t rsa

二、進入Root/. ssh配置文件

authorized_keys: 存放遠程免密登陸的公鑰,主要經過這個文件記錄多臺機器的公鑰。

id_rsa: 生成的私鑰文件

id_rsa.pub: 生成的公鑰文件

known_hosts: 已知的主機公鑰清單

三、遠程密鑰登陸

方式一，經過 ssh-copy-id 命令設置。最後一個參數是要免密鑰登陸的服務器 ip 地址。

ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.1.100

方式二，經過 scp
命令直接將該文件遠程複製過去，使用這種方式須要注意，若是你以前已經配置了其它服務器上的密鑰，這是使用這種方法，就會覆蓋掉你原來的密鑰，這時候是不建議使用這種方式的，若是你是先將該文件複製到服務器上的一個目錄下，而後在使用追加的方式，將密鑰追加到
authorized_keys 也是徹底 OK 的。若是你只有兩臺服務器也是能夠直接複製到文件。

scp -p ~/.ssh/id_rsa.pub root@<ip>:/root/.ssh/authorized_keys

Truncate和delete的區別

一、表和索引所佔空間。當表被truncate
後，這個表和索引所佔用的空間會恢復到初始大小，delete操做不會減小表或索引所佔用的空間。

二、應用範圍。truncate 只能對table；delete能夠是table和view。

三、truncate 和delete只刪除數據， drop則刪除整個表（結構和數據）。

四、delete語句爲dml（data maintain language),這個操做會被放到 rollback
segment中,事務提交後才生效。若是有相應的
tigger,執行的時候將被觸發。truncate是dll（data define
language),操做當即生效，原數據不放到 rollback segment中，不能回滾。

五、在沒有備份狀況下，謹慎使用
truncate。要刪除部分數據行採用delete且注意結合where來約束影響範圍。回滾段要足夠大。若想保留表而將表中數據刪除，若是於事務無關，用truncate便可實現。若是和事務有關，或總是想觸發trigger,仍是用delete。

六、truncate table 表名速度快,並且效率高,由於:

truncate table 在功能上與不帶 where 子句的 delete
語句相同：兩者均刪除表中的所有行。但 truncate table 比 delete
速度快，且使用的系統和事務日誌資源少。

delete 語句每次刪除一行，並在事務日誌中爲所刪除的每行記錄一項。truncate table
經過釋放存儲表數據所用的數據頁來刪除數據，而且只在事務日誌中記錄頁的釋放。

七、truncate table
刪除表中的全部行，但表結構及其列、約束、索引等保持不變。新行標識所用的計數值重置爲該列的種子。若是想保留標識計數值，請改用
delete

MHA的搭建

搭建MHA前期準備工做：

三臺服務器

主：50

從：51

從：52，兼職做爲manager

除了manager之外全部的節點都是node

node+manager兩種類型

一、三臺服務器安裝os，配置網絡，關閉防火牆和selinux

二、在三臺服務器上安裝mysql軟件，要求版本同樣

三、在三臺服務器上安裝xrtabackup

四、搭建主從

一主兩從

搭建兩次從服務器

不建議使用半同步複製

注意幾個點：

一、從庫都該成read-only模式

二、從庫的relay log自動刪除功能要關閉

三、三個數據庫的server_id必須不一致

log-bin = mysql-bin //要求全部可能成爲主庫的節點開啓二進制日誌

relay_log_purge = 0 //要求全部可能成爲主庫的節點都要配置此項

read_only = 1 //MHA 要求全部 slave 節點配置爲 read_only = 1

server-id = 2 //注意主從節點的 server-id 不一樣

五、安裝node和manager軟件，這個屬於mha軟件

安裝的時候，須要依賴不少的per軟件和Perl庫，所以可能會比較麻煩

去下載已經安裝好的虛擬機

六、配置互信（配置SSH免密登陸）

節點之間能夠互相執行命令、拷貝數據，這些都不須要密碼。

配置完成互信之後，必定要進行測試。

配置MHA:

一、先配置manager，manager上配置的主要是整個集羣的基本信息：

讓manager認識全部的節點，包括誰是主，誰優先成爲主

[server default]

manager_workdir=/var/log/masterha/app1

manager_log=/var/log/masterha/app1/manager.log

master_binlog_dir=/var/lib/mysql/data

master_ip_failover_script=/usr/bin/master_ip_failover //失敗切換

master_ip_online_change_script=/usr/bin/master_ip_online_change //主動切換

user=mha_monitor //manager 使用這個帳號鏈接各個數據庫

password=mha_monitor //manager 使用這個帳號密碼鏈接各個數據庫

ping_interval=1 //manager 每隔 1 秒鐘，探測一下各個節點

remote_workdir=/tmp //指定遠端目錄

repl_user=repl //各個節點之間的複製帳號和密碼

repl_password=repl

ssh_user=root

[server1]

hostname=192.168.10.50

#candidate_master=1

port=3306

[server2]

hostname=192.168.10.51

candidate_master=1 //指定 2 節點優先成爲主，建設沒有這個選項，默認使用最新的
slave 成爲主

check_repl_delay=0 //關閉延遲監測

port=3306

[server3]

hostname=192.168.10.52

port=3306

上面配置好之後，就能夠在 manager 上面執行相關的腳本進行測試

上面的配置就是告訴 manager，我這個集羣的基本信息

二、mha檢查ssh免密登陸：

masterha_check_ssh --conf=/etc/masterha/app1.cnf

三、mha檢查複製

masterha_check_repl --conf=/etc/masterha/app1.cnf

四、在主庫上配置虛擬 ip

# ifconfig eth0:1 192.168.10.223

五、在manager上配置漂移ip的腳本

manager須要使用這兩個腳本，在新的主上啓動漂移ip

master_ip_failover

master_ip_online_change

將這兩個中的全部地址改爲漂移ip地址就好了

這兩個腳本在manager節點上

六、啓動 manager：

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master
--ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1
&

建議：在啓動manager之前，啓動好主從

15.insert進去的是一條數據，select查找的是相同的數據。原理是怎麼實現的。

xtrabackup是否有行鎖(沒有行鎖，只有全局的鎖)

17.事務在底層是怎麼實現的

ignix的錯誤日誌在哪
where like 「%a’實際的業務中會使用到，怎麼解決這個問題

20、Zabbix創建的參數有哪些

事務運行原理

在innodb 中查詢到須要修改的數據頁

(1) 此時會發生latch(r)爭用,由於須要鎖住數據鏈對數據鏈進行遍歷

沒有找到的話釋放latch(r),去磁盤查找,發生物理讀
在磁盤中查找時分爲使用索引和不使用索引

(1) 使用索引會提升查詢速度,提升sql的工做效率

(2) 不使用索引會發生全表掃描,會致使大量數據涌入innodb_buffer_pool

查找到的數據會放到innodb_buffer_pool裏面

(1) 此時須要在innodb_buffer_pool中查找free或者clean頁

(2)
在查找free和clean頁時若是free已經所有用完並且在clean不夠用的狀況下會發生磁盤寫,致使db_write工做,而後也會更新redo和ondo,redo的做用是用來記錄未寫入到磁盤的髒數據的日誌,用於後期數據庫將在innodb_buffer_pool中的髒數據更新到磁盤中,ondo的做用是記錄髒數據以前的數據,用於用戶執行rollback操做

(3) 此時會發生latch(x)爭用,由於要將磁盤中的數據寫入到innodb_buffer_pool中

在數據從磁盤上將數據寫入到free或者clean中時,會發生waits特別是在數據的查找時沒有使用索引時會致使大量數據涌入innodb_buffer_pool,致使發生waits
釋放全部的latch

(1) 寫完數據後釋放latch(x)和latch(s)

將innodb_buffer_pool中的數據進行修改,增長pin鎖

(1)
Pin鎖的目的是爲了在修改的一瞬間保證這個數據頁不會被進行任何ddl操做,以免修改失敗

(2) 在修改開始前會對改數據行所在的數據頁增長表級別的ix鎖

① 用於避免此時其餘事務對該表執行ddl操做

(3)
修改過程當中會對要修改的行添加x鎖,使該行進入到排他狀態,以保證修改數據中,不會再其餘線程不會發生髒讀

此時若是有其餘用戶線程查找該行數據,會讀取到該行數據最新一次commit後的數據,而不會讀取到當前事務修改的數據,這也是爲了不髒
修改完數據後釋放pin鎖
當修改完數據後會發生undo和redo

(1) Undo記錄修改前的數據用於rollback

(2) redo用於記錄修改後的日誌寫入磁盤中的log file以用來慢慢更新髒數據

此時ix鎖和x鎖都沒有釋放,由於沒有發生commit

(1) 也就意味着此時該表仍然處於能夠進行的是select和dml不能進行ddl的狀態

(2)
固然若是dml中要更新的數據是被加了x鎖的這一行和讀取這一行數據也是不能夠的,由於該行處於x鎖狀態

commit提交

(1)
在數據修改爲功後,也就是該事務完成後提交,ix表鎖和x行鎖釋放,但數據不會及時的寫入到磁盤上,由於用經過redo進程中的log
file來後臺更新磁盤上的數據

ext4和ext3的區別

區別以下：

一、Ext3文件系統最多隻能支持32TB的文件系統和2TB的文件，根據使用的具體架構和系統設置，實際容量上限可能比這個數字還要低，即只能容納2TB的文件系統和16GB的文件。而Ext4的文件系統容量達到1EB，而文件容量則達到16TB，這是一個很是大的數字了。對通常的臺式機和服務器而言，這可能並不重要，但對於大型磁盤陣列的用戶而言，這就很是重要了。

二、Ext3目前只支持32000個子目錄，而Ext4取消了這一限制，理論上支持無限數量的子目錄。

三、Ext3文件系統使用32位空間記錄塊數量和i-節點數量，而Ext4文件系統將它們擴充到64位。

四、當數據寫入到Ext3文件系統中時，Ext3的數據塊分配器每次只能分配一個4KB的塊，若是寫一個100MB的文件就要調用25600次數據塊分配器，而Ext4的多塊分配器「Multiblock
Allocator（MBAlloc）」支持一次調用分配多個數據塊。

五、Ext3的數據塊分配策略是儘快分配，而Ext4的策略是儘量地延遲分配，直到文件在緩衝中寫完纔開始分配數據塊並寫入磁盤，這樣就能優化整個文件的數據塊分配，顯著提高性能。

六、Ext3文件系統採用間接映射地址，當操做大文件時，效率極其低下。例如，一個100MB大小的文件，在Ext3中要創建25600個數據塊（以每一個數據塊大小爲4KB爲例）的映射表；而Ext4引入了盤區概念，每一個盤區爲一組連續的數據塊，上述文件能夠經過盤區的方式表示爲「該文件數據保存在接下來的25600個數據塊中」，提升了訪問效率。

七、Ext4支持更大的i-節點。以前的Ext3默認的i-節點大小128字節，Ext4爲了在i-節點中容納更多的擴展屬性，默認i-節點大小爲256字節。另外，Ext4還支持快速擴展屬性和i-節點保留。

InnoDB與Myisam區別

	MyISAM	InnoDB
構成上的區別：	每一個MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始，擴展名指出文件類型。	基於磁盤的資源是InnoDB表空間數據文件和它的日誌文件，InnoDB 表的大小隻受限於操做系統文件的大小，通常爲 2GB
	.frm文件存儲表定義。
	數據文件的擴展名爲.MYD (MYData)。
	索引文件的擴展名是.MYI (MYIndex)。
事務處理上方面:	MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，可是不提供事務支持	InnoDB提供事務支持事務，外部鍵（foreign key）等高級數據庫功能
SELECT UPDATE,INSERT，Delete操做	若是執行大量的SELECT，MyISAM是更好的選擇	1.若是你的數據執行大量的INSERT或UPDATE，出於性能方面的考慮，應該使用InnoDB表
		2.DELETE FROM table時，InnoDB不會從新創建表，而是一行一行的刪除。
		3.LOAD TABLE FROM MASTER操做對InnoDB是不起做用的，解決方法是首先把InnoDB表改爲MyISAM表，導入數據後再改爲InnoDB表，可是對於使用的額外的InnoDB特性（例如外鍵）的表不適用
對AUTO_INCREMENT的操做	每表一個AUTO_INCREMEN列的內部處理。	若是你爲一個表指定AUTO_INCREMENT列，在數據詞典裏的InnoDB表句柄包含一個名爲自動增加計數器的計數器，它被用在爲該列賦新值。自動增加計數器僅被存儲在主內存中，而不是存在磁盤上關於該計算器的算法實現，請參考
	MyISAM爲INSERT和UPDATE操做自動更新這一列。這使得AUTO_INCREMENT列更快（至少10%）。在序列頂的值被刪除以後就不能再利用。(當AUTO_INCREMENT列被定義爲多列索引的最後一列，能夠出現重使用從序列頂部刪除的值的狀況）。	AUTO_INCREMENT列在InnoDB裏如何工做
	AUTO_INCREMENT值可用ALTER TABLE或myisamch來重置
	對於AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，可是在MyISAM表中，能夠和其餘字段一塊兒創建聯合索引更好和更快的auto_increment處理
表的具體行數	select count() from table,MyISAM只要簡單的讀出保存好的行數，注意的是，當count()語句包含 where條件時，兩種表的操做是同樣的	InnoDB 中不保存表的具體行數，也就是說，執行select count(*) from table時，InnoDB要掃描一遍整個表來計算有多少行
鎖	表鎖	提供行鎖(locking on row level)，提供與 Oracle 類型一致的不加鎖讀取(non-locking read in
		SELECTs)，另外，InnoDB表的行鎖也不是絕對的，若是在執行一個SQL語句時MySQL不能肯定要掃描的範圍，InnoDB表一樣會鎖全表，例如update table set num=1 where name like "%aaa%"

AWK命令

AWK命令用於對數據的提取，經常使用的還有grep和 sed 俗稱三劍客

AWK命令傾向於將一行分紅數個字段來處理，在shell腳本中是個強有力的工具用來對數據提取

AWK的經常使用語法

-F來指定分隔符

AWK的數據字段變量

$0表示整行文本

$1表示文本中第一個數據字段

$2表示文本中第二個數據字段

$n表示文本中第n個數據字段

AWK命令的完整語法

AWK命令的基本語法

awk的指令必定要用單引號括起

awk的動做必定要用花括號括起

模式能夠是正則表達式、條件表達式或兩種組合，條件表達式不能加/ /

若是模式是正則表達式要用/定界符

多個動做之間用;號分開

示例：awk -F: '/^[^h]/{print $1,$7}' /etc/passwd

不顯示以h開頭的行的第一列和第七列 [^h]表示不以h開頭的行

awk -F '[:/]' '{print $1,$10}' /etc/passwd

以：或者/做爲分隔符顯示第1列和第10列

AWK命令的語法

awk命令的操做符

正則表達式和bash一致

數學運算：+，-，*，/， %，++（自加一），- -（自減一）

邏輯關係符：&&， ||， !

比較操做符：>，<，>=，!=，<=，== ~ !~

文本數據表達式：== （精確匹配）

~波浪號表示匹配後面的模式，想要某個字段進行模式匹配，就要使用~（波浪符號）
使用格式：字段 ~ /模式/

who | awk '$2 ~ /pts/{print $1}‘

第二列要包含有pts，而後輸出第一列

awk -F: '$3 ~ /\<...\>/ {print $1,$3}' /etc/passwd

冒號做爲分隔符，第三列是三個字符的輸出第一列和第三列

seq 100 | awk '$1 % 5 == 0 || $1 ~ /^1/{print $1}'

輸出整除5的數和以1開頭的數

awk -F: '$1 == "root"{print $1,$3}' /etc/passwd

第一個字段等於root就輸出第一個字段和第三個字段

阿里7題

問題1：你以前處理過MySQL的哪些案例？

解答思路：說到案例，逃離不了MySQL的五大知識模塊：體系結構、數據的備份恢復、複製、高可用集羣架構和優化。咱們能夠從這五個方向着手考慮，好比：

MySQL版本的升級；

處理集羣架構中的各類「坑」和問題（你遇到過的就能夠）；

根據公司業務類型，合理設計MySQL庫、表和後期架構；

按期進行災備恢復演練；

恢復誤刪除的數據信息。

問題2：什麼是死鎖？鎖等待？如何優化這類問題？經過數據庫哪些表能夠監控？

解答思路：死鎖是指兩個或多個事務在同一資源上互相佔用，並請求加鎖時，而致使的惡性循環現象。當多個事務以不一樣順序試圖加鎖同一資源時，就會產生死鎖。

鎖等待：MySQL數據庫中，不一樣session在更新同行數據時，會出現鎖等待的現象。重要的三張鎖的監控表：innodb_trx、innodb_locks和innodb_lock_waits。

問題3：MySQL主從複製的具體原理是什麼？

解答思路：直接闡述原理便可，表達必定要清楚。

主服務器把數據更新記錄到二進制日誌中，從服務器經過I/O
thread向主庫發起binlog請求，主服務器經過I/O dump
thread把二進制日誌傳遞給從庫，從庫經過I/O
thread記錄到本身的中繼日誌中。而後再經過SQL thread應用中繼日誌中SQL的內容。

問題4：MySQL有哪些索引類型？

解答思路：能夠從三個角度去談。

首先從數據結構角度上能夠分爲B+tree索引、hash索引、fulltext索引（InnoDB、MyISAM都支持）。其次從存儲角度上能夠分爲彙集索引和非彙集索引。最後邏輯角度上能夠分爲primary
key、normal key、單列、複合和覆蓋索引。

問題5：服務器負載太高或者網頁打開緩慢，簡單說說你的優化思路？

解答思路：咱們能夠經過前面講過的優化思路中的四維度模型去闡述。

首先要發現問題的過程，經過操做系統、數據庫、程序設計、硬件角度四個維度找到問題所在。先找到瓶頸點的位置，制定好優化方案，造成處理問題的體系模型。體系制定好以後，在測試環境進行優化方案的測試。測試環境下若是優化效果很好，再實施到生產環境上。最後作好處理問題的記錄。好記性不如爛筆頭，多作總結，方可大步前進。

問題6：如何優化一條慢SQL語句？

解答思路：針對SQL語句的優化，咱們不要一上來就回答添加索引，這樣顯得太不專業。咱們能夠從以下幾個角度去分析：

①迴歸到表的設計層面，數據類型選擇是否合理。

②大表碎片的整理是否完善。

③表的統計信息是否是準確的。

④審查表的執行計劃，判斷字段上面有沒有合適的索引。

⑤針對索引的選擇性，創建合適的索引（就又涉及大表DDL的操做問題。因此說，咱們要有能力把各個知識點聯繫起來）

問題7：爲何要爲InnoDB表設置自增列作主鍵？

解答思路：使用自增列作主鍵，寫入順序是自增的，和B+數葉子節點分裂順序一致。InnoDB表的數據寫入順序能和B+樹索引的葉子節點順序一致時，存取效率是最高的。

知乎60題

Mysql中有哪幾種鎖？

1.表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的機率最高，併發度最低。

2.行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的機率最低，併發度也最高。

頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度通常。

Mysql中有哪些不一樣的表格？

共有5種類型的表格：

MyISAM

Heap

Merge

INNODB

ISAM

簡述在MySQL數據庫中MyISAM和InnoDB的區別

MyISAM：

不支持事務，可是每次查詢都是原子的；

支持表級鎖，即每次操做是對整個表加鎖；

存儲表的總行數；

一個MYISAM表有三個文件：索引文件、表結構文件、數據文件；

採用菲彙集索引，索引文件的數據域存儲指向數據文件的指針。輔索引與主索引基本一致，可是輔索引不用保證惟一性。

InnoDb：

支持ACID的事務，支持事務的四種隔離級別；

支持行級鎖及外鍵約束：所以能夠支持寫併發；

不存儲總行數；

一個InnoDb引擎存儲在一個文件空間（共享表空間，表大小不受操做系統控制，一個表可能分佈在多個文件裏），也有可能爲多個（設置爲獨立表空，表大小受操做系統文件大小限制，通常爲2G），受操做系統文件大小的限制；

主鍵索引採用彙集索引（索引的數據域存儲數據文件自己），輔索引的數據域存儲主鍵的值；所以從輔索引查找數據，須要先經過輔索引找到主鍵值，再訪問輔索引；最好使用自增主鍵，防止插入數據時，爲維持B+樹結構，文件的大調整。

Mysql中InnoDB支持的四種事務隔離級別名稱，以及逐級之間的區別？

read uncommited ：讀到未提交數據

read committed：髒讀，不可重複讀

repeatable read：可重讀

serializable ：串行事物

CHAR和VARCHAR的區別？

1.CHAR和VARCHAR類型在存儲和檢索方面有所不一樣
2.CHAR列長度固定爲建立表時聲明的長度，長度值範圍是1到255
當CHAR值被存儲時，它們被用空格填充到特定長度，檢索CHAR值時需刪除尾隨空格。

主鍵和候選鍵有什麼區別？

表格的每一行都由主鍵惟一標識,一個表只有一個主鍵。

主鍵也是候選鍵。按照慣例，候選鍵能夠被指定爲主鍵，而且能夠用於任何外鍵引用。

myisamchk是用來作什麼的？

它用來壓縮MyISAM表，這減小了磁盤或內存使用。

MyISAM Static和MyISAM Dynamic有什麼區別？

在MyISAM
Static上的全部字段有固定寬度。動態MyISAM表將具備像TEXT，BLOB等字段，以適應不一樣長度的數據類型。

MyISAM Static在受損狀況下更容易恢復。

若是一個表有一列定義爲TIMESTAMP，將發生什麼？

每當行被更改時，時間戳字段將獲取當前時間戳。

列設置爲AUTO INCREMENT時，若是在表中達到最大值，會發生什麼狀況？

它會中止遞增，任何進一步的插入都將產生錯誤，由於密鑰已被使用。

怎樣才能找出最後一次插入時分配了哪一個自動增量？

LAST_INSERT_ID將返回由Auto_increment分配的最後一個值，而且不須要指定表名稱。

你怎麼看到爲表格定義的全部索引？

索引是經過如下方式爲表格定義的：

SHOW INDEX FROM
<tablename>;

LIKE聲明中的％和_是什麼意思？

％對應於0個或更多字符，_只是LIKE語句中的一個字符。

如何在Unix和Mysql時間戳之間進行轉換？

UNIX_TIMESTAMP是從Mysql時間戳轉換爲Unix時間戳的命令
FROM_UNIXTIME是從Unix時間戳轉換爲Mysql時間戳的命令

列對比運算符是什麼？

在SELECT語句的列比較中使用=，<>，<=，<，>
=，>，<<，>>，<=>，AND，OR或LIKE運算符。

BLOB和TEXT有什麼區別？

BLOB是一個二進制對象，能夠容納可變數量的數據。TEXT是一個不區分大小寫的BLOB。

BLOB和TEXT類型之間的惟一區別在於對BLOB值進行排序和比較時區分大小寫，對TEXT值不區分大小寫。

mysql_fetch_array和mysql_fetch_object的區別是什麼？

如下是mysql_fetch_array和mysql_fetch_object的區別：

mysql_fetch_array（） – 將結果行做爲關聯數組或來自數據庫的常規數組返回。

mysql_fetch_object – 從數據庫返回結果行做爲對象。

MyISAM表格將在哪裏存儲，而且還提供其存儲格式？

每一個MyISAM表格以三種格式存儲在磁盤上：

·「.frm」文件存儲表定義

·數據文件具備「.MYD」（MYData）擴展名

索引文件具備「.MYI」（MYIndex）擴展名

Mysql如何優化DISTINCT？

DISTINCT在全部列上轉換爲GROUP BY，並與ORDER BY子句結合使用。

SELECT DISTINCT t1.a FROM t1,t2 where t1.a=t2.a;

如何顯示前50行？

在Mysql中，使用如下代碼查詢顯示前50行：

SELECT*FROM

LIMIT 0,50;

能夠使用多少列建立索引？

任何標準表最多能夠建立16個索引列。

NOW（）和CURRENT_DATE（）有什麼區別？

NOW（）命令用於顯示當前年份，月份，日期，小時，分鐘和秒。

CURRENT_DATE（）僅顯示當前年份，月份和日期。

什麼是非標準字符串類型？

TINYTEXT

TEXT

MEDIUMTEXT

LONGTEXT

什麼是通用SQL函數？

CONCAT(A, B) –
鏈接兩個字符串值以建立單個字符串輸出。一般用於將兩個或多個字段合併爲一個字段。

FORMAT(X, D)- 格式化數字X到D有效數字。

CURRDATE(), CURRTIME()- 返回當前日期或時間。

NOW（） – 將當前日期和時間做爲一個值返回。

MONTH（），DAY（），YEAR（），WEEK（），WEEKDAY（） – 從日期值中提取給定數據。

HOUR（），MINUTE（），SECOND（） – 從時間值中提取給定數據。

DATEDIFF（A，B） – 肯定兩個日期之間的差別，一般用於計算年齡

SUBTIMES（A，B） – 肯定兩次之間的差別。

FROMDAYS（INT） – 將整數天數轉換爲日期值。

MYSQL支持事務嗎？

在缺省模式下，MYSQL是autocommit模式的，全部的數據庫更新操做都會即時提交，因此在缺省狀況下，mysql是不支持事務的。

可是若是你的MYSQL表類型是使用InnoDB Tables 或 BDB
tables的話，你的MYSQL就能夠使用事務處理,使用SET
AUTOCOMMIT=0就能夠使MYSQL容許在非autocommit模式，在非autocommit模式下，你必須使用COMMIT來提交你的更改，或者用ROLLBACK來回滾你的更改。

mysql裏記錄貨幣用什麼字段類型好

NUMERIC和DECIMAL類型被Mysql實現爲一樣的類型，這在SQL92標準容許。他們被用於保存值，該值的準確精度是極其重要的值，例如與金錢有關的數據。當聲明一個類是這些類型之一時，精度和規模的能被(而且一般是)指定。

例如：

salary DECIMAL(9,2)

在這個例子中，9(precision)表明將被用於存儲值的總的小數位數，而2(scale)表明將被用於存儲小數點後的位數。

所以，在這種狀況下，能被存儲在salary列中的值的範圍是從-9999999.99到9999999.99。

mysql有關權限的表都有哪幾個？

Mysql服務器經過權限表來控制用戶對數據庫的訪問，權限表存放在mysql數據庫裏，由mysql_install_db腳本初始化。這些權限表分別user，db，table_priv，columns_priv和host。

列的字符串類型能夠是什麼？

字符串類型是：

SET

BLOB

ENUM

CHAR

TEXT

MySQL數據庫做發佈系統的存儲，一天五萬條以上的增量，預計運維三年,怎麼優化？

a. 設計良好的數據庫結構，容許部分數據冗餘，儘可能避免join查詢，提升效率。

b. 選擇合適的表字段數據類型和存儲引擎，適當的添加索引。

c. mysql庫主從讀寫分離。

d. 找規律分表，減小單表中的數據量提升查詢速度。
e。添加緩存機制，好比memcached，apc等。

f. 不常常改動的頁面，生成靜態頁面。

g. 書寫高效率的SQL。好比 SELECT * FROM TABEL 改成 SELECT field_1, field_2,
field_3 FROM TABLE.

鎖的優化策略

讀寫分離
分段加鎖
減小鎖持有的時間
多個線程儘可能以相同的順序去獲取資源

不能將鎖的粒度過於細化，否則可能會出現線程的加鎖和釋放次數過多，反而效率不如一次加一把大鎖。

索引的底層實現原理和優化

B+樹，通過優化的B+樹

主要是在全部的葉子結點中增長了指向下一個葉子節點的指針，所以InnoDB建議爲大部分表使用默認自增的主鍵做爲主索引。

什麼狀況下設置了索引但沒法使用

1.以「%」開頭的LIKE語句，模糊匹配

OR語句先後沒有同時使用索引
數據類型出現隱式轉化（如varchar不加單引號的話可能會自動轉換爲int型）

實踐中如何優化MySQL

最好是按照如下順序優化：

1.SQL語句及索引的優化

數據庫表結構的優化

3.系統配置的優化

4.硬件的優化

優化數據庫的方法

選取最適用的字段屬性，儘量減小定義字段寬度，儘可能把字段設置NOTNULL，例如’省份’、’性別’最好適用ENUM

使用鏈接(JOIN)來代替子查詢

適用聯合(UNION)來代替手動建立的臨時表

事務處理

鎖定表、優化事務處理

適用外鍵，優化鎖定表

創建索引

優化查詢語句

簡單描述mysql中，索引，主鍵，惟一索引，聯合索引的區別，對數據庫的性能有什麼影響（從讀寫兩方面）

索引是一種特殊的文件(InnoDB數據表上的索引是表空間的一個組成部分)，它們包含着對數據表裏全部記錄的引用指針。

普通索引(由關鍵字KEY或INDEX定義的索引)的惟一任務是加快對數據的訪問速度。

普通索引容許被索引的數據列包含重複的值。若是能肯定某個數據列將只包含彼此各不相同的值，在爲這個數據列建立索引的時候就應該用關鍵字UNIQUE把它定義爲一個惟一索引。也就是說，惟一索引能夠保證數據記錄的惟一性。

主鍵，是一種特殊的惟一索引，在一張表中只能定義一個主鍵索引，主鍵用於惟一標識一條記錄，使用關鍵字
PRIMARY KEY 來建立。

索引能夠覆蓋多個數據列，如像INDEX(columnA, columnB)索引，這就是聯合索引。

索引能夠極大的提升數據的查詢速度，可是會下降插入、刪除、更新表的速度，由於在執行這些寫操做時，還要操做索引文件。

數據庫中的事務是什麼?

事務特性：

（1）原子性：即不可分割性，事務要麼所有被執行，要麼就所有不被執行。

（2）一致性或可串性。事務的執行使得數據庫從一種正確狀態轉換成另外一種正確狀態

（3）隔離性。在事務正確提交以前，不容許把該事務對數據的任何改變提供給任何其餘事務，

（4）
持久性。事務正確提交後，其結果將永久保存在數據庫中，即便在事務提交後有了其餘故障，事務的處理結果也會獲得保存。

或者這樣理解：

SQL注入漏洞產生的緣由？如何防止？

SQL注入產生的緣由：程序開發過程當中不注意規範書寫sql語句和對特殊字符進行過濾，致使客戶端能夠經過全局變量POST和GET提交一些sql語句正常執行。

防止SQL注入的方式：
開啓配置文件中的magic_quotes_gpc 和 magic_quotes_runtime設置

執行sql語句時使用addslashes進行sql語句轉換

Sql語句書寫儘可能不要省略雙引號和單引號。

過濾掉sql語句中的一些關鍵詞：update、insert、delete、select、 * 。

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

爲表中得字段選擇合適得數據類型

字段類型優先級: 整形>date,time>enum,char>varchar>blob,text
優先考慮數字類型，其次是日期或者二進制類型，最後是字符串類型，同級別得數據類型，應該優先選擇佔用空間小的數據類型

存儲時期

Datatime:以 YYYY-MM-DD HH:MM:SS
格式存儲時期時間，精確到秒，佔用8個字節得存儲空間，datatime類型與時區無關
Timestamp:以時間戳格式存儲，佔用4個字節，範圍小1970-1-1到2038-1-19，顯示依賴於所指定得時區，默認在第一個列行的數據修改時能夠自動得修改timestamp列得值
Date:（生日）佔用得字節數比使用字符串.http://datatime.int儲存要少，使用date只須要3個字節，存儲日期月份，還能夠利用日期時間函數進行日期間得計算
Time:存儲時間部分得數據
注意:不要使用字符串類型來存儲日期時間數據（一般比字符串佔用得儲存空間小，在進行查找過濾能夠利用日期得函數）
使用int存儲日期時間不如使用timestamp類型

對於關係型數據庫而言，索引是至關重要的概念，請回答有關索引的幾個問題：

1.索引的目的是什麼？
快速訪問數據表中的特定信息，提升檢索速度
建立惟一性索引，保證數據庫表中每一行數據的惟一性。
加速表和表之間的鏈接

使用分組和排序子句進行數據檢索時，能夠顯著減小查詢中分組和排序的時間

3.爲數據表創建索引的原則有哪些？
在最頻繁使用的、用以縮小查詢範圍的字段上創建索引。

在頻繁使用的、須要排序的字段上創建索引

4.什麼狀況下不宜創建索引？
對於查詢中不多涉及的列或者重複值比較多的列，不宜創建索引。

對於一些特殊的數據類型，不宜創建索引，好比文本字段（text）等

解釋MySQL外鏈接、內鏈接與自鏈接的區別

先說什麼是交叉鏈接:
交叉鏈接又叫笛卡爾積，它是指不使用任何條件，直接將一個表的全部記錄和另外一個表中的全部記錄一一匹配。

內鏈接
則是隻有條件的交叉鏈接，根據某個條件篩選出符合條件的記錄，不符合條件的記錄不會出如今結果集中，即內鏈接只鏈接匹配的行。
外鏈接其結果集中不只包含符合鏈接條件的行，並且還會包括左表、右表或兩個表中
的全部數據行，這三種狀況依次稱之爲左外鏈接，右外鏈接，和全外鏈接。

左外鏈接，也稱左鏈接，左表爲主表，左表中的全部記錄都會出如今結果集中，對於那些在右表中並無匹配的記錄，仍然要顯示，右邊對應的那些字段值以NULL來填充。右外鏈接，也稱右鏈接，右表爲主表，右表中的全部記錄都會出如今結果集中。左鏈接和右鏈接能夠互換，MySQL目前還不支持全外鏈接。

Myql中的事務回滾機制概述

事務是用戶定義的一個數據庫操做序列，這些操做要麼全作要麼全不作，是一個不可分割的工做單位，事務回滾是指將該事務已經完成的對數據庫的更新操做撤銷。

要同時修改數據庫中兩個不一樣表時，若是它們不是一個事務的話，當第一個表修改完，可能第二個表修改過程當中出現了異常而沒能修改，此時就只有第二個表依舊是未修改以前的狀態，而第一個表已經被修改完畢。而當你把它們設定爲一個事務的時候，當第一個表修改完，第二表修改出現異常而沒能修改，第一個表和第二個表都要回到未修改的狀態，這就是所謂的事務回滾

SQL語言包括哪幾部分？每部分都有哪些操做關鍵字？

SQL語言包括數據定義(DDL)、數據操縱(DML),數據控制(DCL)和數據查詢（DQL）四個部分。

數據定義：Create Table,Alter Table,Drop Table, Craete/Drop Index等

數據操縱：Select ,insert,update,delete,

數據控制：grant,revoke

數據查詢：select

完整性約束包括哪些？
數據完整性(Data Integrity)是指數據的精確(Accuracy)和可靠性(Reliability)。

分爲如下四類：

1) 實體完整性：規定表的每一行在表中是唯一的實體。

2)
域完整性：是指表中的列必須知足某種特定的數據類型約束，其中約束又包括取值範圍、精度等規定。

3)
參照完整性：是指兩個表的主關鍵字和外關鍵字的數據應一致，保證了表之間的數據的一致性，防止了數據丟失或無心義的數據在數據庫中擴散。

4)
用戶定義的完整性：不一樣的關係數據庫系統根據其應用環境的不一樣，每每還須要一些特殊的約束條件。用戶定義的完整性便是針對某個特定關係數據庫的約束條件，它反映某一具體應用必須知足的語義要求。