前言

今天發了個沸點，主題是：當年阿里面試，面試官問，sql怎么優化，掘友發起來激烈討論，我總結了下個人的觀點

1. 優化你的sql、索引

B+樹

sql優化

避免多表聯合查詢，優化難度大
設置合理的查詢字段，避免多次回表

索引

建立合適的索引
避免索引失效

規范

58到家數據庫30條軍規解讀

2. 引入緩存

優點

解決讀的性能瓶頸

缺點

緩存數據庫一致性
緩存穿透
緩存雪崩
緩存擊穿
架構復雜（高可用）

3. 讀寫分離

架構方案

客戶端直接連接客戶端直連方案，因為少了一層 proxy 轉發，所以查詢性能稍微好一點兒，并且整體架構簡單，排查問題更方便。但是這種方案，由于要了解后端部署細節，所以在出現主備切換、庫遷移等操作的時候，客戶端都會感知到，并且需要調整數據庫連接信息。中間件：ShardingSphere
帶proxy 帶 proxy 的架構，對客戶端比較友好。客戶端不需要關注后端細節，連接維護、后端信息維護等工作，都是由 proxy 完成的。但這樣的話，對后端維護團隊的要求會更高。而且，proxy 也需要有高可用架構。因此，帶 proxy 架構的整體就相對比較復雜。中間件：ShardingSphere 、Atlas 、mycat

優點

分擔主庫的壓力

缺點

從延遲，導致往主庫寫入的數據跟從庫讀出來的數據不一致

解決方案

強制走主庫方案；
sleep 方案；主庫更新后，讀從庫之前先 sleep 一下。具體的方案就是，類似于執行一條 select sleep(1) 命令。
判斷主備無延遲方案； seconds_behind_master 參數的值，可以用來衡量主備延遲時間的長短。 seconds_behind_master 是否已經等于 0。如果還不等于 0 ，那就必須等到這個參數變為 0 才能執行查詢請求。
配合 semi-sync 方案；事務提交的時候，主庫把 binlog 發給從庫；從庫收到 binlog 以后，發回給主庫一個 ack，表示收到了；主庫收到這個 ack 以后，才能給客戶端返回“事務完成”的確認。
等主庫位點方案；

Master_Log_File 和 Read_Master_Log_Pos，表示的是讀到的主庫的最新位點；
Relay_Master_Log_File 和 Exec_Master_Log_Pos，表示的是備庫執行的最新位點。如果 Master_Log_File 和 Relay_Master_Log_File、Read_Master_Log_Pos 和 Exec_Master_Log_Pos 這兩組值完全相同，就表示接收到的日志已經同步完成。

等 GTID 方案。

Auto_Position=1 ，表示這對主備關系使用了 GTID 協議。
Retrieved_Gtid_Set，是備庫收到的所有日志的 GTID 集合；
Executed_Gtid_Set，是備庫所有已經執行完成的 GTID 集合。如果這兩個集合相同，也表示備庫接收到的日志都已經同步完成。

4. 分區表

例子


CREATE TABLE `t` (
  `ftime` datetime NOT NULL,
  `c` int(11) DEFAULT NULL,
  KEY (`ftime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE (YEAR(ftime))
(PARTITION p_2017 VALUES LESS THAN (2017) ENGINE = InnoDB,
 PARTITION p_2018 VALUES LESS THAN (2018) ENGINE = InnoDB,
 PARTITION p_2019 VALUES LESS THAN (2019) ENGINE = InnoDB,
PARTITION p_others VALUES LESS THAN MAXVALUE ENGINE = InnoDB);
insert into t values('2017-4-1',1),('2018-4-1',1);

這個表包含了一個.frm 文件和 4 個.ibd 文件，每個分區對應一個.ibd 文件。對于引擎層來說，這是 4 個表；對于 Server 層來說，這是 1 個表。