1 對數據庫性能產生影響的幾個方面
1.1 硬件
1.2 服務器的操作系統
1.3 數據庫存儲引擎的選擇
1.4 數據庫配置參數
1.5 數據庫的設計和sql語句
1.1 硬件 CPU資源和可用內存大小
mysql 體系結構
MyISAM 5.5.8 之前默認的存儲引擎
有myd和myi組成，前者存儲數據，後者存儲索引信息
還有所有存儲引擎都有的frm 存儲表結構
特性：
1 併發性和鎖級別 用的是表級鎖，所以對於讀寫混合操作的話支持不是很好
2 表損壞修復 check table tablename
repaire table tablename
3 支持的索引類型
全文索引
4 支持數據壓縮 命令：myisampack 壓縮之後只能讀取，不能寫入和修改
限制：
1 mysql5.0之前單表大小爲4G，現在默認爲支持256T
使用場景：
1 非事務性應用，即不支持事物。事物是關係型數據庫和非關係型數據庫的一大區別，但很明顯這裏不能這麼說，因爲 這只是一個存儲引擎而已
2 只讀類應用（因爲支持壓縮），性能不錯
3 空間類應用
Innodb
mysql5.5.8之後，成爲默認的存儲引擎
使用表空間進行數據存儲，通過參數innodb_file_per_talbe的on off值來選擇不同的存儲方式，當值爲on時，使用獨立表空間tablename.idb來存儲，當爲off時，使用系統表空間ibdatax來存儲。那應該如何選擇呢？
mysql 5.7之後也開始支持全文索引和空間，
mysql 服務器參數
內存配置相關參數
確定爲操作系統保留多少內存
如何爲緩存池分配內存 innodb_buffer_pool_size
安全相關配置
expire_logs_days 指定自動清理binlog的天數
*基準測試*
什麼是基準測試？
如何進行基準測試
1.1 從系統入口進行測試（如web前臺入口，app入口等）。有點：能測試整個系統的性能，包括服務器、緩存、數據庫的性能
1.2 單獨對某一個組件（如mysql）進行測試
mysql性能基準測試常用的性能指標
1.1 TPS 單位時間內所處理的事物數
1.2 QPS 單位時間內所處理的查詢數
1.3 響應時間
1.4 併發量：同時處理的查詢請求的數量
基準測試的步驟
1.1 計劃和設計基準測試
1.1.1 是對整個系統還是對某一組件
1.1.2 使用什麼樣的數據
編寫測試腳本，收集mysql運行時的各種信息，如cpu使用率，連接數，innodb狀態等等
1.1.3 完成測試，收集和保存測試結果
基準測試時需要注意的問題
1.1 使用數據的問題，是否使用真實的生產環境數據
1.2 多用戶場景中，只模擬單用戶的測試。應該模擬多線程的併發測試
1.3 反覆執行同一條查詢，容易緩存命中，無法真實反映真實查詢性能
如果是想對整個系統進行測試，可以使用apache的ab httpload等進行測試
基準測試工具之
1.1 mysqlslap mysql5.1之後，自帶的測試工具
特點：
1.2 sysbench
第4章 MySQL數據庫結構優化
首先要明確，進行數據庫結構優化要達到的目的
4.1.1 減少數據冗餘
什麼是冗餘呢？舉個例子：一個列的數據是可以通過其他列的計算得出或者已經存在。這裏我們可能不需要再次存儲這些數據，當然必要的冗餘有好處，這裏說的是減少，而不是全部去除
4.1.2 儘量避免數據維護中出現插入、修改、刪除異常（這裏的異常不是說插入的時候不能插入的問題，是指比如修改了一條數據對邏輯產生影響這類問題）
4.1.3 節約數據庫的存儲空間
4.2 mysql 結構設計
4.2.1 設計步驟
1 瞭解需求 ：存儲需求、數據處理需求、數據的安全性和完整性
2 邏輯分析
4.3 數據庫設計範式 ———–》 數據庫設計過程中遵守的規範要求——三範式
4.3.1 第一範式，基本所有數據庫表都符合第一範式，看到這句話我基本就知道，第一範式沒什麼屁用了。都是些只要設計表就自動不自動會遵循的一些規則，真的是沒有什麼實際意義
數據庫表中的所有字段都只有單一的屬性，且必須爲單一的字段等等，不贅述
4.3.2 基本也用不到啊親，這都算他們什麼規則
4.3.3
4.4 需求分析及邏輯設計
實際業務需求分析（1）本網站只銷售圖書類商品（2）需要具有以下功能：用戶登錄 用戶管理 商品展示 商品管理 供應商管理 在線銷售
邏輯分析：用戶登錄及用戶管理功能
用戶必須註冊並登錄才能進行網上交易
同一時間同一用戶只能在一個地方登錄
用戶信息{用戶名 手機號 密碼等等}
4.5 選擇合適的數據類型
選擇原則：當一個字段可以選擇多種數據類型時首先應該選擇數字類型，其次是日期或二進制類型，最後是字符類型。對於級別小的數據類型應該優先選擇空間佔用小的類型
整型比較容易理解，這裏着重講一下帶小數點的float double和decimal 。float和double都不是精確的類型，decimal是精確的。
類型名稱 佔用空間
float 4個字節
double 8個字節
decimal 佔用空間根據長度而定。此外，float和double之間的區別是前者佔用7個精度，而double佔用16個，而且double比float要慢很多，不建議使用。float和double如果存儲的值超過了設置的值會進行四捨五入存儲，這就不是我們想看到的了，所以原則是儘量考慮到我們可能存儲的值宜選用合適的類型或者等到真的選擇了四捨五入的時候的後果是我們完全能夠承受的，那你選擇這種類型也是沒問題的。
varchar用於存儲變長字符串，varchar(num)中num指的是字符，不是字節。舉例來說在utf8下一個漢字佔用3個字節（包括繁體字）。當我們設置varchar(255)的時候，可以存儲包括漢字、英文字母在內的255個字符而不是隻能存儲80多個漢字。當然，相應的varchar(255)存儲255個漢字和255個英文字母，佔用的空間肯定是不一樣的了。要差到510個字節。
這裏在舉個例子吧：如果我們用varchar存儲性別（實際上我們不會這樣的），男/女，varchar(1)和char(1)分別會佔用多個字節呢？首先，utf8下一個漢字佔用三個字節這是通用的，然後，在長度小於255的時候，varchar會在佔用一個字節來存儲字段的長度。所以，這時，varchar會佔用4個字節，char佔用三個字節。
5 mysql複製功能
5.1 二進制日誌
二進制日誌文件中記錄了所有對mysql的修改事件，包括增刪改查和對錶結構的修改事件。這裏只記錄成功執行的事件，對於那些已經回滾的事物等等的操作不會記錄在binlog裏。binlog存儲方式有三種
binlog_format = statement 記錄所有的sql語句，所以佔用空間小，但相比來說不太安全，怕出現數據不統一的問題
優點：佔用磁盤空間小。數據庫表結構可以不同（因爲執行的是sql語句，所以比如說字段順序不一致可以接受，但這種問題幾乎不會涉及）
缺點：對於非確定性事件，無法保證主從複製數據的一致性。
binlog_format = row mysql5.7之後默認使用的格式
優點：傳說中可以防止主從複製時的數據不一致問題，因爲記錄了每一行的更改，不記錄sql語句，主從複製數據完全一致。另外可以減少從庫上鎖的使用（前提是大批量的操作的情況下，個人認爲幾乎可以忽略）
缺點：佔用空間大。無法觸發觸發器
binlog_format = mixed 混合上面兩種 根據sql語句由系統決定使用哪一種
綜合考慮，使用row這種格式。
二進制日誌在mysql默認是不開啓的，通過在配置文件中設置log_bin = mysql 即可開啓；通過datadir 查看二進制日誌的存放地址
5.4 mysql 複製工作原理
1 主服務器將所有操作記錄到二進制日誌中
2 從服務器讀取主服務器上的二進制日誌記錄到relay_log中
3 從服務器執行relay_log中的操作
5.5 配置MYSQL 複製
基於日誌的複製
1 在主庫上建立複製賬號 create user ‘username’@’ip’ identified by ‘password’ 需要注意的是是這裏的ip指的是允許複製的ip地址，也就是從庫的ip
2 進行授權 grant replication slave on . to ‘username’@’ip’
3 配置主庫
log_bin = mysql_bin 用於開啓二進制日誌，並且指定名稱.mysql_bin可以自己定義
server_id = 1
4 配置從庫
log_bin = mysql_bin
server_id = 2（主和從的server_id是不同的）
relay_log = mysql-relay-bin
log_slave_update = on [可選] 對於將該從庫當做主庫來進行復制時必須開啓
read_only = on [可選] 可以限制所有對於該服務器的寫操作
至此，配置主從的所有配置操作都已完成。那麼到了實際的生產環境中去，對於要配置主從關係的時候，從服務器不一定是和主庫上所有數據結構和數據一樣的東西，我們要在主從正式開始運行之前保持數據結構和內容是一致的，所以這時我們需要對主庫進行備份，導入到從庫然後進行操作。那麼如何進行備份呢？？？？？
mysql 備份
mysqldump 這是mysql內置的備份命令，使用此命令時需要對錶進行加鎖
xtrabackup 熱備工具。對於全部使用innodb的庫備份時可以不阻塞服務器，優先選擇。對於混合的時候，同樣會進行所操作。
啓動複製鏈路
這是在從庫上進行的操作，告訴從庫開始同步主庫的binlog,同時也可以告訴從庫從什麼位置開始進行同步
change master xxxxxxxxxxxxxxxxx
使用start master 啓動複製鏈路
這時會在從庫上開啓兩個關於複製的線程，第一個是將主庫binlog同步過來的線程。第二是執行relay_log的線程
基於日誌點複製的優缺點：
優點：最早支持複製的技術，bug相對較少。對sql沒有任何限制（因爲這裏執行的只是單純的sql）.故障處理比較容易
缺點：
基於GTID的複製 mysql5.6以上纔開始支持
1 建立複製賬號
2 授權
3 主庫配置
bin_log = /usr/local/mysql/log/mysql-bin
server_id
gtid_mode = on 是否啓用gtid模式
enforce_gtid_consite 強制gtid的一致性，用於保證事物的安全
log_slave_updates = on 用於從庫記錄主庫傳輸過來的修改日誌
4 從庫配置
server_id
relay_log =
gtid_mode = on
enforce_gtid_consite
read_only = on [可選]
啓動基於GTID的複製
change master xxxxxxx
6
7 數據庫監控
7.1 對服務可用性進行監控 進程或端口號存在不能夠說明數據庫就是可用的，我們必須通過網絡連接切實連接到數據庫中並做一些操作才能說明數據庫是可用的
7.2 對性能進行監控
7.3 對主從複製進行監控
7.4 對服務器的資源進行監控