一、事物的併發？事物隔離級別，每一個級別會引起什麼問題？MySQL默認是哪一個級別？
事物應該彼此徹底隔離，以免併發事物所致使的問題，然而，那樣會對性能產生極大的影響，由於事物必須按順序運行，在實際開發中，爲了提高性能，事物會以較低的隔離級別運行，事物隔離級別能夠經過隔離事物屬性指定。laravel
事物的併發問題面試
1）髒讀：事務A讀取了事務B更新的數據，而後B回滾操做，那麼A讀取到的數據是髒數據。算法
2）不可重複讀：事務A屢次讀取同一數據，事務B在事務A屢次讀取的過程當中，對數據做了更新並提交，致使事務A屢次讀取同一數據時，結果所以本事務 前後兩次讀到的數據結果會不一致。sql
3）幻讀：幻讀解決了不重複讀，保證了同一個事務裏，查詢的結果都是事務開始時的狀態（一致性）。shell
事物隔離級別數據庫
1）讀未提交：另外一個事務修改了數據，但還沒有提交，而本事務中的SELECT會讀到這些未被提交的數據髒讀。數組
2）不可重複讀：事務A屢次讀取同一數據，事務B在事務A屢次讀取的過程當中，對數據做了更新並提交，致使事務A屢次讀取同一數據時，結果所以本 事務前後兩次讀到的數據結果會不一致。緩存
3）可重複讀：在同一個事務裏，SELECT的結果是事務開始時時間點的狀態，所以，一樣的SELECT操做讀到的結果會是一致的。可是，會有幻讀現象。安全
4）串行化：最高的隔離級別，在這個隔離級別下，不會產生任何異常。併發的事務，就像事務是在一個個按照順序執行同樣。服務器
MySQL默認的事務隔離級別爲repeatable-read。
二、MySQL存儲引擎MylSAM與InnoDB的區別點有哪些？
1）InnoDB支持事務，MylSAM不支持，這一點是很是之重要。事務是一種高級 的處理方式，如在一些列増刪改中只要哪一個岀錯還能夠回滾還原，而MylSAM 就不能夠了。
2）MylSAM適合查詢以及插入爲主的應用。InnoDB適合頻繁修改以及涉殛安全性較高的應用。
3）InnoDB支持外鍵，MylSAM不支持。
4）從MySQL5.5.5之後，InnoDB是默認引擎。
5）InnoDB不支持FULLTEXT類型的索引。
6）InnoDB 中不保存表的行數，如 selectcount(*)fromtable 時，InnoDB 須要 掃描一遍整個表來計算有多少行，可是MylSAM只要簡單的讀岀保存好的行數便可。注意的是，當count(*)語句包含where條件時MylSAM也須要掃描 整個表。
7）對於自増長的字段，InnoDB中必須包含只有該字段的索引，可是在MylSAM 表中能夠和其餘字段一塊兒創建聯合索引。
8）DELETE FROM TABLE時，InnoDB不會從新創建表，而是一行一行的刪除，效率很是慢。MylSAM則會重建表。
9）InnoDB支持行鎖(某些狀況下仍是鎖整表，如update table set a=1 where user like %lee%’。
三、什麼是臨時表？臨時表何時刪除？
1）臨時表能夠手動刪除：DROP TEMPORARY TABLE IF EXISTS temp_tb;
2）臨時表只在當前鏈接可見，當關閉鏈接時，MySQL會自動刪除表並釋放全部空 間。所以在不一樣的鏈接中能夠建立同名的臨時表，而且操做屬於本鏈接的臨時表。
3）建立臨時表的語法與建立表語法相似，不一樣之處是増加關鍵字TEMPORARY, 如：
CREATE TEMPORARY TABLE tmp\_table ( NAME VARCHAR (10) NOTNULL, time date NOT NULL select \* from tmp\_table;
四、關於MySQL數據庫提供的兩種存儲引擎，MylSAM與InnoDB如何選？
1）INNODB會支持一些關係數據庫的高級功能，如事務功能和行級鎖，MylSAM不支持。
2）MylSAM的性能更優，佔用的存儲空間少，因此，選擇何種存儲引擎，視具體應用而定。
3）若是你的應用程序必定要使用事務，毫無疑問你要選擇INNODB引擎。但要注意，INNODB的行級鎖是有條件的。在where條件沒有使用主鍵時，照樣會鎖全表。好比DELETE FROM mytable這樣的刪除語句。
4）若是你的應用程序對查詢性能要求較高，就要使用MylSAM了。MylSAM索 引和數據是分開的，並且其索引是壓縮的，能夠更好地利用內存。因此它的查詢性能明顯優於INNODB。壓縮後的索引也能節約一些磁盤空間。MylSAM擁有全文索引的功能，這能夠極大地優化LIKE查詢的效率。
五、MySQL B+Tree索引和Hash索引的區別？
1）Hash索引結構的特殊性，其檢索效率很是高，索引的檢索能夠一次定位；
2）B+樹索引須要從根節點到枝節點,最後才能訪問到頁節點這樣屢次的IO訪冋;
注：BAT面試常問，爲何不用Hash索引而還要使用B+樹索引呢？
Hash索引
1）Hash索引僅僅能知足"=",「IN」和」"查詢，不能使用範圍查詢,由於通過相應 的Hash算法處理以後的Hash值的大小關係，並不能保證和Hash運算前徹底—樣；
2）Hash索引沒法被用來避免數據的排序操做，由於Hash值的大小關係並不必定和Hash運算前的鍵值徹底同樣；
3）Hash索引不能利用部分索引鍵查詢，對於組合索引，Hash索引在計算Hash 值的時候是組合索引鍵合併後再一塊兒計算Hash值，而不是單獨計算Hash 值，因此經過組合索引的前面一個或幾個索引鍵進行查詢的時候，Hash索引也沒法被利用；
4）Hash索引在任什麼時候候都不能避免表掃描，因爲不一樣索引鍵存在相同Hash 值，因此即便取知足某個Hash鍵值的數據的記錄條數，也沒法從Hash索引中直接完成查詢，仍是要回表查詢數據；
5）Hash索引遇到大量Hash值相等的狀況後性能並不必定就會比B+樹索引高。存儲Hash衝突
B+Tree索引：
1）MySQL中，只有HEAP/MEMORY引擎才顯示支持Hash索引。
2）經常使用的InnoDB引擎中默認使用的是B+樹索引，它會實時監控表上索引的使用情 況，若是認爲創建哈希索引能夠提升查詢效率，則自動在內存中的「自適應哈希索 引緩衝區」創建哈希索引(在InnoDB中默認開啓自適應哈希索引),經過觀察搜 索模式，MySQL會利用index key的前綴創建哈希索引，若是一個表幾乎大部分都 在緩衝池中，那麼創建一個哈希索引可以加快等值查詢
B+樹索引和哈希索引的明顯區別是：
1）若是是等值查詢，那麼哈希索引明顯有絕對優點，由於只須要通過一次算法 便可找到相應的鍵值；這個前提是，鍵值都是惟一的。若是鍵值不是惟一的，就須要先找到該撻所在位置，而後再根據S表日後掃描，直到找到相應 的麴居；
若是是範圍查詢檢索，這時候哈希素引就毫無用武之地了，由於原先是有序的鍵值，通過哈希算法後，有可能變成不連續的了，就沒辦法再利用索引完成 範圍查詢檢索；
2）哈希索引沒辦法利用索引完成排序，以及like，xxx%，這樣的部分模糊查詢（這種部分模糊查詢，其實本質上也是範圍查詢）；
3）哈希索引也不支持多列聯合索引的最左匹配規則；
4）B+樹索引的關鍵字檢索效率比較平均，不像B樹那樣波動幅度大，在有大量重複鍵值狀況下，哈希索引的效率也是極低的，由於存在所謂的哈希碰撞問 題。
5）在大多數場景下，都會有範圍查詢、排序、分組等查詢特徵，用B+樹索引就能夠了
六、彙集索引和非彙集索引區別？
根本區別
彙集索引和非彙集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致。
彙集索引
1）彙集索引表記錄的排列順序和索引的排列順序一致（因此查詢效率快，只要找到第一個索引值記錄，其他就連續性的記錄在物理也同樣連續存放。彙集索引對應 的缺點就是修改慢，由於爲了保證表中記錄的物理和索引順序一致，在記錄插入 的時候，會對數據頁從新排序。
2）彙集索引相似於新華字典中用拼音去查找漢字，拼音檢索表於書記順序都是按照 a~z排列的，就像相同的邏輯順序於物理順序同樣，
非彙集索引
1）非彙集索引制定了表中記錄的邏輯順序，可是記錄的物理和索引不必定一致，兩種索引都採用B+樹結構，非彙集索引的葉子層並不和實際數據頁相重疊，而採用 葉子層包含一個指向表中的記錄在數據頁中的指針方式。非彙集索引層次多，不會形成數據重排。非彙集索引相似在新華字典上經過偏旁部首來查詢漢字，檢索表也許是按照橫、 豎、撇來排列的，可是因爲正文中是a~z的拼音順序，因此就相似於邏輯地址於物理地址的不對應。
2）適用的狀況就在於分組，大數目的不一樣值，頻繁更新的列中，這些狀況即不適合彙集索引。
七、MySQL慢查尋怎麼解決？
1）slowquerylog慢查詢開啓狀態。
2）slowquerylog_file慢查詢日誌存放的位置（這個目錄須要MySQL的運行賬 號的可寫權限，_般設置爲MySQL的數據存放目錄）。
3）longquerytime查詢超過多少秒才記錄。
八、MySQL高併發環境解決方案有哪些？
1）分庫分表：水平分庫分表，由單點分佈到多點數據庫中，從而下降單點數據 庫壓力。
2）集羣方案：解決DB宕機帶來的單點DB不能訪問問題。
3）讀寫分離策略：極大限度提升了應用中Read數據的速度和併發量。沒法解決高寫入壓力。
阿里面試
九、從innodb的索引結構分析,爲何索引的key長度不能太長?
key太長會致使一個頁當中可以存放的key的數目變少，間接致使索引樹的頁數目變多，索引層次増加，從而影響總體查詢變動的效率。
十、MySQL的數據如何恢復到任意時間點?
恢復到任意時間點以定時的作全量備份，以及備份増量的binlog 日誌爲前提。恢 復到任意時間點首先將全量備份恢復以後，再此基礎上回放増加的binlog直至指定的時間點。
騰訊面試
十一、MYSQL的主從延遲怎麼解決。
1）半同步複製
從MySQL5.5開始，MySQL已經支持半同步複製了，半同步複製介於異步複製和同步複製之間，主庫在執行完事務後不馬上返回結果給客戶端，須要等待至少一個 從庫接收到並寫到relay log中才返回結果給客戶端。相對於異步複製，半同步復 制提升了數據的安全性，同時它也形成了一個TCP/IP往返耗時的延遲。
2）主庫配置syncbinlog=1 ,innodbflushlogattrxcommit=1
syncbinlog的默認值是0, MySQL不會將binlog同步到磁盤,其值表示每寫多少binlog同步一次磁盤,
innodbflushlogattzxcommit爲1表示每一次事務提交或事務外南指令都須要把日誌 flush到磁盤。
3）優化網絡。升級Slave硬件配置。升級5.7釆用並行複製
十二、某個表有近千萬數據,CRUD比較漫,如何優化？
1）能夠作表拆分，減小單表字段數量，優化表結構。
2）在保證主鍵有效的狀況下，檢查主鍵索引的字段順序，使得查詢語句中條件的 字段順序和主鍵索引的字段順序保持一致。
3）在單表的條件下，SQL語句、行索引優化等，從而提高數據的檢索速度。
1三、高併發下,如何作到安全的修改同一行數據？
1）悲觀鎖
2）FIFO （First Input First Output,先進先岀）緩存隊列思路
3）使用樂觀鎖
百度面試
1四、關係數據庫釆用的數據結構是什麼類型的數據結構？
1）數據庫的數據結構有：非線性數據結構、樹形數據結構，集合數據結構
2）數據結構釆用二維表（非線性數據結構）存儲。
3）二維表與關係
- 關係-二維表；
- 元組-二維表中的行
- 份量-二維表中的列
4）B+Tree索引–樹形數據結構 Hash索引–集合數據結構
注：四種基本的數據結構。線性數據結構（元素之間一對一的關係）結 構又細分爲，數組，鏈表，隊列，堆棧。），樹形數據結構（好比二叉樹，平衡二叉樹，B+樹），集合數據結構，圖形數據結構
1五、數據庫的索引的實現？
1）數據的索引實現爲B+Tree、hash索引結構存儲數據。
2）B+Tree是一種多路平衡查詢樹，因此他的節點是自然有序的（左子節點小於父 節點、父節點小於右子節點），因此對於範圍查詢的時候不須要作全表掃描。
3）Hash索引底層是哈希表，哈希表是一種以key-value存儲數據的結構，因此多個數據在存儲關係上是徹底沒有任何順序關係的。
以上內容但願幫助到你們， 不少PHPer在進階的時候總會遇到一些問題和瓶頸，業務代碼寫多了沒有方向感，不知道該從那裏入手去提高，對此我整理了一些資料，包括但不限於：分佈式架構、高可擴展、高性能、高併發、服務器性能調優、TP6，laravel，Redis，Swoole、Swoft、Kafka、Mysql優化、shell腳本、Docker、微服務、Nginx等多個知識點高級進階乾貨須要的能夠免費分享給你們 ，須要戳這裏 PHP進階架構師>>>實戰視頻、大廠面試文檔免費獲取