深入理解java—MySQL性能優化思路及總結
概述
MySQL優化需要在三個不同層次上協調進行：MySQL級別、OS級別和硬件級別。MySQL級別的優化包括表優化、查詢優化和MySQL服務器配置優化等，而MySQL的各種數據結構又最終作用於OS直至硬件設備，因此還需要了解每種結構對OS級別的資源的需要並最終導致的CPU和I/O操作等，並在此基礎上將CPU及I/O操作需要儘量降低以提升其效率。
一丶 數據庫層面的優化著眼點
1、是否正確設定了表結構的相關屬性，尤其是每個字段的字段類型是否為最佳。同時，是否為特定類型的工作組織使用了合適的表及表字段也將影響系統性能，比如，數據頻繁更新的場景應該使用較多的表而每張表有著較少字段的結構，而複雜數據查詢或分析的場景應該使用較少的表而每張表較多字段的結構等。
2、是否為高效進行查詢創建了合適的索引。
3、是否為每張表選用了合適的存儲引擎，並有效利用了選用的存儲引擎本身的優勢和特性。
4、是否基於存儲引擎為表選用了合適的行格式(row format)。例如，壓縮表在讀寫操作中會降低I/O操作需求並佔用較少的磁盤空間，InnoDB支持讀寫應用場景中使用壓縮表，但MyISAM僅能在讀環境中使用壓縮表。
5、是否使用了合適的鎖策略，如在併發操作場景中使用共享鎖，而對較高優先級的需求使用獨佔鎖等。同時，還應該考慮存儲引擎所支持的鎖類型。
6、是否為InnoDB的緩衝池、MyISAM的鍵緩存以及MySQL查詢緩存設定了合適大小的內存空間，以便能夠存儲頻繁訪問的數據且又不會引起頁面換出。
二丶 操作系統和硬件級別的優化著眼點：
1、是否為實際的工作負載選定了合適的CPU，如對於CPU密集型的應用場景要使用更快速度的CPU甚至更多數量的CPU，為有著更多查詢的場景使用更多的CPU等。基於多核以及超線程(hyperthreading)技術，現代的CPU架構越來越複雜、性能也越來越強了，但MySQL對多CPU架構的並行計算能力的利用仍然是有著不太盡如人意之處，尤其是較老的版本如MySQL 5.1之前的版本甚至無法發揮多CPU的優勢。不過，通常需要實現的CPU性能提升目標有兩類：低遲延和高吞吐量。低延遲需要更快速度的CPU，因為單個查詢只能使用一顆；而需要同時運行許多查詢的場景，多CPU更能提供更好的吞吐能力，然而其能否奏效還依賴於實際工作場景，因為MySQL尚不能高效的運行於多CPU，並且其對CPU數量的支持也有著限制。一般來說，較新的版本可以支持16至24顆CPU甚至更多。
2、是否有著合適大小的物理內存，並通過合理的配置平衡內存和磁盤資源，降低甚至避免磁盤I/O。現代的程序設計為提高性能通常都會基於局部性原理使用到緩存技術，這對於頻繁操作數據的數據庫系統來說尤其如此——有著良好設計的數據庫緩存通常比針對通用任務的操作系統的緩存效率更高。緩存可以有效地延遲寫入、優化寫入，但並能消除寫入，並綜合考慮存儲空間的可擴展性等，為業務選擇合理的外部存儲設備也是非常重要的工作。
3、是否選擇了合適的網絡設備並正確地配置了網絡對整體系統系統也有著重大影響。延遲和帶寬是網絡連接的限制性因素，而常見的網絡問題如丟包等，即是很小的丟包率也會贊成性能的顯著下降。而更重要的還有按需調整系統中關網絡方面的設置，以高效處理大量的連接和小查詢。
4、是否基於操作系統選擇了適用的文件系統。實際測試表明大部分文件系統的性能都非常接近，因此，為了性能而苦選文件系統並不划算。但考慮到文件系統的修復能力，應該使用日誌文件系統如ext3、ext4、XFS等。同時，關閉文件系統的某些特性如訪問時間和預讀行為，並選擇合理的磁盤調度器通常都會給性能提升帶來幫助。
5、MySQL為響應每個用戶連接使用一個單獨的線程，再加內部使用的線程、特殊目的線程以及其它任何由存儲引擎創建的線程等，MySQL需要對這些大量線程進行有效管理。Linux系統上的NPTL線程庫更為輕量級也更有效率。MySQL 5.5引入了線程池插件，但其效用尚不明朗。
三丶 使用InnoDB存儲引擎最佳實踐：
1、基於MySQL查詢語句中最常用的字段或字段組合創建主鍵，如果沒有合適的主鍵也最好使用AUTO_INCRMENT類型的某字段為主鍵。
2、根據需要考慮使用多表查詢，將這些表通過外鍵建立約束關係。
3、關閉autocommit。
4、使用事務(START TRANSACTION和COMMIT語句)組合相關的修改操作或一個整體的工作單元，當然也不應該創建過大的執行單元。
5、停止使用LOCK TABLES語句，InnoDB可以高效地處理來自多個會話的併發讀寫請求。如果需要在一系列的行上獲取獨佔訪問權限，可以使用SELECT ... FOR UPDATE鎖定僅需要更新的行。
6、啟用innodb_file_per_table選項，將各表的數據和索引分別進行存放。
7、評估數據和訪問模式是否能從InnoDB的表壓縮功能中受益(在創建表時使用ROW_FORMAT=COMPRESSED選項)，如果可以，則應該啟用壓縮功能。
四丶 SQL語句優化
EXPLAIN語句解析：
id:SELECT語句的標識符，一般為數字，表示對應的SELECT語句在原始語句中的位置。沒有子查詢或聯合的整個查詢只有一個SELECT語句，因此其id通常為1。在聯合或子查詢語句中，內層的SELECT語句通常按它們在原始語句中的次序進行編號。但UNION操作通常最後會有一個id為NULL的行，因為UNION的結果通常保存至臨時表中，而MySQL需要到此臨時表中取得結果。
select_type:
即SELECT類型，有如下值列表：
SIMPLE：簡單查詢，即沒有使用聯合或子查詢；
PRIMARY：UNION的最外圍的查詢或者最先進行的查詢；
UNION：相對於PRIMARY，為聯合查詢的第二個及以後的查詢；
DEPENDENT UNION：與UNION相同，但其位於聯合子查詢中(即UNION查詢本身是子查詢)；
UNION RESULT：UNION的執行結果；
SUBQUERY：非從屬子查詢，優化器通常認為其只需要運行一次；
DEPENDENT SUBQUERY：從屬子查詢，優化器認為需要為外圍的查詢的每一行運行一次，如用於IN操作符中的子查詢；
DERIVED：用於FROM子句的子查詢，即派生表查詢；
table:
輸出信息所關係到的表的表名，也有可能會顯示為如下格式：
<unionM,N>：id為M和N的查詢執行聯合查詢後的結果；
<derivedN>：id為N的查詢執行的結果集；
type:
MySQL官方手冊中解釋type的作用為“type of join(聯結的類型)”，但其更確切的意思應該是“記錄(record)訪問類型”，因為其主要目的在於展示MySQL在表中找到所需行的方式。通常有如下所示的記錄訪問類型：
system: 表中僅有一行，是const類型的一種特殊情況；
const：表中至多有一個匹配的行，該行僅在查詢開始時讀取一次，因此，該行此字段中的值可以被優化器看作是個常量(constant)；當基於PRIMARY KEY或UNIQUE NOT NULL字段查詢，且與某常量進行等值比較時其類型就為const，其執行速度非常快；
eq_ref：類似於const，表中至多有一個匹配的行，但比較的數值不是某常量，而是來自於其它表；ed_ref出現在PRIMARY KEY或UNIQUE NOT NULL類型的索引完全用於聯結操作中進行等值(=)比較時；這是除了system和const之外最好的訪問類型；
ref：查詢時的索引類型不是PRIMARY KEY或UNIQUE NOT NULL導致匹配到的行可能不惟一，或者僅能用到索引的左前綴而非全部時的訪問類型；ref可被用於基於索引的字段進行=或<=>操作；
fulltext：用於FULLTEXT索引中用純文本匹配的方法來檢索記錄。
ref_or_null：類似於ref，但可以額外搜索NULL值；
index_merge：使用“索引合併優化”的記錄訪問類型，相應地，其key字段(EXPLAIN的輸出結果)中會出現用到的多個索引，key_len字段中會出現被使用索引的最長長度列表；將多個“範圍掃描(range scan)”獲取到的行進行合併成一個結果集的操作即索引合併(index merge)。
unique_subquery：用於IN比較操作符中的子查詢中進行的“鍵值惟一”的訪問類型場景中，如 value IN (SELECT primary_key FROM single_table WHERE some_expr)；
index_subquery：類似於unique_subquery，但子查詢中鍵值不惟一；
range：帶有範圍限制的索引掃描，而非全索引掃描，它開始於索引裡的某一點，返回匹配那個值的範圍的行；相應地，其key字段(EXPLAIN的輸出結果)中會輸出所用到的索引，key_len字段中會包含用到的索引的最長部分的長度；range通常用於將索引與常量進行=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或IN()類的比較操作中；
index：同全表掃描(ALL)，只不過是按照索引的次序進行而不行的次序；其優點是避免了排序，但是要承擔按索引次序讀取整個表的開銷，這意味著若是按隨機次序訪問行，代價將非常大；
ALL：“全表掃描”的方式查找所需要的行，如果第一張表的查詢類型(EXPLAIN的輸出結果)為const，其性能可能不算太壞，而第一張表的查詢類型為其它結果時，其性能通常會非常差；
Extra:
Using where：MySQL服務器將在存儲引擎收到數據後進行“後過濾(post-filter)”以限定發送給下張表或客戶端的行；如果WHERE條件中使用了索引列，其讀取索引時就由存儲引擎檢查，因此，並非所有帶有WHERE子句的查詢都會顯示“Using where”；
Using index：表示所需要的數據從索引就能夠全部獲取到，從而不再需要從表中查詢獲取所需要數據，這意味著MySQL將使用覆蓋索引；但如果同時還出現了Using where，則表示索引將被用於查找特定的鍵值；
Using index for group-by：類似於Using index，它表示MySQL可僅通過索引中的數據完成GROUP BY或DISTINCT類的查詢；
Using filesort：表示MySQL會對結果使用一個外部索引排序，而不是從表裡按索引次序來讀取行；
五丶 索引優化
聚集索引
非聚集索引
主索引
輔助索引
稠密索引
稀疏索引
稠密索引：
每一個值的變化都有對應的索引。
稀疏索引：
索引和值的變化不是一一對應關係。
注意：主索引也得是稠密索引
輔助索引可以使用稠密或稀疏索引。
聚集索引必須是稠密索引
多級索引：
為了降低索引查詢數據量。
二級索引
但是會產生多次IO
B+樹（多級索引）
Hash索引
空間索引
全文索引
從根到每一個葉子節點的路徑都是等長的。
平衡樹索引
Balance Tree
索引：加速查詢
索引：降低寫入速度
表頻繁更新，索引也要更新
插入，刪除，更新等性能的影響
hash
key-value
hash碼
age：hash索引
1：hash
key（hash）--->value
注意：主鍵不能使用hash索引
桶：
性能比較，IO少
靜態hash
不適合進行數據運算的，做等值查詢比較好用。
InnoDB：自適應hash索引
覆蓋索引：索引使用方法
students:
id,name,age,salary
name,age:組合索引
左
查詢和搜索鍵做到索引裡。
B樹索引的使用場景：
適用全鍵值，鍵值範圍或鍵值前綴查找。
name：
ling huchong
zhang wuji
zhang sanfeng
chen xuanfeng
chen yanzong
select * from where name like 'chen%';
B樹侷限性：
如果不是從最左前綴開始，索引沒用
where name like '%u%'
不能跳過索引中的列。
where name like 'chen%' and salary>3000
存儲引擎不能優化訪問任何第一個範圍條件右邊的列。
hash索引：
等值條件比較,只支持使用,IN(),<>進行的條件比較。
缺陷：
無法使用索引排序
不支持部分鍵匹配
InnoDB：主索引（聚集索引），輔助索引
要用到兩次索引
聚集索引
索引和實際數據保存在一起的數據。
索引：指針
索引必須載入內存
非聚集索引：索引和數據不保存在一起。
MYISAM：是非聚集的
InnoDB：是聚集索引
輔助索引是指向主索引的。
一張表只能有一個索引，聚集索引只有一個。
輔助索引是指向索引的，所以要執行兩次索引。
什麼字段查詢最多是
六丶 MYISAM的調優參數
key_buffer_size 鍵緩衝大小
加速查詢操作
concurreat_insert
空隙插入
delay_key_write
延時鍵寫入 異步
七丶 InnoDB性能參數：
innodb_buffer_pool_size
緩存索引和數據(使用大內存頁)
innodb_flush_log_at_trx_commit
事務提交
innodb_log_file_size:
事務日誌大小
key：value
select語句的hash碼：語句的查詢結果：
select name from student where age=30;
select name from student where age=30;
select name student whwere
儘量使用
query_alloc_block_size
query_cache_limit
query_cache_min_res_unit
query_cache_size bash
query_cache_type
query_cache_type
query_cache_type
explain
顯示語句執行計劃：
select_type
select name from student union select name from tutors;
總結
到這裡深入理解java—MySQL性能優化思路及總結結束了，不足之處還望大家多多包涵！！覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）
下面和大家交流幾點編程的經驗：
1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的
2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。
3丶 簡化算法，代碼如惡魔，在你完成編碼後，應回頭並且優化它。從長遠來看，這裡或那裡一些的改進，會讓後來的支持人員更加輕鬆。
最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。
想了解學習以上內容可加群469717771 驗證：（009）
概述
MySQL優化需要在三個不同層次上協調進行：MySQL級別、OS級別和硬件級別。MySQL級別的優化包括表優化、查詢優化和MySQL服務器配置優化等，而MySQL的各種數據結構又最終作用於OS直至硬件設備，因此還需要了解每種結構對OS級別的資源的需要並最終導致的CPU和I/O操作等，並在此基礎上將CPU及I/O操作需要儘量降低以提升其效率。
一丶 數據庫層面的優化著眼點
1、是否正確設定了表結構的相關屬性，尤其是每個字段的字段類型是否為最佳。同時，是否為特定類型的工作組織使用了合適的表及表字段也將影響系統性能，比如，數據頻繁更新的場景應該使用較多的表而每張表有著較少字段的結構，而複雜數據查詢或分析的場景應該使用較少的表而每張表較多字段的結構等。
2、是否為高效進行查詢創建了合適的索引。
3、是否為每張表選用了合適的存儲引擎，並有效利用了選用的存儲引擎本身的優勢和特性。
4、是否基於存儲引擎為表選用了合適的行格式(row format)。例如，壓縮表在讀寫操作中會降低I/O操作需求並佔用較少的磁盤空間，InnoDB支持讀寫應用場景中使用壓縮表，但MyISAM僅能在讀環境中使用壓縮表。
5、是否使用了合適的鎖策略，如在併發操作場景中使用共享鎖，而對較高優先級的需求使用獨佔鎖等。同時，還應該考慮存儲引擎所支持的鎖類型。
6、是否為InnoDB的緩衝池、MyISAM的鍵緩存以及MySQL查詢緩存設定了合適大小的內存空間，以便能夠存儲頻繁訪問的數據且又不會引起頁面換出。
二丶 操作系統和硬件級別的優化著眼點：
1、是否為實際的工作負載選定了合適的CPU，如對於CPU密集型的應用場景要使用更快速度的CPU甚至更多數量的CPU，為有著更多查詢的場景使用更多的CPU等。基於多核以及超線程(hyperthreading)技術，現代的CPU架構越來越複雜、性能也越來越強了，但MySQL對多CPU架構的並行計算能力的利用仍然是有著不太盡如人意之處，尤其是較老的版本如MySQL 5.1之前的版本甚至無法發揮多CPU的優勢。不過，通常需要實現的CPU性能提升目標有兩類：低遲延和高吞吐量。低延遲需要更快速度的CPU，因為單個查詢只能使用一顆；而需要同時運行許多查詢的場景，多CPU更能提供更好的吞吐能力，然而其能否奏效還依賴於實際工作場景，因為MySQL尚不能高效的運行於多CPU，並且其對CPU數量的支持也有著限制。一般來說，較新的版本可以支持16至24顆CPU甚至更多。
2、是否有著合適大小的物理內存，並通過合理的配置平衡內存和磁盤資源，降低甚至避免磁盤I/O。現代的程序設計為提高性能通常都會基於局部性原理使用到緩存技術，這對於頻繁操作數據的數據庫系統來說尤其如此——有著良好設計的數據庫緩存通常比針對通用任務的操作系統的緩存效率更高。緩存可以有效地延遲寫入、優化寫入，但並能消除寫入，並綜合考慮存儲空間的可擴展性等，為業務選擇合理的外部存儲設備也是非常重要的工作。
3、是否選擇了合適的網絡設備並正確地配置了網絡對整體系統系統也有著重大影響。延遲和帶寬是網絡連接的限制性因素，而常見的網絡問題如丟包等，即是很小的丟包率也會贊成性能的顯著下降。而更重要的還有按需調整系統中關網絡方面的設置，以高效處理大量的連接和小查詢。
4、是否基於操作系統選擇了適用的文件系統。實際測試表明大部分文件系統的性能都非常接近，因此，為了性能而苦選文件系統並不划算。但考慮到文件系統的修復能力，應該使用日誌文件系統如ext3、ext4、XFS等。同時，關閉文件系統的某些特性如訪問時間和預讀行為，並選擇合理的磁盤調度器通常都會給性能提升帶來幫助。
5、MySQL為響應每個用戶連接使用一個單獨的線程，再加內部使用的線程、特殊目的線程以及其它任何由存儲引擎創建的線程等，MySQL需要對這些大量線程進行有效管理。Linux系統上的NPTL線程庫更為輕量級也更有效率。MySQL 5.5引入了線程池插件，但其效用尚不明朗。
三丶 使用InnoDB存儲引擎最佳實踐：
1、基於MySQL查詢語句中最常用的字段或字段組合創建主鍵，如果沒有合適的主鍵也最好使用AUTO_INCRMENT類型的某字段為主鍵。
2、根據需要考慮使用多表查詢，將這些表通過外鍵建立約束關係。
3、關閉autocommit。
4、使用事務(START TRANSACTION和COMMIT語句)組合相關的修改操作或一個整體的工作單元，當然也不應該創建過大的執行單元。
5、停止使用LOCK TABLES語句，InnoDB可以高效地處理來自多個會話的併發讀寫請求。如果需要在一系列的行上獲取獨佔訪問權限，可以使用SELECT ... FOR UPDATE鎖定僅需要更新的行。
6、啟用innodb_file_per_table選項，將各表的數據和索引分別進行存放。
7、評估數據和訪問模式是否能從InnoDB的表壓縮功能中受益(在創建表時使用ROW_FORMAT=COMPRESSED選項)，如果可以，則應該啟用壓縮功能。
四丶 SQL語句優化
EXPLAIN語句解析：
id:SELECT語句的標識符，一般為數字，表示對應的SELECT語句在原始語句中的位置。沒有子查詢或聯合的整個查詢只有一個SELECT語句，因此其id通常為1。在聯合或子查詢語句中，內層的SELECT語句通常按它們在原始語句中的次序進行編號。但UNION操作通常最後會有一個id為NULL的行，因為UNION的結果通常保存至臨時表中，而MySQL需要到此臨時表中取得結果。
select_type:
即SELECT類型，有如下值列表：
SIMPLE：簡單查詢，即沒有使用聯合或子查詢；
PRIMARY：UNION的最外圍的查詢或者最先進行的查詢；
UNION：相對於PRIMARY，為聯合查詢的第二個及以後的查詢；
DEPENDENT UNION：與UNION相同，但其位於聯合子查詢中(即UNION查詢本身是子查詢)；
UNION RESULT：UNION的執行結果；
SUBQUERY：非從屬子查詢，優化器通常認為其只需要運行一次；
DEPENDENT SUBQUERY：從屬子查詢，優化器認為需要為外圍的查詢的每一行運行一次，如用於IN操作符中的子查詢；
DERIVED：用於FROM子句的子查詢，即派生表查詢；
table:
輸出信息所關係到的表的表名，也有可能會顯示為如下格式：
<unionM,N>：id為M和N的查詢執行聯合查詢後的結果；
<derivedN>：id為N的查詢執行的結果集；
type:
MySQL官方手冊中解釋type的作用為“type of join(聯結的類型)”，但其更確切的意思應該是“記錄(record)訪問類型”，因為其主要目的在於展示MySQL在表中找到所需行的方式。通常有如下所示的記錄訪問類型：
system: 表中僅有一行，是const類型的一種特殊情況；
const：表中至多有一個匹配的行，該行僅在查詢開始時讀取一次，因此，該行此字段中的值可以被優化器看作是個常量(constant)；當基於PRIMARY KEY或UNIQUE NOT NULL字段查詢，且與某常量進行等值比較時其類型就為const，其執行速度非常快；
eq_ref：類似於const，表中至多有一個匹配的行，但比較的數值不是某常量，而是來自於其它表；ed_ref出現在PRIMARY KEY或UNIQUE NOT NULL類型的索引完全用於聯結操作中進行等值(=)比較時；這是除了system和const之外最好的訪問類型；
ref：查詢時的索引類型不是PRIMARY KEY或UNIQUE NOT NULL導致匹配到的行可能不惟一，或者僅能用到索引的左前綴而非全部時的訪問類型；ref可被用於基於索引的字段進行=或<=>操作；
fulltext：用於FULLTEXT索引中用純文本匹配的方法來檢索記錄。
ref_or_null：類似於ref，但可以額外搜索NULL值；
index_merge：使用“索引合併優化”的記錄訪問類型，相應地，其key字段(EXPLAIN的輸出結果)中會出現用到的多個索引，key_len字段中會出現被使用索引的最長長度列表；將多個“範圍掃描(range scan)”獲取到的行進行合併成一個結果集的操作即索引合併(index merge)。
unique_subquery：用於IN比較操作符中的子查詢中進行的“鍵值惟一”的訪問類型場景中，如 value IN (SELECT primary_key FROM single_table WHERE some_expr)；
index_subquery：類似於unique_subquery，但子查詢中鍵值不惟一；
range：帶有範圍限制的索引掃描，而非全索引掃描，它開始於索引裡的某一點，返回匹配那個值的範圍的行；相應地，其key字段(EXPLAIN的輸出結果)中會輸出所用到的索引，key_len字段中會包含用到的索引的最長部分的長度；range通常用於將索引與常量進行=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或IN()類的比較操作中；
index：同全表掃描(ALL)，只不過是按照索引的次序進行而不行的次序；其優點是避免了排序，但是要承擔按索引次序讀取整個表的開銷，這意味著若是按隨機次序訪問行，代價將非常大；
ALL：“全表掃描”的方式查找所需要的行，如果第一張表的查詢類型(EXPLAIN的輸出結果)為const，其性能可能不算太壞，而第一張表的查詢類型為其它結果時，其性能通常會非常差；
Extra:
Using where：MySQL服務器將在存儲引擎收到數據後進行“後過濾(post-filter)”以限定發送給下張表或客戶端的行；如果WHERE條件中使用了索引列，其讀取索引時就由存儲引擎檢查，因此，並非所有帶有WHERE子句的查詢都會顯示“Using where”；
Using index：表示所需要的數據從索引就能夠全部獲取到，從而不再需要從表中查詢獲取所需要數據，這意味著MySQL將使用覆蓋索引；但如果同時還出現了Using where，則表示索引將被用於查找特定的鍵值；
Using index for group-by：類似於Using index，它表示MySQL可僅通過索引中的數據完成GROUP BY或DISTINCT類的查詢；
Using filesort：表示MySQL會對結果使用一個外部索引排序，而不是從表裡按索引次序來讀取行；
五丶 索引優化
聚集索引
非聚集索引
主索引
輔助索引
稠密索引
稀疏索引
稠密索引：
每一個值的變化都有對應的索引。
稀疏索引：
索引和值的變化不是一一對應關係。
注意：主索引也得是稠密索引
輔助索引可以使用稠密或稀疏索引。
聚集索引必須是稠密索引
多級索引：
為了降低索引查詢數據量。
二級索引
但是會產生多次IO
B+樹（多級索引）
Hash索引
空間索引
全文索引
從根到每一個葉子節點的路徑都是等長的。
平衡樹索引
Balance Tree
索引：加速查詢
索引：降低寫入速度
表頻繁更新，索引也要更新
插入，刪除，更新等性能的影響
hash
key-value
hash碼
age：hash索引
1：hash
key（hash）--->value
注意：主鍵不能使用hash索引
桶：
性能比較，IO少
靜態hash
不適合進行數據運算的，做等值查詢比較好用。
InnoDB：自適應hash索引
覆蓋索引：索引使用方法
students:
id,name,age,salary
name,age:組合索引
左
查詢和搜索鍵做到索引裡。
B樹索引的使用場景：
適用全鍵值，鍵值範圍或鍵值前綴查找。
name：
ling huchong
zhang wuji
zhang sanfeng
chen xuanfeng
chen yanzong
select * from where name like 'chen%';
B樹侷限性：
如果不是從最左前綴開始，索引沒用
where name like '%u%'
不能跳過索引中的列。
where name like 'chen%' and salary>3000
存儲引擎不能優化訪問任何第一個範圍條件右邊的列。
hash索引：
等值條件比較,只支持使用,IN(),<>進行的條件比較。
缺陷：
無法使用索引排序
不支持部分鍵匹配
InnoDB：主索引（聚集索引），輔助索引
要用到兩次索引
聚集索引
索引和實際數據保存在一起的數據。
索引：指針
索引必須載入內存
非聚集索引：索引和數據不保存在一起。
MYISAM：是非聚集的
InnoDB：是聚集索引
輔助索引是指向主索引的。
一張表只能有一個索引，聚集索引只有一個。
輔助索引是指向索引的，所以要執行兩次索引。
什麼字段查詢最多是
六丶 MYISAM的調優參數
key_buffer_size 鍵緩衝大小
加速查詢操作
concurreat_insert
空隙插入
delay_key_write
延時鍵寫入 異步
七丶 InnoDB性能參數：
innodb_buffer_pool_size
緩存索引和數據(使用大內存頁)
innodb_flush_log_at_trx_commit
事務提交
innodb_log_file_size:
事務日誌大小
key：value
select語句的hash碼：語句的查詢結果：
select name from student where age=30;
select name from student where age=30;
select name student whwere
儘量使用
query_alloc_block_size
query_cache_limit
query_cache_min_res_unit
query_cache_size bash
query_cache_type
query_cache_type
query_cache_type
explain
顯示語句執行計劃：
select_type
select name from student union select name from tutors;
總結
到這裡深入理解java—MySQL性能優化思路及總結結束了，不足之處還望大家多多包涵！！覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）
下面和大家交流幾點編程的經驗：
1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的
2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。
3丶 簡化算法，代碼如惡魔，在你完成編碼後，應回頭並且優化它。從長遠來看，這裡或那裡一些的改進，會讓後來的支持人員更加輕鬆。
最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。
想了解學習以上內容可加群469717771 驗證：（009）