mysql 优化(一)
數據庫的操作越來越成為整個應用的瓶頸,mysql優化是提高應用性能的重中之重,今天來講講最近研究的mysql 的一些性能優化
Mysql的性能優化
(一) 開啟查詢緩存優化的你查詢速度
如何開啟mysql的查詢緩存?你的mysql數據庫是否支持mysql查詢緩存?? (查詢緩存是一把雙刃劍,這里就不多說了)
查詢緩存的工作流程:
1. 服務器接收SQL,以SQL和一些其他條件為key查找緩存表(額外性能消耗)
2. 如果找到了緩存,則直接返回緩存(性能提升)
3. 如果沒有找到緩存,則執行SQL查詢,包括原來的SQL解析等.
4. 執行完SQL查詢結果以后,將SQL查詢結果存入緩存表(額外性能消耗)
打開命令行終端 輸入?show variables like "%query_cache%"; 查看你是否開啟緩存
這里的參數
have_query_cache: 你的mysql版本是否支持查詢緩存
query_cache_size :?緩存使用的總內存空間大小,單位是字節,這個值必須是1024的整數倍,否則MySQL實際分配可能跟這個數值不同
query_cache_type: 緩存的方式 有三個值?1) OFF: 關閉 ?2) ON: 總是打開?3) DEMAND: 只有明確寫了SQL_CACHE的查詢才會吸入緩存
query_cache_min_res_unit: 分配內存塊時的最小單位大小
如果你的 query_cache_type =0 ?or query_chache_size =0 那么表示沒有開啟緩存,可以修改配置文件來開啟
當有很多相同的查詢被執行了多次的時候，這些查詢結果會被放到一個緩存中，這樣，后續的相同的查詢就不用操作表?而直接訪問緩存結果了。
如果你的查詢條件有包含一些mysql的內置函數 比如 有時間 now() ,rand()等,那么講不會緩存.
比較一下下面我執行的sql語句,當我開啟查詢緩存的時候 第一次執行所消耗的時間跟第二次執行所消耗的時間 以及相同查詢語義但是大小寫不一樣.(sql語句絕對相等)
?
?
(2) EXPLAIN你的查詢語句
EXPLAIN關鍵字能夠讓你知道索引的使用,如何搜索數據的,掃描行數等等
可以幫助你分析你SELECT 語句的瓶頸因此可以優化你的SELECT語句
選擇一個復雜的sql語句
可以看到mysql是怎么樣處理你的sql語句
select_type: 有三個參數(simple,primary, union,dependent union,union result) ?simple 它表示簡單的select,沒有union和子查詢(這里只介紹simple)
table : 出自哪一張表
type :顯示的訪問類型,從性能最好到最壞以此是?system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
表中只有一行;const類型的特例
?
2)const: ?表中最有有一行匹配,const用戶比較primary key或者unique索引,因為只有一行,所以很快
?
3)eq_ref : ??mysql手冊是這樣說的:"對于每個來自于前面的表的行組合，從該表中讀取一行。這可能是最好的聯接類型，除了const類型。它用在一個索引的所有部分被聯接使用并且索引是UNIQUE或PRIMARY KEY"。即比較帶索引的列
4)ref :?對于每個來自于前面的表的行組合，所有有匹配索引值的行將從這張表中讀取。這里的索引不包括 primary和unique.
5)rang : 給定范圍內的索引,如 EXPLAIN SELECT * FROM user WHERE id IN (1,5) 或者是 BETWEEN
6)ALL : 全表掃描
possible_key : 顯示 使用的哪個索引在該表中找到行?
key : 該查詢時所用到的索引
key_len : 使用索引的長度
ref :?ref列顯示使用哪個列或常數與key一起從表中選擇行。
rows : 顯示查詢時掃描的行數,值越大越不好,所以根據這個可以判斷mysql語句的好壞以及建立索引優化
extra: 額外的信息
可以根據EXPLAIN你SELECT的查詢語句 進行相關的優化
?
(3) 為你的表合理的建立索引
這里為什么是合理呢,索引不是建得越多就越好,索引太多 對于 UPDATE DELETE INSERT 的效率都會有影響,
上面提到的EXPLAIN SELECT 語句我們可以進行分析
在table user(及table a)中 它的掃描行數是?180207行.而且是全表掃描,沒有用到索引,
在命令行中我們來執行以下該sql,查詢的時間是0.63sec
我們可以給user表中的school_id加個索引?CREATE INDEX schoolIndex ON `user`(school_id);
?
這時來看一下查詢的時間和EXPLAIN SELECT 語句,
?
?總結:可以很明顯的看出 執行時間大大減少了,而且在EXPLAIN中可以看到 type相比于之前的ALL 現在是ref (索引) ,row也相比于180207行到2385行 性能大大的提升了許多
另外需要注意的是:當你的WHERE 后面的條件是 a.name like %陳%; 這樣是不會的查詢語句 就算你給name加一個索引 也會沒有意義.
1、建立多表（三個表或以上）關聯視圖時，如果是主表和副表都有的字段，盡量使用主表的字段（特別是主表的主鍵）
2、副表的字段（無論是普通字段還是主鍵、索引字段）作為查詢條件對查詢都沒有幫助，都需進行全表檢索
?
(4)如果查詢一條數據的時候使用limit
舉個例子 :??SELECT * FROM user WHERE name='vDobgB';
當你知道 name='vDobgB'在數據庫中只有一條數據的時候使用limit會大大提升效率,這個時候mysql找到該行的時候就會返回這條數據,而不會繼續往下查找
?
(5)在join表的時候 連接條件的字段類型,應當一致,并且將其索引
如果你的應用中使用到了很多表連接查詢,應該確認表與表連接字段已經建立了索引,并且兩個字段類型是一致的.
向我上面兩表連接的字段類型都是int類型,且已經加了索引.如果你要把DECIMAL(小數)類型字段和int(整形)類型的字段連接在一起,那么Mysql就無法使用它們的索引
?
(6)避免使用 SELECT *
從數據庫里讀出越多的數據，那么查詢就會變得越慢。并且，如果你的數據庫服務器和WEB 服務器是兩臺獨立的服務器的話，這還會增加網絡傳輸的負載。
應該養成,需要什么數據就拿什么數據
?
?
(7)建立主鍵索引 即id
為每一個表都建立主鍵索引 id,而且這個id還是 AUTO_INCREMENT 最好是INT類型 ,
如果你有一張表name是唯一的,并且你給name這個字段設立為主鍵,這樣效率會減低,因為使用VARCHAR類型的主鍵低于INT類型.
而且，在MySQL 數據引擎下，還有一些操作需要使用主鍵，在這些情況下，主鍵的性能和設置變得非常重要，比如:mysql的分表, 集群等
?
(8)某些情況下使用ENUM而不是VARCHAR (但是也有一些人說慎用ENUM類型)
如果你的表中的某個字段 例如: 省份,而這個字段經常出現的且只會出現的只有 廣東省,福建省,海南省等國家的所有省份.
那么你應該給該字段的類型應該是ENUM而不是VARCHAR.
ENUM 類型是非常快和緊湊的。在實際上，其保存的是TINYINT，但其外表上顯示為字符串。
例如，指定為 ENUM("one", "two", "three") 的一個列，可以有下面所顯示的任一值。每個值的索引值也如下所示：
| 值 | 索引值 |
| NULL | NULL |
| "" | 0 |
| "one" | 1 |
| "two" | 2 |
| "three" | 3 |
?
?
?
?
?
?
(9) 使用PROCEDURE ANALYSE()取得建議
?
?其中 optimal_fieldtype會推薦我們使用怎么樣的數據類型,當表中數據了越大的時候,就越準確,但是不一定是完全準確的,你需要思考..哈哈哈哈
?
?(10)建立表的時候使用NOT NULL,而且盡量給表設定默認值
NULL 需要額外的空間,mysql的上的文檔是這么說的
?如果你的表的字段是int 那么應該給默認值 DEFAULT 0 ,如果是varchar類型 DEFAULT ' '
?
mysql的部分優化先暫時講這么多,如果有疑惑的或者是有其他見解的歡迎評論..
今天php7發布了,php7的性能相比于原來提高了百分之40%-200%.
轉載于:https://www.cnblogs.com/chenshishuo/p/5014829.html
總結
以上是生活随笔為你收集整理的mysql 优化(一)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 获取Executor提交的并发执行的任务
- 下一篇： centos 下 django 1.8