2020.11.07面試總結（面試12k）

作業的的原因，還有自己不努力學習（哈哈哈）盡量引導面試官問ssm的框架
文章是對我 這個星期，5天面試的總結
先說mysql

mysql：原文的地址
1.引擎
2.索引
3.隔離級別
4.鎖

1.存盤引擎
一 Innodb（mysql默認引擎）
支持事務，是事務安全的，提供行級鎖與外鍵約束，有緩沖池，用于緩沖資料和索引
適用場景：用于事務處理，具有ACID事物支持，應用于執行大量的insert和update操作的表
二 MyISAM
不支持事務，不支持外鍵約束，不支持行級鎖，操作時需要鎖定整張表，不過會保存表的行數，所以當執行select count(*) from tablename時執行特別快
適用場景：用于管理非事務表，提供高速檢索及全文檢索能力，適用于有大量的select操作的表，如 日志表
三 MEMORY
使用存在于記憶體中的內容創建表，每一個memory只實際對應一個磁盤檔案，該引擎使用hash索引，可以一次定位，不需要像B樹一樣從根節點查找到支節點，所以精確查詢時訪問速度特別快，但是非精確查找時，比如like，這種范圍查找，hash就起不到作用了，
適用場景：主要用于內容變化不頻繁的表，或者作為中間的查找表，對表的更新要謹慎因為資料沒有被寫入到磁盤中，服務關閉前要考慮好資料的存盤
四 MERGE
MERGE存盤引擎把一組MyISAM資料表當做一個邏輯單元來對待，讓我們可以同時對他們進行查詢，構成一個MERGE資料表結構的各成員MyISAM資料表必須具有完全一樣的結構，每一個成員資料表的資料列必須按照同樣的順序定義同樣的名字和型別，索引也必須按照同樣的順序和同樣的方式定義，

二、索引種類
普通索引：僅加速查詢
唯一索引：加速查詢 + 列值唯一（可以有null）
主鍵索引：加速查詢 + 列值唯一（不可以有null）+ 表中只有一個
組合索引：多列值組成一個索引，專門用于組合搜索，其效率大于索引合并
創建索引的時機：
MySQL只對<，<=，=，>，>=，BETWEEN，IN，以及某些時候的LIKE才會使用索引
索引不生效的情況:
1、使用like關鍵字模糊查詢時，第一個位置是任意字符
3、OR前后的兩個條件中的列都是索引時，索引才會生效，
4、盡量避免在where子句中使用!=或<>運算子，否則全表掃描，
5、在 where 子句中對欄位進行運算式 , 函式操作，否則全表掃描，
6、order by 索引 ，不起作用的問題（除了主鍵索引之外）：
　　1、 如果select 只查詢索引欄位，order by 索引欄位會用到索引，要不然就是全表排列；
　　 2、如果有where 條件，比如where vtype=1 order by vtype asc . 這樣order by 也會用到索引！
組合索引？在哪些場景中，組合索引會失效:
1、組合索引欄位無論順序如何改變都會用到索引，前提是所有欄位都在where條件上
2、如果想要使用一個或者兩個欄位在where條件上，必須有組合索引里的第一個欄位，但是與順序無關，例如a,c或c,a，這種場景是可以命中索引的，但是，b,c或c,b這種是不會命中索引的，，
3、order by 只能使用a，才能用到索引
mysql的優化方法：
創建表考慮的問題：
1、選擇最合適的欄位屬性
2、盡量把欄位設定為NOT NULL
3 使用連接(JOIN)來代替子查詢
4.連接查詢推薦：inner join（內連接）
5.創建合適的索引

優化SQL的查詢陳述句
1 不使用子查詢
2 避免函式索引
3 用IN來替換OR
4 LIKE第一個位置是任意字符無法使用到索引
6 避免資料型別不一致
7 分組統計可以禁止排序
8 禁止不必要的ORDER BY排序
9 批量INSERT插入

為什么子查詢比連接查詢（LEFT JOIN）效率低：
執行子查詢時，MYSQL需要創建臨時表，查詢完畢后再洗掉這些臨時表，所以，子查詢的速度會受到一定的影響，這里多了一個創建和銷毀臨時表的程序

事務：
原子性：一個事物(transaction)中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節，事務在執行程序中發生錯誤，會被回滾(Rollback)到事務開始的狀態，就像這個事務從來沒有執行過一樣，
一致性：在事務開始之前和事務結束之后，資料庫的完整性沒有被破壞，這表示寫入的資料必須完全符合所有的預設規則，這包含資料的精確度、串聯性以及后續資料庫可以自發性地完成預定的作業，
隔離性：資料庫允許多個事務同時對其資料進行讀寫和修改的能力，隔離性可以防止多個事務并發執行時由于交叉執行而導致資料的不一致，事務隔離分為不同的級別，包括讀未提交(Read uncommitted)、讀已提交(Read committed)、可重復讀(repeateable read)和串行化(Serializable).
持久性：事務處理結束后，對資料的修改就是永久的，即便系統故障也不會丟失，

事務隔離級別
讀未提交
讀已提交
可重復讀
串行化
產生的問題：
1、臟讀：事務A讀取了事務B更新的資料，然后B回滾操作，那么A讀取到的資料就是臟資料
2、不可重復讀：事務A多次讀取同一事物，事務B在事務A多次讀取的程序中，對資料做了更新并提交，導致事務A多次讀取同一資料時，結果不一致，
3、幻讀：系統管理員A將資料庫中的所有學生的成績從具體分數改為ABCDE等級，但是系統管理員B就在這個時候插入了一條具體分數的記錄，當系統管理員A改結束后發現還有一條記錄沒有改過來，就好像發生了幻覺一樣，這就叫幻讀，

鎖

InnoDB的行鎖是針對索引加的鎖，不是針對記錄加的鎖，并且該索引不能失效，否則都會從行鎖升級為表鎖

行鎖
行鎖的劣勢：開銷大；加鎖慢；會出現死鎖
行鎖的優勢：鎖的粒度小，發生鎖沖突的概率低；處理并發的能力強
加鎖的方式：自動加鎖，對于UPDATE、DELETE和INSERT陳述句，InnoDB會自動給涉及資料集加排他鎖；對于普通SELECT陳述句，InnoDB不會加任何鎖；當然我們也可以顯示的加鎖：
共享鎖：select * from tableName where … + lock in share more
排他鎖：select * from tableName where … + for update
排他鎖
排他鎖，也稱寫鎖，獨占鎖，當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖，
共享鎖
共享鎖，也稱讀鎖，多用于判斷資料是否存在，多個讀操作可以同時進行而不會互相影響，當如果事務對讀鎖進行修改操作，很可能會造成死鎖，

分析行鎖定

通過檢查InnoDB_row_lock 狀態變數分析系統上的行鎖的爭奪情況
innodb_row_lock_current_waits: 當前正在等待鎖定的數量
innodb_row_lock_time: 從系統啟動到現在鎖定總時間長度；非常重要的引數，
innodb_row_lock_time_avg: 每次等待所花平均時間；非常重要的引數，
innodb_row_lock_time_max: 從系統啟動到現在等待最常的一次所花的時間；
innodb_row_lock_waits: 系統啟動后到現在總共等待的次數；非常重要的引數，直接決定優化的方向和策略
行鎖優化
1 盡可能讓所有資料檢索都通過索引來完成，避免無索引行或索引失效導致行鎖升級為表鎖，
2 盡可能避免間隙鎖帶來的性能下降，減少或使用合理的檢索范圍，
3 盡可能減少事務的粒度，比如控制事務大小，而從減少鎖定資源量和時間長度，從而減少鎖的競爭等，提供性能，
4 盡可能低級別事務隔離，隔離級別越高，并發的處理能力越低，

表鎖
表鎖的優勢：開銷小；加鎖快；無死鎖
表鎖的劣勢：鎖粒度大，發生鎖沖突的概率高，并發處理能力低
加鎖的方式：自動加鎖，查詢操作（SELECT），會自動給涉及的所有表加讀鎖，更新操作（UPDATE、DELETE、INSERT），會自動給涉及的表加寫鎖，也可以顯示加鎖：
共享讀鎖：lock table tableName read;
獨占寫鎖：lock table tableName write;
批量解鎖：unlock tables;

共享讀鎖
對MyISAM表的讀操作（加讀鎖），不會阻塞其他行程對同一表的讀操作，但會阻塞對同一表的寫操作，只有當讀鎖釋放后，才能執行其他行程的寫操作，在鎖釋放前不能取其他表，

獨占寫鎖
對MyISAM表的寫操作（加寫鎖），會阻塞其他行程對同一表的讀和寫操作，只有當寫鎖釋放后，才會執行其他行程的讀寫操作，在鎖釋放前不能寫其他表，

什么場景下用表鎖
InnoDB默認采用行鎖，在未使用索引欄位查詢時升級為表鎖，
第一種情況：全表更新，
第二種情況：多表查詢，
總結
1 InnoDB 支持表鎖和行鎖，使用索引作為檢索條件修改資料時采用行鎖，否則采用表鎖，
2 InnoDB 自動給修改操作加鎖，給查詢操作不自動加鎖
3 行鎖可能因為未使用索引而升級為表鎖，所以除了檢查索引是否創建的同時，也需要通過explain執行計劃查詢索引是否被實際使用，
4 行鎖相對于表鎖來說，優勢在于高并發場景下表現更突出，畢竟鎖的粒度小，
5 當表的大部分資料需要被修改，或者是多表復雜關聯查詢時，建議使用表鎖優于行鎖，
6 為了保證資料的一致完整性，任何一個資料庫都存在鎖定機制，鎖定機制的優劣直接影響到一個資料庫的并發處理能力和性能，