優化方式
1.空間換時間（冗餘）
2.時間換空間
字段優先使用型別
int > date > char > varchar > text
索引型別
btree索引、hash索引
索引的葉子下，存放乙個資訊指向所在行的資料位址。
btree有利於範圍查詢，hash有利於精確查詢。
btree用的更多一些。
btree索引的常見誤區
1.在where條件的常用的列上都加上索引
(因為索引同時只能用上乙個)
可以用多列聯合索引來處理多條件查詢。
優化要實地調研，結合實際場景，然後加上多列索引。
聯合索引的順序很重要，影響著查詢的效果。
為什麼商品表，在**price上加了索引，查詢速度沒有提公升？
答：正常的查詢都是復合查詢，根據多條件查詢，比如分類下商品的**。可以加上（cat_id,price）復合索引來解決這個問題。
索引作用
1.提高查詢速度
2.提高排序速度
3.提高分組統計速度
myisam（非聚簇索引）和innodb（聚簇索引）引擎
對應非聚簇索引和聚簇索引（都是btree索引）
非聚簇索引，索引和資料是分開的。
聚簇索引的葉子節點比較大，直接儲存其他的字段的資料。
聚簇索引，當你找到索引的位置時候，就不需要回行去找資料了。直接就獲取了資料。
myisam（非聚簇索引）索引指向行在磁碟上的位置。
innodb（聚簇索引）次級索引指向對主鍵索引的引用。
聚簇索引，亂序插入資料，最終的資料仍然是有序的。非聚簇索引，如果是亂序插入，最終的資料就會是亂序的。
btree索引的**，如果是性別索引，將會分成三塊，男、女、null。每個對應很多資料。所以，即便快速知道男女，還是要逐條查詢獲取資料。
什麼是索引覆蓋？
如果查詢的內容，能直接從索引上獲取，那麼就不需要回行到磁碟上去找資料了。這種查詢效率很快。
理想的索引
查詢頻繁，
區分度高（不要給性別加索引），
長度小，
盡可能覆蓋常用查詢字段。
如果有1000條資料，去除重複後，有200個。那個相當於5條資料共用乙個索引。
如果是1000條性別資料，去除重複後，只有男、女。那麼相當於500條資料共用乙個索引。區分度不高。
索引的新增要分析使用者查詢的習慣，分析查詢日誌，合理的新增索引。
重複索引和冗餘索引
重複索引是指在同乙個列，或者順序相同的幾個列，建立多個索引。
重複索引沒有任何幫助，只會增加索引檔案，拖累更新速度。
冗餘索引允許存在。
index arttag(artid,tag) index tagart(tag,artid)
這兩個索引，列有重疊，但是順序不一樣，稱為冗餘索引。可以利用索引的索引覆蓋，快速獲取資料。
索引碎片
在長期的資料更改過程中，索引檔案和資料檔案，都將產生空洞，形成碎片。
修復碎片，就是講表和索引重建一下，將其碼放整齊了。
sql語句優化
查詢取出
如何查的快?
聯合索引的順序，區分度，長度
如何取得快？
索引覆蓋
傳輸的少，更少的行和列
sql語句優化思路？
不查，少查，高效的查
不查，通過業務邏輯來計算
必須要查，盡量走索引，走索引覆蓋。
explain分析
select_type
****** 不含子查詢
primary 含子查詢，外層叫primary，裡面分多種（derived、union、subquery....）
possible_key 可能用到的索引，只能用到乙個。
key 最終用到的索引。
key_len用到索引的最大長度。
定長字段，int佔四個位元組、date佔三個位元組、char(n)佔n個字元。
對於變成欄位varchar(n)，則有n個字元+兩個位元組。
不同的字符集，乙個字元占用的位元組數不同。latin1編碼的，乙個字元占用乙個位元組，gbk編碼的，乙個字元占用兩個位元組，utf8編碼的，乙個字元占用三個位元組。
type
all查詢所有資料。
index掃瞄所有的索引節點，相當於index_all。
range，查詢範圍。
ref，引用查詢。
eq_ref，準確指到一行。
const，system，null 查詢速度超快。
rows代表，估計要掃瞄多少行。
extra
using index，速度極快，用到了索引覆蓋。
using where，用到了篩選。
using temporary ，用到了臨時表。不太好。
using filesort ，用到了排序。
如果查詢條件中有函式，或者表示式，索引在查詢上將不會被使用。索引覆蓋依然有可能使用到索引。
不鼓勵三表聯查，多表聯查說明表設計的有問題。
少用in查詢，它會全部逐行搜尋查詢對比，查詢慢。
desc table_name; # 可以檢視表字段詳情
explain sql; # 可以檢視語句執**況
mysql key值（pri, uni, mul）的含義
pri表示主鍵索引
uni表示唯一索引
mul表示可重複索引
count
查詢全部的很快，因為總數已經被記錄。
但是只要加條件，就需要逐行統計。
看下面的圖，大概sql逐行找，1,2,3...1000。就停止了。
沿著索引列，一邊走，一邊統計。
group by的列要有索引，可以避免臨時表及檔案排序。
order by的列要盡量跟group by 一致，否則也會引起臨時表。（知其然，知其所以然。）
group by 是必排序的。
union必產生臨時表。
資料少的話，sql沒必要優化。但是資料量一旦指數級的增長，sql優化就非常的有必要了。
要想去重，就得排序，只要排序，資料就慢。
limit翻頁優化
有意思的，當offset很大的時候，同樣是取3條資料，卻要20多秒。
大量的資料，拿了仍，拿了仍導致的。
優化辦法：
1.業務上，不允許翻過100頁。
如果經理非讓翻到10000頁，先在心裡罵他兩句，然後接著幹活。
2.不用offset，用條件查詢。
limit 5,3;
where id > 5 limit 3;
但是資料不可以刪除，否則計算出的分頁跟實際的分頁不一致。
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...
mysql的效能優化 mysql效能優化
檢視安裝指令碼 select version 非互動式超時時間，如jdbc show global variables like wait timeout 互動式超時時間，如資料庫工具 show global variables like interactive timeout show sessi...
mysql 效能優化 命令 mysql效能優化
發現問題 當發現程式執行比較慢的時候，首先排除物力資源問題之後，就將注意力轉向mysq資料庫 1 首先確定執行慢的sql語句 mysql show full processlist 2 確認低效的查詢 多次執行第一步發現time耗費大的sql語句。檢視耗費的時間。3 分析效能 為sql生成乙個執行計...