mysql開發相關

1.mysql事務原理,特性,事務併發控制
2.如何解決高併發場景下的插入重複
3.樂觀鎖和悲觀鎖
4.經常使用數據庫引擎之間區別
5.mysql索引
6.B-Tree
7.mysql索引類型
8.何時建立索引
9.索引何時失效(模糊匹配,類型隱轉,最左匹配)
10.什麼是彙集索引和非彙集索引(輔助索引)
11.如何排查和消除慢查詢
12.SQL語句編寫
內連接(inner join)
外鏈接(left/right join)
全鏈接(full join)
13.MyISAM和InnoDB搜索引擎的特色
14.char 和varchar字符串類型的區別？
15.mysql索引相關介紹。
16.MySQL在如下操做場景下會使用索引
17.mysql中隨着數據量的增大，查詢速度會愈來愈慢，請給出簡易的優化方案。
18.關係型數據庫中，表與表之間有左鏈接、內鏈接、外鏈接，分別指出他們的含義及區別？

 

1.關係型數據庫的三範式
2.事務的四大特徵
3.mysql數據庫最大鏈接數
4.mysql的分頁語句
5.觸發器的使用場景？
6.存儲過程的優勢
7.jdbc調用存儲過程
8.簡單說一下你對jdbc的理解
9.寫一個jdbc的訪問oracle的列子
10.jdbc中preparedStatement比Statement的好處
11.數據庫鏈接池的做用
12.ORM是什麼？ORM框架是什麼？
13.ibatis和hibernate有什麼不一樣
14.hibernate對象狀態及其轉換
15.hibernate的緩存
16.數據庫優化方面的事情
17.若是查詢和定位慢查詢
18.數據庫優化之數據庫表設計遵循範式
19.選擇合適的數據庫引擎
20.選擇合適的索引
21.使用索引的一些技巧
22.數據庫優化之分表
23.數據庫的讀寫分離
24.數據庫優化之緩存
25.sql語句優化小技巧
26.批量插入幾百萬條數據

 

1.mysql事務原理,特性,事務併發控制
事務是數據庫併發控制的基本單位
事務能夠看做是一系列SQL語句的集合
事務必需要麼所有執行成功,要麼所有執行失敗(回滾)
轉帳操做是事務使用最多見的場景

ACID是事務的四個基本特性
原子性:一個事務中全部操做所有完成或失敗
一致性:事務開始和結束以後數據完整性沒有被破壞
隔離性:容許多個事務同時對數據庫修改和讀寫
持久性:事務結束以後,修改是永久的不會丟失

事務的併發控制可能產生的問題(四種異常狀況)
幻讀:一個事務第二次查出現第一次沒有的結果
非重複讀:一個事務重複讀兩次獲得不一樣的結果
髒讀:一個事務讀取到另外一個事務沒有提交的修改
丟失修改:併發寫入形成其中一些修改丟失

解決以上4種異常,定義了4種事務隔離級別
讀未提交:別的事務能夠讀取到未提交改變
讀已提交:只能讀取已經提交的數據
可重複讀:同一個事務前後查詢結果同樣(innodb默認實現可重複讀級別)
串行化:事務徹底串行化的執行,隔離級別最高,執行效率最低

如何解決高併發場景下的插入重複
高併發場景下,寫入數據庫會有數據重複問題
使用數據庫的惟一索引
使用隊列異步寫入
使用redis實現分佈式鎖

樂觀鎖和悲觀鎖
悲觀鎖是先獲取鎖再進行操做。一鎖二查三更新 (select for update)
樂觀鎖先修改,更新的時候發現數據已經變了就回滾(check and set) 通常經過版本號或時間戳實現
使須要根據響應速度,衝突頻率,重試代價來判斷使用哪種

經常使用字段,含義和區別
字符串 char/varchar/text
數值 tinyint/smallint/bigint/int/float/double length 數據庫可見長度
日期和時間 date/datetime/timestamp

經常使用數據庫引擎之間區別
innodb/myisam
myisam不支持事務/innodb支持事務
myisam不支持外鍵/innodb支持外鍵
myisam只支持表鎖/innodb支持行鎖和表鎖
myisam支持全文索引/innodb不支持全文索引

mysql索引
索引的原理、類型、結構
索引是數據表中一個或者多個列進行排序的數據結構
索引可以大幅提高檢索速度
建立、更新索引自己也會消耗空間和時間

B-Tree
查找結構進化史
線性查找:一個個找;實現簡單;太慢
二分查找:有序;簡單;要求是有序的,插入特別慢
HASH:查詢快;佔用空間;不太適合存儲大規模數據
二叉樹:插入和查詢很快;沒法存大規模數據,複雜度退化
平衡樹:解決bst退化問題,樹是平衡的;節點很是多的時候,依然樹高很高
多路查找樹:一個父親多個孩子節點(度/階);節點過多樹高不會特別深
多路平衡查找樹:B-Tree(每一個節點最多m(m>=2)個孩子,稱爲m階或者度) 階的大小是根據磁盤塊的4k大小來肯定
葉節點具備相同的深度
節點中的數據key從左到右是遞增的
B+樹
只在葉子節點帶有指向記錄的指針(能夠增長樹的度) 根據磁盤塊大小來肯定一個節點來存儲多個階
葉子節點經過指針相連。實現範圍查詢

mysql索引類型
普通索引 (create index)
惟一索引,索引列的值必須惟一(create unique index)
多列索引 B+樹的key是由多個列組成的
主鍵索引(primary key),一個表只能有一個
全文索引(fulltext index),innodb不支持, 倒排索引實現 es

何時建立索引
建表的時候須要根據查詢需求來建立索引
常常用做查詢條件的字段(where條件)
常常用做錶鏈接的字段
常常出如今order by，group by以後的字段

建立索引有哪些須要注意的 最佳實踐
非空字段 not null，mysql很難對空值作查詢優化 建表規範要求索引字段有默認值
區分度高,離散度大,做爲索引的字段值儘可能不要有大量相同值
索引的長度不要太長(比較耗費時間)

索引何時失效(模糊匹配,類型隱轉,最左匹配) 索引失效是由於key無法比較
以%開頭的LIKE語句,模糊搜索
出現隱式類型轉換(在python這種動態語言查詢中須要注意)
沒有知足最左前綴原則,無法直接比較

什麼是彙集索引和非彙集索引(輔助索引)
區別是B+Tree葉節點存的是指針仍是數據記錄
myisam索引和數據分離,使用的是非彙集索引
innodb數據文件是索引文件,主鍵索引是彙集索引

如何排查和消除慢查詢
慢查詢一般是缺乏索引,索引不合理或者業務代碼實現致使
slow_query_log_file 開啓而且查詢慢查詢日誌
經過explain排查索引問題
調整數據修改索引;業務代碼層限制不合理訪問

SQL語句編寫
內連接(inner join) 兩個表都存在匹配時,纔會返回匹配行
將左表和右表可以關聯起來的數據鏈接後返回
相似於求兩個表的"交集"
select * from A inner join B on a.id=b.id;

外鏈接(left/right join) 返回一個表的行,即便另外一個沒有匹配
左鏈接返回左表中全部記錄,即便右表中沒有匹配的記錄
右鏈接返回右表中全部記錄,即便左表中沒有匹配的記錄
沒有匹配的字段會設置成NULL
select * from A left join B on A.id=B.id;

全鏈接(full join) 只要某一個表存在匹配就返回
oracle裏面有full join,可是在mysql中沒有full join。咱們可使用union來達到目的。
select * from t1 left join t2 on t1.id = t2.id union select * from t1 right join t2 on t1.id = t2.id;

 

MyISAM和InnoDB搜索引擎的特色
存儲引擎說白了就是如何存儲數據、如何爲存儲的數據創建索引和如何更新、查詢數據等技術的實現方法。因此存儲引擎也能夠稱爲表類型。

MyISAM：
特色：
（1）不支持事務：MyISAM存儲引擎不支持事務，因此對事務有要求的業務場景不能使用
（2）表級鎖定：其鎖定機制是表級索引，這雖然可讓鎖定的實現成本很小可是也同時大大下降了其併發性能
（3）讀寫互相阻塞：不只會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀自己並不會阻塞另外的讀
（4）只會緩存索引：MyISAM能夠經過key_buffer緩存以大大提升訪問性能減小磁盤IO，可是這個緩存區只會緩存索引，而不會緩存數據
適用場景：
（1）不須要事務支持（不支持）
（2）併發相對較低（鎖定機制問題）
（3）數據修改相對較少（阻塞問題）
（4）以讀爲主
（5）數據一致性要求不是很是高
InnoDB：
特色：
（1）具備較好的事務支持：支持4個事務隔離級別，支持多版本讀
（2）行級鎖定：經過索引實現，全表掃描仍然會是表鎖，注意間隙鎖的影響
（3）讀寫阻塞與事務隔離級別相關
（4）具備很是高效的緩存特性：能緩存索引，也能緩存數據
（5）整個表和主鍵以Cluster方式存儲，組成一顆平衡樹
（6）全部Secondary Index都會保存主鍵信息
適用場景：
（1）須要事務支持（具備較好的事務特性）
（2）行級鎖定對高併發有很好的適應能力，但須要確保查詢是經過索引完成
（3）數據更新較爲頻繁的場景
（4）數據一致性要求較高
（5）硬件設備內存較大，能夠利用InnoDB較好的緩存能力來提升內存利用率，儘量減小磁盤 IO

char 和varchar字符串類型的區別？
char類型：定長，存入字符長度大於設置長度時報錯，存入字符長度小於設置長度時，會用空格填充，達到設置字符長度，簡單粗暴，浪費空間，存取速度快。
Varchar類型：varchar類型存儲數據的真實內容，不會用空格填充，會在真實數據前加1-2Bytes的前綴，該前綴用來表示真實數據的bytes字節數，變長，精準，節省空間，存取速度慢。
雖然varchar使用起來較爲靈活，可是從整個系統的性能角度來講，char數據類型的處理速度更快，有時甚至能夠超出varchar處理速度的50%。所以，用戶在設計數據庫時應當綜合考慮各方面的因素，以求達到最佳的平衡。

foreign key外鍵關聯（一對多）實例。
create table press(
id int primary key auto_increment,
name varchar(20)
);

create table book(
id int primary key auto_increment,
name varchar(20),
press_id int not null,
foreign key(press_id) references press(id)
on delete cascade
on update cascade

);

mysql索引相關介紹。

索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表能夠有多個單列索引，但這不是組合索引。組合索引，即一個索引包含多個列。MySQL索引的創建對於MySQL的高效運行是很重要的，索引能夠大大提升MySQL的檢索速度。實際上，索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄。

上面都在說使用索引的好處，但過多的使用索引將會形成濫用。所以索引也會有它的缺點：雖然索引大大提升了查詢速度，同時卻會下降更新表的速度，如對錶進行INSERT、UPDATE和DELETE。由於更新表時，MySQL不只要保存數據，還要保存一下索引文件。創建索引會佔用磁盤空間的索引文件。

聯合索引命中規則是：最左匹配規則，以下聯合索引（姓名，年齡，性別）：

諸如select * from user where name= ‘zzz’ and sex=’male’ and age=18查詢語句，當對name、sex、age分別創建列索引和創建（name、sex、age）組合索引時，查詢的結果是不同的，組合索引效率高於多個列索引，由於在執行多個列索引的時候，mysql只會選擇其中一個效率最高的。可是經過組合索引就直接鎖定那一條信息了。因爲組合索引的最左匹配原則，上述組合索引至關於分別創建（name），（name、sex）,（name、sex、age）這樣的三個索引，只有查詢條件與這三個順序相一致的纔會用到組合索引。

MySQL在如下操做場景下會使用索引
1) 快速查找符合where條件的記錄
2) 快速肯定候選集。若where條件使用了多個索引字段，則MySQL會優先使用能使候選記錄集規模最小的那個索引，以便儘快淘汰不符合條件的記錄。
3) 若是表中存在幾個字段構成的聯合索引，則查找記錄時，這個聯合索引的最左前綴匹配字段也會被自動做爲索引來加速查找。
例如，若爲某表建立了3個字段(c1, c2, c3)構成的聯合索引，則(c1), (c1, c2), (c1, c2, c3)均會做爲索引，(c2, c3)就不會被做爲索引，而(c1, c3)其實只利用到c1索引。
4) 多表作join操做時會使用索引（若是參與join的字段在這些表中均創建了索引的話）。
5) 若某字段已創建索引，求該字段的min()或max()時，MySQL會使用索引。
6) 對創建了索引的字段作sort或group操做時，MySQL會使用索引。

mysql中隨着數據量的增大，查詢速度會愈來愈慢，請給出簡易的優化方案。
1.合理的添加索引（mysql默認只會btree類型索引）；
mysql常見的索引：
普通索引INDEX：加速查找

惟一索引：
-主鍵索引PRIMARY KEY：加速查找+約束（不爲空、不能重複）
-惟一索引UNIQUE:加速查找+約束（不能重複）

聯合索引：
-PRIMARY KEY(id,name):聯合主鍵索引
-UNIQUE(id,name):聯合惟一索引
-INDEX(id,name):聯合普通索引
二、避免使用select *
三、建立表時儘可能用char代替varchar
四、表的字段順序，固定長度的優先
五、組合索引代替多個單列索引
六、使用鏈接（join）代替子查詢
七、使用explain優化神器

 

關係型數據庫中，表與表之間有左鏈接、內鏈接、外鏈接，分別指出他們的含義及區別？
一、 交叉鏈接：不使用任何匹配條件生成笛卡爾積
select * from employee,department

二、內鏈接：只鏈接匹配的行
selcet employee.name,employee.age,department.name from employee inner join department on employee.dep_id = department.id
三、外鏈接之左鏈接：優先顯示左表所有內容
selcet employee.name,employee.age,department.name from employee left join department on employee.dep_id = department.id
四、外鏈接之右鏈接：優先顯示右表所有內容
selcet employee.name,employee.age,department.name from employee right join department on employee.dep_id = department.id
五、全外鏈接：顯示左右兩個表所有記錄(mysql不支持full join)，實現方式以下：
select * from employee left join department on employee.dep_id = department.id
union
select * from employee right join department on employee.dep_id = department.id

 

1.關係型數據庫的三範式
範式就是規範,就是關係型數據庫在設計表時，要遵循的三個規範。要想知足第二範式必須先知足第一範式，要知足第三範式必須先知足第二範式。
第一範式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。列數據的不可分割
二範式（2NF）要求數據庫表中的每一個行必須能夠被惟一地區分。爲實現區分一般須要爲表加上一個列，以存儲各個實例的惟一標識。(主鍵)
知足第三範式（3NF）必須先知足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。(外鍵)
反三範式,有的時候爲了效率，能夠設置重複或者能夠推導出的字段.訂單（總價）和訂單項（單價）

2.事務的四大特徵
事務是併發控制的單位，是用戶定義的一個操做序列。這些操做要麼都作，要麼都不作，是一個不可分割的工做單位。
一個轉帳必須 A帳號扣錢成功，B帳號加錢成功，纔算正真的轉帳成功。
事務必須知足四大特徵:原子性,一致性,隔離性持久性/持續性
原子性：表示事務內操做不可分割。要麼都成功、要麼都是失敗.
一致性：要麼都成功、要麼都是失敗.後面的失敗了要對前面的操做進行回滾。
隔離性：一個事務開始後，不能後其餘事務干擾。
持久性/持續性：表示事務開始了，就不能終止。

3.mysql數據庫最大鏈接數
100
爲何須要最大鏈接數?特定服務器上面的數據庫只能支持必定數目同時鏈接,這時候咱們通常都會設置最大鏈接數(最多同時服務多少鏈接)。
在數據庫安裝時都會有一個默認的最大鏈接數爲100

4.mysql的分頁語句
爲何須要分頁?在不少數據是,不可能徹底顯示數據.進行分段顯示.Mysql是使用關鍵字limit來進行分頁的 limit offset,size 表示從多少索引去多少位.

5.觸發器的使用場景？
觸發器，須要有觸發條件，當條件知足之後作什麼操做。

6.存儲過程的優勢
一、存儲過程只在建立時進行編譯，之後每次執行存儲過程都不需再從新編譯，而通常 SQL 語句每執行一次就編譯一次，所以使用存儲過程能夠大大提升數據庫執行速度。
二、一般，複雜的業務邏輯須要多條 SQL 語句。這些語句要分別地從客戶機發送到服務器，當客戶機和服務器之間的操做不少時，將產生大量的網絡傳輸。若是將這些操做放在一個存儲過程當中，那麼客戶機和服務器之間的網絡傳輸就會大大減小，下降了網絡負載。
三、存儲過程建立一次即可以重複使用，從而能夠減小數據庫開發人員的工做量。
四、安全性高，存儲過程能夠屏蔽對底層數據庫對象的直接訪問，使用 EXECUTE 權限調用存儲過程，無需擁有訪問底層數據庫對象的顯式權限。

7.jdbc調用存儲過程
加載驅動
獲取鏈接
設置參數
執行
釋放鏈接

8.簡單說一下你對jdbc的理解
9.寫一個jdbc的訪問oracle的列子
10.jdbc中preparedStatement比Statement的好處

11.數據庫鏈接池的做用
一、限定數據庫的個數，不會致使因爲數據庫鏈接過多致使系統運行緩慢或崩潰
二、數據庫鏈接不須要每次都去建立或銷燬，節約了資源
三、數據庫鏈接不須要每次都去建立，響應時間更快。

12.ORM是什麼？ORM框架是什麼？
對象關係映射（Object Relational Mapping，簡稱ORM）模式是一種爲了解決面向對象與關係數據庫存在的互不匹配的現象的技術。能夠簡單的方案是採用硬編碼方式(jdbc操做sql方式)，爲每一種可能的數據庫訪問操做提供單獨的方法。這種方法存在不少缺陷，使用
使用ORM框架(爲了解決解決面向對象與關係數據庫存在的互不匹配的現象的框架)來解決.
Hibernate,ibatis(mybatis),

13.ibatis和hibernate有什麼不一樣
14.hibernate對象狀態及其轉換

15.hibernate的緩存
Hibernate中的緩存分一級緩存和二級緩存。
一級緩存就是Session級別的緩存，在事務範圍內有效是,內置的不能被卸載。二級緩存是SesionFactory級別的緩存，從應用啓動到應用結束有效。是可選的，默認沒有二級緩存，須要手動開啓。
保存數據庫後，在內存中保存一份，若是更新了數據庫就要同步更新。
什麼樣的數據適合存放到第二級緩存中？ 　　
1)不多被修改的數據 　帖子的最後回覆時間　
2)常常被查詢的數據 電商的地點
2) 不是很重要的數據，容許出現偶爾併發的數據 　　
3) 不會被併發訪問的數據 　　
4) 常量數據
擴展：hibernate的二級緩存默認是不支持分佈式緩存的。使用memcahe,redis等中央緩存來代替二級緩存。

16.數據庫優化方面的事情
定位：查找、定位慢查詢
優化手段：
a)建立索引:建立合適的索引，咱們就能夠如今索引中查詢，查詢到之後直接找對應的記錄。
b)分表：當一張表的數據比較多或者一張表的某些字段的值比較多而且不多使用時，採用水平分表和垂直分表來優化
c)讀寫分離：當一臺服務器不能知足需求時，採用讀寫分離的方式進行集羣。
d)緩存:使用redis來進行緩存

17.若是查詢和定位慢查詢
在項目自驗項目轉測試以前，在啓動mysql數據庫時開啓慢查詢，而且把執行慢的語句寫到日誌中，在運行必定時間後。經過查看日誌找到慢查詢語句。
要找出項目中的慢Sql時
一、關閉數據庫服務器(關閉服務)
二、把慢查詢記錄到日誌中
三、設置慢查詢時間
四、找出日誌中的慢查詢SQL 使用explain 慢查詢語句，來詳細分析語句的問題.

18.數據庫優化之數據庫表設計遵循範式
三範式

19.選擇合適的數據庫引擎
MyISAM存儲引擎
若是表對事務要求不高，同時是以查詢和添加爲主的，咱們考慮使用myisam存儲引擎. 好比 bbs 中的 發帖表，回覆表.
INNODB存儲引擎:
對事務要求高，保存的數據都是重要數據，咱們建議使用INNODB,好比訂單表，帳號表.
Memory 存儲
咱們數據變化頻繁，不須要入庫，同時又頻繁的查詢和修改，咱們考慮使用memory, 速度極快.
問 MyISAM 和 INNODB的區別(主要)
1. 事務安全 myisam不支持事務而innodb支持
2. 查詢和添加速度 myisam不用支持事務就不用考慮同步鎖，查找和添加和添加的速度快
3. 支持全文索引 myisam支持innodb不支持
4. 鎖機制 myisam支持表鎖而innodb支持行鎖(事務)
5. 外鍵 MyISAM 不支持外鍵， INNODB支持外鍵. (一般不設置外鍵，一般是在程序中保證數據的一致)

20.選擇合適的索引
索引（Index）是幫助DBMS高效獲取數據的數據結構。
分類：普通索引/惟一索引/主鍵索引/全文索引
普通索引:容許重複的值出現
惟一索引:除了不能有重複的記錄外，其它和普通索引同樣(用戶名、用戶身份證、email,tel)
主鍵索引：是隨着設定主鍵而建立的，也就是把某個列設爲主鍵的時候，數據庫就會給改列建立索引。這就是主鍵索引.惟一且沒有null值
全文索引:用來對錶中的文本域(char，varchar，text)進行索引， 全文索引針對MyIsam
explain select * from articles where match(title,body) against(‘database’);【會使用全文索引】

21.使用索引的一些技巧
索引弊端
1.佔用磁盤空間。
2.對dml(插入、修改、刪除)操做有影響，變慢。
使用場景：
a: 確定在where條件常用,若是不作查詢就沒有意義
b: 該字段的內容不是惟一的幾個值(sex)
c: 字段內容不是頻繁變化.

具體技巧：
1.對於建立的多列索引（複合索引），不是使用的第一部分就不會使用索引。
alter table dept add index my_ind (dname,loc); // dname 左邊的列,loc就是右邊的列
explain select * from dept where dname='aaa'\G 會使用到索引
explain select * from dept where loc='aaa'\G 就不會使用到索引
2. 對於使用like的查詢，查詢若是是’%aaa’不會使用到索引而‘aaa%’會使用到索引。
explain select * from dept where dname like '%aaa'\G不能使用索引
explain select * from dept where dname like 'aaa%'\G使用索引.
因此在like查詢時，‘關鍵字’的最前面不能使用 % 或者 _這樣的字符.，若是必定要前面有變化的值，則考慮使用 全文索引->sphinx.
3.若是條件中有or，有條件沒有使用索引,即便其中有條件帶索引也不會使用。換言之，就是要求使用的全部字段,都必須單獨使用時能使用索引.
4.若是列類型是字符串，那必定要在條件中將數據使用引號引用起來。不然不使用索引。
expain select * from dept where dname=’111’;
expain select * from dept where dname=111;（數值自動轉字符串）
expain select * from dept where dname=qqq;報錯
也就是，若是列是字符串類型，不管是否是字符串數字就必定要用 ‘’ 把它包括起來.
5.若是mysql估計使用全表掃描要比使用索引快，則不使用索引。 表裏面只有一條記錄

 

22.數據庫優化之分表
分表分爲水平(按行)分表和垂直(按列)分表

根據經驗，Mysql表數據通常達到百萬級別，查詢效率會很低，容易形成表鎖，甚至堆積不少鏈接，直接掛掉；水平分表可以很大程度較少這些壓力。
按行數據進行分表。

若是一張表中某個字段值很是多(長文本、二進制等)，並且只有在不多的狀況下會查詢。這時候就能夠把字段多個單獨放到一個表，經過外鍵關聯起來。
考試詳情，通常咱們只關注分數，不關注詳情。
水平分表策略：
1.按時間分表
這種分表方式有必定的侷限性，當數據有較強的實效性，如微博發送記錄、微信消息記錄等，這種數據不多有用戶會查詢幾個月前的數據，如就能夠按月分表。
2.按區間範圍分表
通常在有嚴格的自增id需求上，如按照user_id水平分表：
table_1 user_id從1~100w
table_2 user_id從101~200w
table_3 user_id從201~300w
3.hash分表*****
經過一個原始目標的ID或者名稱經過必定的hash算法計算出數據存儲表的表名，而後訪問相應的表。

23.數據庫的讀寫分離
主從同步
數據庫最終會把數據持久化到磁盤，若是集羣必須確保每一個數據庫服務器的數據是一直的。能改變數據庫數據的操做都往主數據庫去寫，而其餘的數據庫從主數據庫上同步數據。
讀寫分離
使用負載均衡來實現寫的操做都往主數據去，而讀的操做往從服務器去。

24.數據庫優化之緩存
在持久層(dao)和數據庫(db)之間添加一個緩存層，若是用戶訪問的數據已經緩存起來時，在用戶訪問時直接從緩存中獲取，不用訪問數據庫。而緩存是在操做內存級，訪問速度快。

做用：減小數據庫服務器壓力，減小訪問時間。

25.sql語句優化小技巧
DDL優化:
1 、經過禁用索引來提供導入數據性能 。 這個操做主要針對有數據庫的表，追加數據
//去除鍵
alter table test3 DISABLE keys;
//批量插入數據
insert into test3 select * from test;
//恢復鍵
alter table test3 ENABLE keys;
二、 關閉惟一校驗
set unique_checks=0 關閉
set unique_checks=1 開啓
三、修改事務提交方式(導入)（變屢次提交爲一次）
set autocommit=0 關閉
//批量插入
set autocommit=1 開啓

DML優化（變屢次提交爲一次）
insert into test values(1,2);
insert into test values(1,3);
insert into test values(1,4);
//合併多條爲一條
insert into test values(1,2),(1,3),(1,4)

DQL優化
Order by優化
一、多用索引排序
二、普通結果排序（非索引排序）Filesort
group by優化
是使用order by null,取消默認排序
子查詢優化
在客戶列表找到不在支付列表的客戶
#在客戶列表找到不在「支付列表」的客戶 , 查詢沒買過東西的客戶
explain
select * from customer where customer_id not in (select DISTINCT customer_id from payment); #子查詢 -- 這種是基於func外鏈

explain
select * from customer c left join payment p on(c.customer_id=p.customer_id) where p.customer_id is null -- 這種是基於「索引」外鏈
Or優化
在兩個獨立索引上使用or的性能優於
一、 or兩邊都是用索引字段作判斷，性能好！！
二、 or兩邊，有一邊不用，性能差
三、 若是employee表的name和email這兩列是一個複合索引，可是若是是 :name='A' OR email='B' 這種方式，不會用到索引！
limit優化
select film_id,description from film order by title limit 50,5;
select a.film_id,a.description from film a inner join (select film_id from film order by title limit 50,5)b on a.film_id=b.film_id

26.批量插入幾百萬條數據一、變屢次提交爲一次三、使用批量操做省出的時間可觀。像這樣的批量插入操做能不使用代碼操做就不使用，可使用存儲過程來實現。