索引哪些情況會(huì)失效背率？

• 查詢條件包含or话瞧，會(huì)導(dǎo)致索引失效（or前后都有索引，且都有序會(huì)生效退渗？）移稳。
• 隱式類型轉(zhuǎn)換。會(huì)導(dǎo)致索引失效会油，例如age字段類型是int个粱，我們where age = “1”，這樣就會(huì)觸發(fā)隱式類型轉(zhuǎn)換翻翩。
• like通配符會(huì)導(dǎo)致索引失效都许。注意："ABC%“會(huì)走range索引，”%ABC"索引才會(huì)失效嫂冻。
• 聯(lián)合索引胶征，查詢時(shí)的條件列不是聯(lián)合索引中的第一個(gè)列，索引失效桨仿。
• 對索引字段進(jìn)行函數(shù)運(yùn)算睛低。
• 對索引列運(yùn)算（如，+、-钱雷、*骂铁、/），索引失效罩抗。
• 索引字段上使用（!= 或者 < >拉庵，not in）時(shí)，會(huì)導(dǎo)致索引失效套蒂。
• 索引字段上使用is null钞支， is not null，可能導(dǎo)致索引失效操刀。
• 相join的兩個(gè)表的字符編碼不同烁挟，不能命中索引，會(huì)導(dǎo)致笛卡爾積的循環(huán)計(jì)算馍刮。
• mysql估計(jì)使用全表掃描要比使用索引快,則不使用索引信夫。

索引不適合哪些場景？

• 數(shù)據(jù)量少的不適合加索引卡啰。
• 更新比較頻繁的也不適合加索引静稻。
• 離散性低的字段不適合加索引（如性別）。

MySQL 遇到過死鎖問題嗎匈辱，你是如何解決的振湾？

• 查看死鎖日志show engine innodb status;
• 找出死鎖Sql
• 分析sql加鎖情況
• 模擬死鎖案發(fā)
• 分析死鎖日志
• 分析死鎖結(jié)果

日常工作中你是怎么優(yōu)化SQL的？

• 加索引
• 避免返回不必要的數(shù)據(jù)
• 適當(dāng)分批量進(jìn)行
• 優(yōu)化sql結(jié)構(gòu)

分庫分表方案亡脸？

分表：

• 水平分表：以字段為依據(jù)押搪，按照一定策略（hash、range等）浅碾，將一個(gè)表中的數(shù)據(jù)拆分到多個(gè)表中大州。
• 垂直分表：以字段為依據(jù)，按照字段的活躍性垂谢，將表中字段拆到不同的表（主表和擴(kuò)展表）中厦画。

分庫：

• 水平分庫：以字段為依據(jù)，按照一定策略（hash滥朱、range等）根暑，將一個(gè)庫中的數(shù)據(jù)拆分到多個(gè)庫中。
• 垂直分庫：以表為依據(jù)徙邻，按照業(yè)務(wù)歸屬不同排嫌，將不同的表拆分到不同的庫中。

分庫分表可能遇到的問題缰犁？

• 事務(wù)問題：需要用分布式事務(wù)
• 跨節(jié)點(diǎn)連表查詢問題：解決這一問題可以分兩次查詢實(shí)現(xiàn)
• 跨節(jié)點(diǎn)的count,order by,group by以及聚合函數(shù)問題：分別在各個(gè)節(jié)點(diǎn)上得到結(jié)果后在應(yīng)用程序端進(jìn)行合并淳地。
• 數(shù)據(jù)遷移怖糊，容量規(guī)劃，擴(kuò)容等問題薇芝。
• ID問題：數(shù)據(jù)庫被切分后蓬抄，不能再依賴數(shù)據(jù)庫自身的主鍵生成機(jī)制，最簡單可以考慮UUID夯到。
• 跨分片的排序分頁問題

InnoDB與MyISAM的區(qū)別？

• InnoDB支持事務(wù)饮亏，MyISAM不支持事務(wù)
• InnoDB支持外鍵耍贾，MyISAM不支持外鍵
• InnoDB 支持 MVCC(多版本并發(fā)控制)，MyISAM 不支持
• select count(*) from table時(shí)路幸，MyISAM更快荐开，因?yàn)樗幸粋€(gè)變量保存了整個(gè)表的總行數(shù)，可以直接讀取简肴，InnoDB就需要全表掃描晃听。
• Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索引）
• InnoDB支持表砰识、行級(jí)鎖能扒，而MyISAM支持表級(jí)鎖。

聚集索引與非聚集索引的區(qū)別辫狼？

• 一個(gè)表中只能擁有一個(gè)聚集索引初斑，而非聚集索引一個(gè)表可以存在多個(gè)。
• 聚集索引中鍵值的邏輯順序決定了表中相應(yīng)行的物理順序膨处；非聚集索引中索引的邏輯順序與磁盤上行的物理存儲(chǔ)順序不同见秤。
• 索引是通過二叉樹的數(shù)據(jù)結(jié)構(gòu)來描述的，我們可以這么理解聚簇索引：索引的葉節(jié)點(diǎn)就是數(shù)據(jù)節(jié)點(diǎn)真椿。而非聚簇索引的葉節(jié)點(diǎn)仍然是索引節(jié)點(diǎn)鹃答，只不過有一個(gè)指針指向?qū)?yīng)的數(shù)據(jù)塊。
• 聚集索引：物理存儲(chǔ)按照索引排序突硝；非聚集索引：物理存儲(chǔ)不按照索引排序测摔；

limit 1000000 加載很慢的話，你是怎么解決的呢狞换？

方案一：如果id是連續(xù)的避咆，可以這樣，返回上次查詢的最大記錄(偏移量)修噪，再往下limit：

select id查库，name from employee where id>1000000 limit 10.
方案二：在業(yè)務(wù)允許的情況下限制頁數(shù)：
建議跟業(yè)務(wù)討論，有沒有必要查這么后的分頁黄琼。因?yàn)榻^大多數(shù)用戶都不會(huì)往后翻太多頁樊销。

方案三：order by + 索引（id為索引）

select id整慎，name from employee order by id limit 1000000，10
方案四：利用延遲關(guān)聯(lián)或者子查詢優(yōu)化超多分頁場景围苫。（先快速定位需要獲取的id段裤园，然后再關(guān)聯(lián)）：

SELECT a.* FROM employee a, (select id from employee where 條件 LIMIT 1000000,10 ) b where a.id=b.id

如何選擇合適的分布式主鍵方案呢？

• 雪花算法

• Redis生成ID

• 利用zookeeper生成唯一ID

什么是事務(wù)的隔離性剂府？

隔離性是指拧揽，多個(gè)用戶的并發(fā)事務(wù)訪問同一個(gè)數(shù)據(jù)庫時(shí)，一個(gè)用戶的事務(wù)不應(yīng)該被其他用戶的事務(wù)干擾腺占，多個(gè)并發(fā)事務(wù)之間要相互隔離淤袜。

事務(wù)的隔離級(jí)別有哪些？

• 讀未提交(Read Uncommitted)

• 讀提交(Read Committed, RC)

• 可重復(fù)讀(Repeated Read, RR)

• 串行化(Serializable)

InnoDB的四種事務(wù)的隔離級(jí)別衰伯，分別是怎么實(shí)現(xiàn)的铡羡？

InnoDB使用不同的鎖策略(Locking Strategy)來實(shí)現(xiàn)不同的隔離級(jí)別。

讀未提交(Read Uncommitted)：

• 這種事務(wù)隔離級(jí)別下意鲸，select語句不加鎖烦周。

• 此時(shí)，可能讀取到不一致的數(shù)據(jù)怎顾，即“讀臟”读慎。這是并發(fā)最高，一致性最差的隔離級(jí)別杆勇。

串行化(Serializable)：

• 這種事務(wù)的隔離級(jí)別下贪壳，所有select語句都會(huì)被隱式的轉(zhuǎn)化為select … in share mode。

• 這可能導(dǎo)致蚜退，如果有未提交的事務(wù)正在修改某些行闰靴，所有讀取這些行的select都會(huì)被阻塞住。

• 這是一致性最好的钻注，但并發(fā)性最差的隔離級(jí)別蚂且。 在大數(shù)據(jù)量，高并發(fā)量的場景下幅恋，幾乎不會(huì)使用上述兩種隔離級(jí)別杏死。

可重復(fù)讀(Repeated Read, RR)：

這是InnoDB默認(rèn)的隔離級(jí)別，在RR下：

• 普通的select使用快照讀(snapshot read)捆交，這是一種不加鎖的一致性讀(Consistent Nonlocking Read)淑翼，底層使用MVCC來實(shí)現(xiàn)；
• 加鎖的select(select … in share mode / select … for update), update, delete等語句品追，它們的鎖玄括，依賴于它們是否在唯一索引(unique index)上使用了唯一的查詢條件(unique search condition)，或者范圍查詢條件(range-type search condition)：
  • 在唯一索引上使用唯一的查詢條件肉瓦，會(huì)使用記錄鎖(record lock)遭京，而不會(huì)封鎖記錄之間的間隔胃惜，即不會(huì)使用間隙鎖(gap lock)與臨鍵鎖(next-key lock)。
  • 范圍查詢條件哪雕，會(huì)使用間隙鎖與臨鍵鎖船殉，鎖住索引記錄之間的范圍，避免范圍間插入記錄斯嚎，以避免產(chǎn)生幻影行記錄利虫，以及避免不可重復(fù)的讀

讀提交(Read Committed, RC)：

這是互聯(lián)網(wǎng)最常用的隔離級(jí)別，在RC下：

• 普通讀是快照讀堡僻；
• 加鎖的select, update, delete等語句列吼，除了在外鍵約束檢查(foreign-key constraint checking)以及重復(fù)鍵檢查(duplicate-key checking)時(shí)會(huì)封鎖區(qū)間，其他時(shí)刻都只使用記錄鎖苦始；

此時(shí)，其他事務(wù)的插入依然可以執(zhí)行慌申，就可能導(dǎo)致陌选，讀取到幻影記錄。

在高并發(fā)情況下蹄溉，如何做到安全的修改同一行數(shù)據(jù)咨油？

要安全的修改同一行數(shù)據(jù)，就要保證一個(gè)線程在修改時(shí)其它線程無法更新這行記錄柒爵。一般有悲觀鎖和樂觀鎖兩種方案：
悲觀鎖：當(dāng)前線程要進(jìn)來修改數(shù)據(jù)時(shí)役电，別的線程都得拒之門外~ 比如，可以使用select…for update
樂觀鎖：有線程過來棉胀，先放過去修改法瑟，如果看到別的線程沒修改過，就可以修改成功唁奢，如果別的線程修改過霎挟，就修改失敗或者重試。實(shí)現(xiàn)方式：樂觀鎖一般會(huì)使用版本號(hào)機(jī)制或CAS算法實(shí)現(xiàn)麻掸。

SQL優(yōu)化的一般步驟是什么酥夭，怎么看執(zhí)行計(jì)劃（explain），如何理解其中各個(gè)字段的含義脊奋？

• show status 命令了解各種 sql 的執(zhí)行頻率
• 通過慢查詢?nèi)罩径ㄎ荒切﹫?zhí)行效率較低的 sql 語句
• explain 分析低效 sql 的執(zhí)行計(jì)劃（這點(diǎn)非常重要熬北，日常開發(fā)中用它分析Sql，會(huì)大大降低Sql導(dǎo)致的線上事故）

select for update有什么含義诚隙，會(huì)鎖表還是鎖行還是其他讶隐？

• select查詢語句是不會(huì)加鎖的，但是select for update除了有查詢的作用外最楷，還會(huì)加鎖整份，而且是悲觀鎖待错。

• 至于加了是行鎖還是表鎖，這就要看是不是用了索引/主鍵烈评。 沒用索引/主鍵的話就是表鎖火俄，否則就是是行鎖。

MySQL事務(wù)得四大特性以及實(shí)現(xiàn)原理讲冠？

原子性： 事務(wù)作為一個(gè)整體被執(zhí)行瓜客，包含在其中的對數(shù)據(jù)庫的操作要么全部被執(zhí)行，要么都不執(zhí)行竿开。
一致性： 指在事務(wù)開始之前和事務(wù)結(jié)束以后谱仪，數(shù)據(jù)不會(huì)被破壞，假如A賬戶給B賬戶轉(zhuǎn)10塊錢否彩，不管成功與否疯攒，A和B的總金額是不變的。
隔離性： 多個(gè)事務(wù)并發(fā)訪問時(shí)列荔，事務(wù)之間是相互隔離的敬尺，即一個(gè)事務(wù)不影響其它事務(wù)運(yùn)行效果。
持久性： 表示事務(wù)完成以后贴浙，該事務(wù)對數(shù)據(jù)庫所作的操作更改砂吞，將持久地保存在數(shù)據(jù)庫之中。

事務(wù)ACID特性的實(shí)現(xiàn)思想崎溃？

原子性：是使用 undo log來實(shí)現(xiàn)的蜻直，如果事務(wù)執(zhí)行過程中出錯(cuò)或者用戶執(zhí)行了rollback，系統(tǒng)通過undo log日志返回事務(wù)開始的狀態(tài)袁串。
持久性：使用 redo log來實(shí)現(xiàn)概而，只要redo log日志持久化了，當(dāng)系統(tǒng)崩潰般婆，即可通過redo log把數(shù)據(jù)恢復(fù)到腥。
隔離性：通過鎖以及MVCC,使事務(wù)相互隔離開。
一致性：通過回滾蔚袍、恢復(fù)乡范，以及并發(fā)情況下的隔離性，從而實(shí)現(xiàn)一致性啤咽。

如果某個(gè)表有近千萬數(shù)據(jù)晋辆，CRUD比較慢，如何優(yōu)化宇整？

• 分庫分表瓶佳，分表（水平分表，垂直分表）
• 優(yōu)化表結(jié)構(gòu)
• 索引優(yōu)化

如何寫sql能夠有效的使用到復(fù)合索引鳞青？

• 復(fù)合索引霸饲，也叫組合索引为朋，用戶可以在多個(gè)列上建立索引,這種索引叫做復(fù)合索引。

• 當(dāng)我們創(chuàng)建一個(gè)組合索引的時(shí)候厚脉，如(k1,k2,k3)习寸，相當(dāng)于創(chuàng)建了（k1）、(k1,k2)和(k1,k2,k3)三個(gè)索引傻工，這就是最左匹配原則霞溪。

• 復(fù)合索引，我們需要關(guān)注查詢Sql條件的順序中捆，確保最左匹配原則有效鸯匹，同時(shí)可以刪除不必要的冗余索引。

mysql中in 和exists的區(qū)別泄伪？

mysql優(yōu)化原則是小表驅(qū)動(dòng)大表殴蓬，小的數(shù)據(jù)集驅(qū)動(dòng)大的數(shù)據(jù)集，從而讓性能更優(yōu)蟋滴。主表數(shù)據(jù)量大適合用in科雳，關(guān)聯(lián)表數(shù)據(jù)量大適合用exists。

數(shù)據(jù)庫自增主鍵可能遇到什么問題脓杉？

使用自增主鍵對數(shù)據(jù)庫做分庫分表，可能出現(xiàn)諸如主鍵重復(fù)等的問題简逮。解決方案的話球散，簡單點(diǎn)的話可以考慮使用UUID， 自增主鍵會(huì)產(chǎn)生表鎖散庶，從而引發(fā)問題 自增主鍵可能用完問題蕉堰。

說一下大表查詢的優(yōu)化方案？

• 優(yōu)化shema悲龟、sql語句+索引

• 可以考慮加緩存

• 主從復(fù)制屋讶，讀寫分離

• 分庫分表

InnoDB引擎中的索引策略？

當(dāng)索引幫助存儲(chǔ)引擎快速查找到記錄帶來的好處大于其帶來的額外工作時(shí)须教，索引才是有效的皿渗。對于非常小的表，大部分情況下簡單的全表掃描更高效轻腺，對于中到大型的表乐疆，索引就非常有效。

如何爭取的創(chuàng)建和使用縮影贬养？

• 索引列不能是表達(dá)式的一部分挤土，也不是函數(shù)的參數(shù)。
• 長字符串只索引左邊開始的部分字符误算。
• 選擇合適的索引的選擇性：select count(distinct left(city,6))/count(*) from skill.city_demo
• 盡量使用聯(lián)合索引

前綴索引缺點(diǎn)仰美？

MySQL無法使用前綴索引做ORDER BY和GROUP BY迷殿，也無法使用前綴索引做覆蓋掃描。

聯(lián)合索引列選擇原則咖杂？

• 經(jīng)常用的列優(yōu)先【最左匹配原則】
• 選擇性（離散性）高的優(yōu)先【離散度高原則】
• 寬度小的列優(yōu)先【最少空間原則】
• 選擇合適的索引列順序

一條sql執(zhí)行過長的時(shí)間庆寺，你如何優(yōu)化，從哪些方面入手翰苫？

• 查看是否涉及多表和子查詢止邮，優(yōu)化Sql結(jié)構(gòu)，如去除冗余字段奏窑，是否可拆表等
• 優(yōu)化索引結(jié)構(gòu)导披，看是否可以適當(dāng)添加索引
• 數(shù)量大的表，可以考慮進(jìn)行分離/分表（如交易流水表）
• 數(shù)據(jù)庫主從分離埃唯，讀寫分離
• explain分析sql語句撩匕，查看執(zhí)行計(jì)劃，優(yōu)化sql
• 查看mysql執(zhí)行日志墨叛，分析是否有其他方面的問題

Blob和text有什么區(qū)別止毕？

Blob用于存儲(chǔ)二進(jìn)制數(shù)據(jù)，而Text用于存儲(chǔ)大字符串漠趁。
Blob值被視為二進(jìn)制字符串（字節(jié)字符串）,它們沒有字符集扁凛，并且排序和比較基于列值中的字節(jié)的數(shù)值。
text值被視為非二進(jìn)制字符串（字符字符串）闯传。它們有一個(gè)字符集谨朝，并根據(jù)字符集的排序規(guī)則對值進(jìn)行排序和比較。

MySQL里記錄貨幣用什么字段類型比較好甥绿？

貨幣在數(shù)據(jù)庫中MySQL常用Decimal和Numric類型表示字币，這兩種類型被MySQL實(shí)現(xiàn)為同樣的類型。他們被用于保存與金錢有關(guān)的數(shù)據(jù)共缕。
DECIMAL和NUMERIC值作為字符串存儲(chǔ)洗出，而不是作為二進(jìn)制浮點(diǎn)數(shù)，以便保存那些值的小數(shù)精度图谷。

如何使用普通鎖保證一致性翩活？

• 操作數(shù)據(jù)前加鎖，實(shí)施互斥便贵，不允許其他的并發(fā)任務(wù)操作隅茎。

• 操作完成后釋放鎖，讓其他任務(wù)執(zhí)行嫉沽，來保證一致性辟犀。

普通鎖存在什么問題？

簡單的鎖住太過粗暴，連“讀任務(wù)”也無法并行堂竟，任務(wù)執(zhí)行過程本質(zhì)上是串行的魂毁。

InnoDB有哪幾種鎖？

• 共享/排它鎖(Shared and Exclusive Locks)：

  • 共享鎖（Share Locks出嘹，記為S鎖）席楚，讀取數(shù)據(jù)時(shí)加S鎖
  • 排他鎖（eXclusive Locks，記為X鎖）税稼，修改數(shù)據(jù)時(shí)加X鎖

  共享鎖之間不互斥烦秩，讀讀可以并行。

  排他鎖與任何鎖互斥郎仆，寫讀只祠，寫寫都不可以并行。

  共享鎖和排它鎖存在讀寫互斥扰肌，對并發(fā)度有較大的影響抛寝。

• 意向鎖(Intention Locks)：

  • 意向鎖，是一個(gè)表級(jí)別的鎖(table-level locking)曙旭。
  • 意向鎖分為：
    • 意向共享鎖(intention shared lock, IS)盗舰，它預(yù)示著，事務(wù)有意向?qū)Ρ碇械哪承┬屑庸蚕鞸鎖
    • 意向排它鎖(intention exclusive lock, IX)桂躏，它預(yù)示著钻趋，事務(wù)有意向?qū)Ρ碇械哪承┬屑优潘黊鎖
    • select … lock in share mode，要設(shè)置IS鎖剂习；select … for update爷绘，要設(shè)置IX鎖；
  • 意向鎖協(xié)議(intention locking protocol)：
    • 事務(wù)要獲得某些行的S鎖进倍，必須先獲得表的IS鎖
    • 事務(wù)要獲得某些行的X鎖，必須先獲得表的IX鎖
  • 由于意向鎖僅僅表明意向购对，它是比較弱的鎖猾昆，意向鎖之間并不相互互斥，其兼容互斥表如下：

  	IS	IX
  IS	兼容	兼容
  IX	兼容	兼容

  • 意向鎖會(huì)與共享鎖/排它鎖互斥骡苞，其兼容互斥表如下：

  	S	X
  IS	兼容	互斥
  IX	互斥	互斥

  InnoDB支持多粒度鎖(multiple granularity locking)垂蜗，它允許行級(jí)鎖與表級(jí)鎖共存，實(shí)際應(yīng)用中解幽，InnoDB使用的是意向鎖贴见。

意向鎖是指，未來的某個(gè)時(shí)刻躲株，事務(wù)可能要加共享/排它鎖了片部，先提前聲明一個(gè)意向。

意向鎖解決什么問題霜定？

如果事務(wù) A 獲取了某一行的排它鎖档悠，事務(wù) B 想要獲取表的鎖（共享或者排他鎖）廊鸥。因?yàn)楣蚕礞i與排它鎖互斥，所以事務(wù) B 在試圖對表鎖的時(shí)候辖所，必須保證：

• 當(dāng)前沒有其他事務(wù)持有表的排它鎖惰说。
• 當(dāng)前沒有其他事務(wù)持有表中任意一行的排它鎖 。

為了檢測是否滿足第二個(gè)條件缘回，事務(wù) B 必須去檢測表中的每一行是否存在排它鎖吆视。這是一個(gè)效率很差的做法，但是有了意向鎖之后酥宴，事務(wù)A持有了表的意向排它鎖啦吧，就可得知事務(wù)A必然持有該表中某些數(shù)據(jù)行的排它鎖，而無需去檢測表中每一行是否存在排它鎖幅虑。

Hash索引和B+樹區(qū)別是什么丰滑？你在設(shè)計(jì)索引是怎么抉擇的？

B+樹可以進(jìn)行范圍查詢倒庵，Hash索引不能褒墨。
B+樹支持聯(lián)合索引的最左側(cè)原則，Hash索引不支持擎宝。
B+樹支持order by排序郁妈，Hash索引不支持。
Hash索引在等值查詢上比B+樹效率更高绍申。
B+樹使用like 進(jìn)行模糊查詢的時(shí)候噩咪，like后面（比如%開頭）的話可以起到優(yōu)化的作用，Hash索引根本無法進(jìn)行模糊查詢极阅。

mysql 的內(nèi)連接胃碾、左連接、右連接有什么區(qū)別筋搏？

Inner join 內(nèi)連接仆百，在兩張表進(jìn)行連接查詢時(shí)，只保留兩張表中完全匹配的結(jié)果集奔脐。
left join 在兩張表進(jìn)行連接查詢時(shí)俄周，會(huì)返回左表所有的行，即使在右表中沒有匹配的記錄髓迎。
right join 在兩張表進(jìn)行連接查詢時(shí)峦朗，會(huì)返回右表所有的行，即使在左表中沒有匹配的記錄排龄。

什么是內(nèi)連接波势、外連接、交叉連接、笛卡爾積呢艰亮？

內(nèi)連接（inner join）：取得兩張表中滿足存在連接匹配關(guān)系的記錄闭翩。
外連接（outer join）：取得兩張表中滿足存在連接匹配關(guān)系的記錄，以及某張表（或兩張表）中不滿足匹配關(guān)系的記錄迄埃。
交叉連接（cross join）：顯示兩張表所有記錄一一對應(yīng)疗韵，沒有匹配關(guān)系進(jìn)行篩選，也被稱為：笛卡爾積侄非。

主從復(fù)制binlog格式有哪幾種蕉汪？有什么區(qū)別？

• STATEMENT：基于語句的日志記錄逞怨，把所有寫操作的sql語句寫入 binlog （默認(rèn)）

  • 優(yōu)點(diǎn)：
    成熟的技術(shù)者疤。
    更少的數(shù)據(jù)寫入日志文件。當(dāng)更新或刪除影響許多行時(shí)叠赦，這將導(dǎo)致日志文件所需的存儲(chǔ)空間大大減少驹马。這也意味著從備份中獲取和還原可以更快地完成。
    日志文件包含所有進(jìn)行了任何更改的語句除秀，因此它們可用于審核數(shù)據(jù)庫糯累。
  • 缺點(diǎn)：
    有很多函數(shù)不能復(fù)制，例如now()册踩、random()泳姐、uuid()等

• ROW：基于行的日志記錄，把每一行的改變寫入binlog暂吉，假設(shè)一條sql語句影響100萬行胖秒，從節(jié)點(diǎn)需要執(zhí)行100萬次，效率低慕的。

  • 優(yōu)點(diǎn)：可以復(fù)制所有更改阎肝，這是最安全的復(fù)制形式
  • 缺點(diǎn)：如果該SQL語句更改了許多行，則基于行的復(fù)制可能會(huì)向二進(jìn)制日志中寫入更多的數(shù)據(jù)肮街。即使對于回滾的語句也是如此风题。這也意味著制作和還原備份可能需要更多時(shí)間。此外低散，二進(jìn)制日志被鎖定更長的時(shí)間以寫入數(shù)據(jù)，這可能會(huì)導(dǎo)致并發(fā)問題骡楼。

• MIXED：混合模式熔号，如果 sql 里有函數(shù)，自動(dòng)切換到 ROW 模式鸟整，如果 sql 里沒有會(huì)造成主從復(fù)制不一致的函數(shù)引镊，那么就使用STATEMENT模式。（存在問題：解決不了系統(tǒng)變量問題，例如@@host name弟头，主從的主機(jī)名不一致）

索引有哪些優(yōu)缺點(diǎn)吩抓？

優(yōu)點(diǎn)：

• 唯一索引可以保證數(shù)據(jù)庫表中每一行的數(shù)據(jù)的唯一性

• 索引可以加快數(shù)據(jù)查詢速度，減少查詢時(shí)間

缺點(diǎn)：

• 創(chuàng)建索引和維護(hù)索引要耗費(fèi)時(shí)間
• 索引需要占物理空間赴恨，除了數(shù)據(jù)表占用數(shù)據(jù)空間之外疹娶，每一個(gè)索引還要占用一定的物理空間
• 以表中的數(shù)據(jù)進(jìn)行增、刪伦连、改的時(shí)候雨饺，索引也要?jiǎng)討B(tài)的維護(hù)。

索引有哪幾種類型惑淳？

主鍵索引: 數(shù)據(jù)列不允許重復(fù)额港，不允許為NULL，一個(gè)表只能有一個(gè)主鍵歧焦。
唯一索引: 數(shù)據(jù)列不允許重復(fù)移斩，允許為NULL值，一個(gè)表允許多個(gè)列創(chuàng)建唯一索引绢馍。
普通索引: 基本的索引類型向瓷，沒有唯一性的限制，允許為NULL值痕貌。
全文索引：是目前搜索引擎使用的一種關(guān)鍵技術(shù)风罩，對文本的內(nèi)容進(jìn)行分詞、搜索舵稠。
覆蓋索引：查詢列要被所建的索引覆蓋超升，不必讀取數(shù)據(jù)行
組合索引：多列值組成一個(gè)索引，用于組合搜索哺徊，效率大于索引合并

創(chuàng)建索引的三種方式室琢？

在執(zhí)行CREATE TABLE時(shí)創(chuàng)建索引
使用ALTER TABLE命令添加索引
使用CREATE INDEX命令創(chuàng)建

百萬級(jí)別或以上的數(shù)據(jù)，你是如何刪除的落追？

• 我們想要?jiǎng)h除百萬數(shù)據(jù)的時(shí)候可以先刪除索引
• 然后批量刪除其中無用數(shù)據(jù)
• 刪除完成后重新創(chuàng)建索引

組合索引是什么盈滴？為什么需要注意組合索引中的順序？

組合索引轿钠，用戶可以在多個(gè)列上建立索引,這種索引叫做組合索引巢钓。 因?yàn)镮nnoDB引擎中的索引策略的最左原則，所以需要注意組合索引中的順序疗垛。

什么是死鎖症汹？怎么解決？

死鎖：

• 死鎖是指兩個(gè)或多個(gè)事務(wù)在同一資源上相互占用贷腕，并請求鎖定對方的資源背镇，從而導(dǎo)致惡性循環(huán)的現(xiàn)象咬展。

• 死鎖有四個(gè)必要條件：互斥條件，請求和保持條件瞒斩，環(huán)路等待條件破婆，不剝奪條件。

解決：

• 如果不同程序會(huì)并發(fā)存取多個(gè)表胸囱，盡量約定以相同的順序訪問表祷舀，可以大大降低死鎖機(jī)會(huì)。
• 在同一個(gè)事務(wù)中旺矾，盡可能做到一次鎖定所需要的所有資源蔑鹦，減少死鎖產(chǎn)生概率。
• 對于非常容易產(chǎn)生死鎖的業(yè)務(wù)部分箕宙，可以嘗試使用升級(jí)鎖定顆粒度嚎朽，通過表級(jí)鎖定來減少死鎖產(chǎn)生的概率。
• 如果業(yè)務(wù)處理不好可以用分布式事務(wù)鎖或者使用樂觀鎖。

MySQL鎖介紹？

從并發(fā)的角度：

• 共享鎖/排他鎖

• 意象共享鎖/意象排他鎖

從一致性鎖定讀的角度：

• 行鎖/表鎖

• 間隙鎖/臨建鎖

左前綴匹配規(guī)則拗慨？

當(dāng)使用聯(lián)合索引時(shí)，索引使用滿足左前綴規(guī)則锅很。

例子：當(dāng)對字段A、B凤跑、C創(chuàng)建聯(lián)合索引時(shí)爆安，相當(dāng)于創(chuàng)建了A索引，A仔引、B索引和A扔仓、B、C三個(gè)索引咖耘。

• 順序條件都會(huì)走索引：

  • where A = 'a'
  • where A = 'a' and B = 'b'
  • where A = 'a' and B = 'b' and C = 'c'

• 從哪兒缺失從哪兒停止走索引：

  • where A = 'a' and C = 'c' A走索引翘簇，C不走索引
  • where C = 'c' 不走索引
  • where B = 'b' and C = 'c' 不走索引

• 亂序條件會(huì)走索引：

  • where B = 'b' and A = 'a' and C = 'c' 由于優(yōu)化器優(yōu)化，依然會(huì)走A儿倒、B版保、C索引

• 模糊查詢根據(jù)條件走索引：

  • where A like 'a%' 走index或者range索引
  • where A like '%a' 不走索引
  • where A like '%a%' 不走索引
  • where A = 'a' and b like 'b%' A走索引，b走范圍或者index索引

• 范圍查詢走索引：

• where A = 'a' and B > 1 order by C A走索引夫否，b走范圍索引彻犁，C不走索引，會(huì)導(dǎo)致文件排序凰慈。此時(shí)可以優(yōu)化成 A汞幢、C索引，這樣能走A溉瓶、C索引急鳄，避免文件排序。