MySQL學習筆記——讀《MySQL技術內幕 InnoDB存儲引擎》

show ENGINES; #存儲引擎支持狀況

select version(); #查看當前版本號

ALTER table mytest ENGINE = MyISAM; #更改表引擎

show VARIABLES like 'innodb_%io_threads'; #列出數據庫屬性變量字段

show ENGINE INNODB STATUS; #InnoDB當前狀態 包括鎖的狀況 表更新的狀況 線程的狀況 緩衝池的狀況 表總體增刪改查的次數

select * from INNODB_BUFFER_POOL_STATS; #查看InnoDB緩存池的狀態

select @@tx_isolation; #查看當前隔離級別

官方文檔：dev.mysql.com/doc/refman/… 有中文版 以下圖所示：

重點參數分析： 1.innodb_io_capacity #每次從緩存區刷新髒頁到磁盤時，刷新髒頁的最大數量（固態硬盤能夠根據實際狀況調高這個數值） 2.show GLOBAL STATUS like 'innodb_dblwr%'; Innodb_dblwr_pages_written/Innodb_dblwr_writes若是遠小於64 說明系統寫入壓力並非很高 3.innodb_flush_neighbors #是否刷新鄰近頁 若是是機械硬盤則打開 若是是固態硬盤 則設置爲0 4.innodb_fast_shutdown #非正常關閉時的full purge,merge insert buffer,髒頁刷回磁盤的策略

InnoDB的關鍵特性： 1.Insert Buffer 使用條件：a.索引是輔助索引 b.索引不是惟一的 2.兩次寫 3.自適應hash索引 4.AIO 5.刷新鄰接頁

InnoDB的優化方案： 1.數據庫層面 a.錯誤日誌 2.表層面 a.慢查詢日誌 long_query_time slow_query_log 參數的設置 log_queries_not_using_indexes #這個參數是用來記錄沒有使用索引的SQL語句 能夠有效記錄索引失效的狀況 set GLOBAL log_output='TABLE' 能夠配置慢查詢記錄爲表輸入 這樣就能夠經過 SELECT * FROM slow_log 來查詢了

小技巧： 1.在數據導入過程當中關閉外鍵約束的檢查以減小時間開銷： SET foreign_key_checks = 0; LOAD DATA .... SET foreign_key_checks = 1; 2. select database() from dual; #查看當前數據庫 3. InnoDB常常會自行「優化重構」sql語句 能夠經過 EXPLAIN EXTENDED sql語句 的方式來查看優化過的sql語句 4. innodb_flush_log_at_trx_commit 和 sync_binlog這兩個參數對數據庫寫入性能影響很大，在安全性要求不高（好比刷數據的時候）的狀況下，能夠都關閉，可以極大地提高性能 5. 全文檢索 默認字段不能少於4字節 不然不計入統計範圍 默認字段長度的參數爲？

比較容易忽視的參數： 1.innodb_online_alter_log_max_size: 實現Online DDL的索引修改時，用來存放DML操做日誌的緩存大小。在LOCK爲NONE時，若是這個參數過小，容易拋異常，見書本P210

InnoDB漏洞和補救： 1.索引信息的統計和索引的使用存在不穩定現象 好比索引的cardinality的統計值並非實時的（由於若是是實時的話 開銷太大了） 好比對兩條基本同樣的語句執行explain 可是最終結果 一個使用了索引 一個沒使用 因此 建議在非高峯時期 對核心表作ANALYZE TABLE的操做 能使優化器和索引更好工做

索引的使用： 1.InnoDB引擎中只有BTREE索引 高選擇性的時候用索引，高選擇性的判斷依據是索引的cardinality show index from table; #查看某張表中索引的狀態（包含了cardinality屬性） cardinality/記錄數 接近1的時候 說明具備高選擇性 就能夠使用索引（好比性別這類的字段就不適合加索引） OLTP和OLAP應用也不一樣：OLTP可能會對姓名等進行查找，能夠加索引。OLAP就不多會對這種微觀的角度進行分析，因此能夠不加索引，除非有hash join的場景。OLAP經常會對時間作索引，也能夠結合partition對時間段統計類查詢進行優化。 2.須要指定索引時 用FORCE INDEX 而不是 USE INDEX 3.一樣一個輔助索引，一樣的查詢，InNoDB會根據數據量大小而採起全表掃描仍是使用索引

`DROP TABLE IF EXISTS `t_playlist_info_test`;
CREATE TABLE `t_playlist_info_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `vivo_tags` varchar(50) DEFAULT '' COMMENT 'vivo標籤',
  PRIMARY KEY (`id`),
  KEY `idx_vivo_tags` (`vivo_tags`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='歌單表';`
複製代碼

當這個表數據量1000時 執行：

`EXPLAIN
select * from t_playlist_info_test where vivo_tags = '測試'`
複製代碼

能夠看到

採起了全表掃描的方式 並無用到vivo_tags上面的輔助索引 而當這個表數據量1W的時候 再執行上述的語句時 能夠看到

鎖機制： 用戶監控鎖狀況的三張表information_schema.INNODB_TRX,information_schema.INNODB_LOCKS,information_schema.INNODB_LOCK_WAITS

分佈式事務： 查看是否打開XA事務的支持

性能調優： 1.怎樣去預估數據庫大小 2.怎樣判斷數據庫內存到了瓶頸： show global status like 'innodb%read%';

緩存命中率=Innodb_buffer_pool_read_requests/(Innodb_buffer_pool_read_requests+Innodb_buffer_pool_reads+Innodb_buffer_pool_read_ahead) 緩存命中率低於99%就說明內存到了瓶頸

一些常識： 1.count()通常比快，緣由是count(*)會用到覆蓋索引，IO次數要比使用聚合索引少 2.參數設置有三個級別 最高級別是經過修改my.cnf 而後是set global來設置全局參數 再就是。。。