1、資料庫優化可以從以下幾個方面進行：

2、專案中，優化mysql之前，首先要開啟慢查詢日誌，在分析慢查詢日誌.

1,檢視所有日誌狀態： show variables like '%quer%';2,檢視慢查詢狀態：show variables like 'show%'

linux啟用MySQL慢查詢

程式碼如下

vim /etc/my.cnf [mysqld] slow-query-log = on # 開啟慢查詢功能 slow_query_log_file = /usr/local/mysql/data/slow-query.log # 慢查詢日誌存放路徑與名稱 long_query_time = 5 # 查詢時間超過5s的查詢語句 log-queries-not-using-indexes = on # 列出沒有使用索引的查詢語句

Windows下開啟MySQL慢查詢

MySQL在Windows系統中的配置檔案一般是是my.ini找到[mysqld]下面加上

補充：

在my.cnf或者my.ini中新增log-queries-not-using-indexes引數，表示記錄下沒有使用索引的查詢。比如：

程式碼如下

log-slow-queries=/data/mysqldata/slowquery.log # 慢查詢日誌存放路徑與名稱 long_query_time=5 # 查詢時間超過5s的查詢語句 log-queries-not-using-indexes # 列出沒有使用索引的查詢語句

3、如何分析sql查詢explain返回各列的含義extra列需要注意的返回值Using filesort:看到這個的時候，查詢就需要優化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連線型別以及儲存排序鍵值和匹配條件的全部行的行指標來排序全部行Using temporary看到這個的時候，查詢需要優化了。這裡，MYSQL需要建立一個臨時表來儲存結果，這通常發生在對不同的列集進行ORDER BY上，而不是GROUP BY上
3.1  MySql內部函式explain（查詢sql的執行計劃）使用方法以及返回各列的含義explain返回各列的含義table:顯示這一行的資料是關於哪張表的type:這是重要的列，顯示連線使用了何種型別。從最好到最差的連線型別為const、eq_reg、ref、range、index 和ALLpossible_keys:顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。key:實際使用的索引。如果為NULL,則沒有使用索引。keyjen:使用的索引的長度。在不損失精確性的情況下，長度越短越好ref:顯示索引的哪一列被使用了，如果可能的話，是一個常數rows: MYSQL認為必須檢查的用來返回請求資料的行數
例項1：mysql函式【max()】，最後一位註冊使用者的資訊進行查詢操作，圖一是沒有加索引，圖二是加了索引的，查詢出來的type和rows欄位也不相同。（參照上圖欄位段含義）圖一：

圖二：例項2： mysql函式【count() 】，獲取註冊使用者男女人數
顯然圖三不是這個查詢方法不是咱們想要的結果，圖四和圖五也一樣，利用count()函式的特性null不統計，得到了我們想要的結果(圖六)。圖三：
圖四：
圖五：
圖六：
3.2 子查詢的優化，通常情況下把子查詢優化為join查詢，但在優化的時候需要注意關聯建是否有一對多的關係，要特別注意重複資料
例項3：如圖七和圖八圖七：
圖八：
3.3GROUP BY的優化例項4：獲取每個使用者愛好的數量。使用sql執行計劃來排查，圖九使用GROUP BY查詢，關聯的表會產生臨時表和按照檔案排序，sql優化之後（圖十）就直接按照索引來查詢，避免臨時表的產生和檔案形式排序。在資料量大的時候會大大減少對伺服器的IO訪問。圖九：圖十：例項5：使用LIMIT一般都伴隨著ORDER BY（如圖十一），如果是沒有索引的欄位排序的的話會按照檔案排序，全表查詢會加大對伺服器IO的訪問。圖十一：

優化方案一：使用主鍵進行排序，不會造成全表掃描，會減少對伺服器IO的訪問。但是還有一個問題，當所查詢的條數越往後，所掃描的條數也會越多（如圖十三）圖十二：圖十三：
優化方案二：可以獲取上一個主鍵的id來做一個範圍查詢來減少對伺服器IO的訪問（如圖十四），但是因此還會出現另一個問題，要保證主鍵ID是連續的，當主鍵ID中間有缺少，會對我們查詢出來的資料不對。圖十四：

優化方案三：可以新增一個欄位用於LIMIT查詢，再加上索引，就和主鍵id產生同樣的效果，但是這樣會產生很多麻煩。4 .1、如何選擇合適的列建立索引說明：1、如果一個索引可以包含所有欄位的話，就稱之為覆蓋索引。當一張表裡的資料少的話，就可以使用覆蓋索引，這樣就可以讀取索引而不用讀取表了。2、索引欄位越小越好，因為資料庫裡的資料是已頁儲存的，如果IO一次讀取一頁的資料很多，這樣的話就可以提高伺服器IO的效率。3、在建立聯合索引的時候，一定要把離散度大的放在前面，這樣的話效果比較好例項6：通過count函式統計唯一值，值大的離散度就大，也就是說u_pass的離散度比大u_name，所以應該使用index(u_pass,u_name)
4.2、索引的維護和優化4.2.1重複索引4.2.2冗餘索引

4.2.3檢查重複及冗餘索引的工具4.2.4刪除不用的索引
說明：由於業務變更有些原來使用的索引現在不使用了也是需要清除的，這也是索引優化的一個方面了！
注意：再次的強調SQL和索引的優化對於資料庫的優化是相當重要的，這一層的優化如果做好了，其他的優化也能起到一些作用否則其他的優化所能起到的作用是微乎其微的，這一層的優化也是成本最低效果最好的一層了，所以對於資料庫的優化最好重點放在這一層。
5、資料庫結構優化5.1選擇合適的資料型別資料型別的選擇，重點在於合適二字，如何確定選擇的資料型別是否合適?1.使用可以存下你的資料的最小的資料型別。2.使用簡單的資料型別。Int要比varchar型別在mysql處理上簡單。3.儘可能的使用not null定義欄位。4.儘量少用text型別，非用不可時最好考慮分表。
例項：int、bigint、smallint 和 tinyint範圍

使用整數資料的精確數字資料型別。bigint從 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型資料（所有數字）。儲存大小為 8 個位元組。int從 -2^31 (-2,147,483,648) 到 2^31 - 1 (2,147,483,647) 的整型資料（所有數字）。儲存大小為 4 個位元組。int 的 SQL-92 同義字為 integer。smallint從 -2^15 (-32,768) 到 2^15 - 1 (32,767) 的整型資料。儲存大小為 2 個位元組。tinyint從 0 到 255 的整型資料。儲存大小為 1 位元組。註釋在支援整數值的地方支援 bigint 資料型別。但是，bigint 用於某些特殊的情況，當整數值超過 int 資料型別支援的範圍時。在資料型別優先次序表中，bigint 位於 smallmoney 和 int 之間。

例項：時間使用int型別例項：IP地址使用bigint型別
5.2 表的正規化化
什麼是正規化化？不符合第三正規化的要求會出現的問題
例項：5.3 表的反正規化化的使用
如我要查詢訂單商品表的下單人，電話，地址，訂單id和下單時間sql語句如下：使用反正規化化的表結構sqi語句的查詢效率也會提升很多，資料庫表結構的設計對sql的優化也起到了很大的作用5.4 表的垂直拆分
5.5 表的水行拆分

當表的資料比較多的時候，可以選擇將表進行水平拆分，水平拆分的本質並沒有改變表的結構僅是將原本存放在同一個表中的資料放到了多個結構一樣的表中。水平拆分的方法：6 系統配置優化6.1作業系統優化6.2 MySql配置優化
SELECT engine,ROUND(SUM(data_length+index_length)/1024/2014,1) AS "Total MB" FROM INFORMATION_SCHEMA.TABLES WHERE table_schema not in ("information_schema","performance_schema") GROUP BY ENGINE;
mysql常用配置引數1
mysql常用配置引數2
mysql常用配置引數3
mysql常用配置引數4
mysql常用配置引數5
6.3 MySql第三方配置工具https://tools.percona.com/wizard
配置MySQL的配置檔案使用工具更方便，主要就是調整配置的引數，值調整成什麼樣的引數才是合適的，估計需要補充各種基礎知識不是三言兩語說的清楚的。
就是將文字的配置方式變成了介面式的配置方式，不過經驗在此時就非常的重要了，否則壓根判斷不出什麼樣的配置才是適合的配置！
7 伺服器硬體優化模擬資料庫資料和sql語句下載：

連結：https://pan.baidu.com/s/1c1xe0WQttP9gA_uUcOVHDA 

密碼：rnjh