1.如何優(yōu)化MySQL
借一個場景來講讼溺， 點贊功能愧口， 見Java面試題—拾遺
結(jié)合自己是如何設(shè)計后臺數(shù)據(jù)庫雨让， 以及優(yōu)化查詢的來講
2. 什么情況下設(shè)置了索引但無法使用
這需要從索引的原理來解釋独撇， 不同的原理， 決定了有的操作可以作桐腌， 有的不可以做
如對姓名建立索引， 姓名之間的大小按字符串大小比較苟径， 在這種排序樹中案站， 并不適合做模糊匹配操作， 如何要想加快模糊匹配的操作棘街， 可能需要其它的數(shù)據(jù)結(jié)構(gòu)蟆盐， 如該字符串大小排序的一個數(shù)組承边。
網(wǎng)上好像說可以做特定的模糊查詢， 如
B-Tree索引可以被用在像=,>,>=,<,<=和BETWEEN這些比較操作符上石挂。而且還可以用于LIKE操作符博助，只要它的查詢條件是一個不以通配符開頭的常量
至于能不能， 以及效率問題痹愚， 需要考察該操作在該數(shù)據(jù)結(jié)構(gòu)中能不能有效的執(zhí)行富岳， 如Like操作在B-Tree上的執(zhí)行。
同時里伯， 還可以提一提Hash索引城瞎，以及Hash索引不能做的操作。
Hash 索引理想情況下疾瓮， 可使得查找效率達到O(1)
Hash 索引僅僅能滿足"=","IN"和"<=>"查詢脖镀，不能使用范圍查詢。由于 Hash 索引比較的是進行 Hash 運算之后的 Hash 值狼电，所以它只能用于等值的過濾蜒灰，不能用于基于范圍的過濾，因為經(jīng)過相應(yīng)的 Hash 算法處理之后的 Hash 值的大小關(guān)系肩碟，并不能保證和Hash運算前完全一樣强窖。
B+樹索引的關(guān)鍵字檢索效率比較平均，不像B樹那樣波動幅度大削祈，在有大量重復(fù)鍵值情況下翅溺，哈希索引的效率也是極低的，因為存在所謂的哈希碰撞問題髓抑。
4. 索引的底層實現(xiàn)原理和優(yōu)化
見博客文章
5. 數(shù)據(jù)庫范式
解釋一下關(guān)系數(shù)據(jù)庫的第一第二第三范式咙崎？
因為太形式與理論化了， 只了解以下這句話就行
范式就是一張數(shù)據(jù)表的表結(jié)構(gòu)所符合的某種設(shè)計標(biāo)準(zhǔn)的級別
7. 數(shù)據(jù)庫怎么做優(yōu)化
當(dāng)問到某某怎么做優(yōu)化的問題時吨拍， 首先要知道某某執(zhí)行所涉及哪些過程褪猛， 然后才可以有條有理的去說
8. 什么是數(shù)據(jù)庫鏈接, 多客戶端可以共享一個數(shù)據(jù)庫鏈接嗎?
數(shù)據(jù)庫鏈接就是一個Socket,
鏈接池應(yīng)該在客戶端
將數(shù)據(jù)庫當(dāng)做一個應(yīng)用服務(wù)器的話, 其實就是多線程并發(fā)訪問數(shù)據(jù)庫的問題,
當(dāng)客戶端每個線程都有一個鏈接時, 對于數(shù)據(jù)庫服務(wù)端來說, 要處理多客戶端的并發(fā)訪問
當(dāng)客戶端所有線程共享一個鏈接時, 就不需要處理多客戶端的并發(fā)訪問, 因為此時只有一個Socket
但這樣， 多線程共享一個鏈接時羹饰， 要對鏈接進行加鎖操作伊滋， 否則返回的查詢結(jié)果是混亂的， 鏈接是一種資源队秩， 多個線程去爭用這種資源笑旺。
與應(yīng)用服務(wù)器不同的是, 對于應(yīng)用服務(wù)器, 客戶端我們無法控制, 而對于數(shù)據(jù)庫服務(wù)器, 客戶端就可以看作是應(yīng)用服務(wù)器, 所以可以對客戶端的數(shù)量進行控制.
使用數(shù)據(jù)庫鏈接的良好實踐是
- 使用鏈接池， 每次使用鏈接時從鏈接池取得
- always acquire and close the connection, statement and resultset in the shortest possible scope.
netty-chat中馍资， 共用了一個鏈接燥撞， 但沒有做多線程的并發(fā)控制， 所以是錯的。
Is it safe to use a static java.sql.Connection instance in a multithreaded system?
11. 一致性與原子性, 隔離性的關(guān)系
https://www.zhihu.com/question/30272728
原子一致性與并發(fā)一致性
