1. 表結構
存儲引擎
MyIsam: 應用時以讀和插入操作爲主，只有少量的更新和刪除，並且對事務的完整性，併發性要求不是很高的。（適合做只讀表，如統計表等）
InnoDB: 事務處理，以及併發條件下要求數據的一致性。（適合批量操作與經常修改）
字段類型
- 選用合適的字段類型，選用最小的長度減少存儲空間，儘量使用int型；
- 儘可能的使用 varchar/nvarchar 代替 char/nchar，因爲首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些；
- 不要使用null作爲默認值，將導致全表掃描，使用其他（0，-1）代替；
2. 索引
索引就是爲特定的mysql字段進行一些特定的算法排序，比如二叉樹的算法和哈希算法，哈希算法是通過建立特徵值，然後根據特徵值來快速查找。而用的最多，並且是mysql默認的就是二叉樹算法 BTREE，通過BTREE算法建立索引的字段，比如掃描20行就能得到未使用BTREE前掃描了2^20行的結果。
實際上，索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄。
（https://www.cnblogs.com/shijingxiang/articles/4743324.html）
聚簇索引、非聚簇索引（二級索引）
https://www.cnblogs.com/crazylqy/p/7615393.html
https://blog.csdn.net/u013132035/article/details/82193763
https://blog.csdn.net/GitChat/article/details/78787837
http://www.imooc.com/article/267890
- 主鍵索引，外鍵索引；
- 在where條件中經常使用查詢的列加索引（根據實際場景分析）；
- 使用複合索引（確定是多個列同時查詢才使用）；
- 創建索引要選擇維度高（不重複值出現的個數大）的列；
優點：加快查詢速度
缺點：索引會降低寫的速度（因爲要動態維護索引），隨着數據量的增加，索引文件也會越來越大
3. 查詢優化
- 開啓查詢緩存
緩存條件：查詢緩存可以看做是SQL文本和查詢結果的映射。如果第二次查詢的SQL和第一次查詢的SQL完全相同（注意必須是完全相同，即使多一個空格或者大小寫不同都認爲不同）且開啓了查詢緩存，那麼第二次查詢就直接從查詢緩存中取結果；
緩存失效機制：在表的結構或數據發生改變時，查詢緩存中的數據不再有效。
- 開啓慢查詢日誌，定期檢查SQL語句；
- 使用Explain分心SQL語句的性能；https://www.runoob.com/w3cnote/mysql-index.html
SQL語句優化
- 避免使用 select *，要什麼查什麼；
- 避免使用 <>，MySQL只對以下操作符使用索引：<，<=，=，>，>=，BETWEEN，IN；
- 避免使用 or，將導致全表掃描，可以使用 union 代替；
- in和not in在某些情況也會導致全表掃描；（一般情況下，當你IN中的條件太多，或是無法估計時，優化器傾向於全表掃描。當IN的條件少時，如果優化器認爲，INDEX SEEK可以帶來好處時，照樣會走索引的。）
- 避免對字段進行函數操作，導致全表掃描；
- 多個表連接查詢（join）的時候請使用別名，可以減少解析的時間並減少那些由Column歧義引起的語法錯誤；
4. 主從配置、讀寫分離
在實際的生產環境中，由單臺Mysql作爲獨立的數據庫是完全不能滿足實際需求的，無論是在安全性，高可用性以及高併發等各個方面。因此，一般來說都是通過 主從複製（Master-Slave）的方式來同步數據，再通過讀寫分離（MySQL-Proxy）來提升數據庫的併發負載能力 這樣的方案來進行部署與實施的。
主從複製原理：
主庫(Master)開啓二進制日誌(binlog，記錄所有數據庫操作的日誌)；主庫授權一個賬號給從庫(Slave)，從庫作爲主庫的一個客戶端訪問主庫的二進制日誌，記錄到自己的中繼日誌（Relay Log）中；從庫的SQL線程會檢測自己的中繼日誌，並執行；
具體執行過程：
（1）在Slave服務器上執行start slave命令開啓主從複製開關，開始進行主從複製。
（2）此時，Slave服務器的IO線程會通過在master上已經授權的複製用戶權限請求連接Master服務器，並請求從執行binlog日誌文件中的指定位置（日誌文件名和位置就是在配置主從複製服務時執行change master命令指定的）之後開始發送binlog日誌內容。
（3）Master服務器接收來自Slave服務器的IO線程的請求後，其上負責複製的IO線程會根據Slave服務器的IO線程請求的信息分批讀取指定binlog日誌文件指定位置之後的binlog日誌信息，然後返回給Slave端的IO線程。
（4）當Slave服務器的IO線程獲取到Master服務器上IO線程發送的日誌內容、日誌文件及位置點後，會將binlog日誌內容依次寫到Slave端自身的Relay Log（即中繼日誌）文件（Mysql-relay-bin.xxx）的最末端，並將新的binlog文件名和位置記錄到master-info文件中，以便下一次讀取master端新binlog日誌時能告訴Master服務器從新binlog日誌的指定文件及位置開始讀取新的binlog日誌內容
（5）Slave服務器端的SQL線程會實時檢測本地Relay Log 中IO線程新增的日誌內容，然後及時把Relay LOG 文件中的內容解析成sql語句，並在自身Slave服務器上按解析SQL語句的位置順序執行應用這樣sql語句，並在relay-log.info中記錄當前應用中繼日誌的文件名和位置點
讀寫分離（主寫從讀）
從服務器只負責讀，主服務器負責寫操作、
實現方式：
1. 程序上判斷（開發者自己寫）
2. 使用中間件，MySQL- Proxy是實現"讀寫分離(Read/Write Splitting)"的一個軟件。基本的原理是讓主數據庫處理寫操作（insert、update、delete），而從數據庫處理查詢操作（select）。而數據庫的一致性則通過主從複製來實現。所以說主從複製是讀寫分離的基礎。
5、分庫、分區、分表
https://blog.csdn.net/u011665991/article/details/90038768
分區：https://blog.csdn.net/vbirdbest/article/details/82461109
分區原理：
分區表是由多個相關的底層表實現，這些底層表也是由句柄對象表示，所以我們也可以直接訪問各個分區，存儲引擎管理分區和一個普通表沒有任何不同，存儲引擎也無須知道這是一個普通表是分區表的一部分。
在分區表上的操作是按照下面的操作邏輯進行：
- select 查詢：分區層先打開並鎖住所有的底層表，優化器判斷是否可以過濾部分分區，然後再調 用對應的存儲接口訪問各個分區。
- insert操作：分區層打開並鎖住所有底層表，然後確定那個分區接受這條記錄，再將這條記錄寫入對應的底層表 。
- delete操作：分區層先打開並鎖住所有底層表，mysql先確定對象分區，最後對相應的底層表進行刪除操作。
- update操作：分區層先打開並鎖住所有的底層表，mysql先確定更新的記錄再哪個分區，然後取出數據並更新，在判斷更新後的數據應該放在哪個分區，然後對底層表進行寫入操作，並對原數據的底層表進行刪除操作。
轉自：https://blog.csdn.net/ruan_learning/article/details/79668871