文章目錄

• • • mysql 執行過程
    • • • 連接器
        • 緩存
        • 分析器
        • 優化器
        • 執行器
    • 執行到存儲引擎，聊一聊數據頁
    • • • 數據頁分裂合并
    • 存儲引擎
    • • • MyISAM 和 innodb 對比
        • MyISAM存儲引擎的特點和應用場景
    • Innodb數據結構
    • • • 平衡二叉樹
        • B樹(B-tree)
        • B+樹
    • 基于樹的結構聊一聊mysql存儲結構
    • • • MYSQL 數據存放方式
        • • db.opt
          • .frm
          • .MYD和.MYI
          • .ibd
          • .ibd和.ibdata
        • MyISAM 存儲結構
        • InnoDB 存儲結構
      • 聊一聊索引
      • • 普通索引（這個是最基本的索引）
        • 唯一索引，要求字段所有的值是唯一的，這一點和主鍵索引一樣，但是允許有空值。
      • 主鍵索引
      • • 全文索引
        • 組合索引
        • 覆蓋索引
      • 聊一聊事務
      • 基于上面所有，再聊一聊優化

mysql 執行過程

連接器

MySQL中存在4個控制權限的表，分別為user表，db表，tables_priv表，columns_priv表,MySQL權限表的驗證過程為：

先從user表中的Host,User,Password這3個字段中判斷連接的ip、用戶名、密碼是否存在，存在則通過驗證。

通過身份認證后，進行權限分配，按照user，db，tables_priv，columns_priv的順序進行驗證。即先檢查全局權限表user，如果user中對應的權限為Y，則此用戶對所有數據庫的權限都為Y，將不再檢查db, tables_priv,columns_priv；如果為N，則到db表中檢查此用戶對應的具體數據庫，并得到db中為Y的權限；如果db中為N，則檢查tables_priv中此數據庫對應的具體表，取得表中的權限Y，以此類推

緩存

MySQL的緩存主要的作用是為了提升查詢的效率，緩存以key和value的哈希表形式存儲，key是具體的sql語句，value是結果的集合。如果無法命中緩存,就繼續走到分析器的的一步,如果命中緩存就直接返回給客戶端 。不過需要注意的是在MySQL的8.0版本以后，緩存被官方刪除掉了。之所以刪除掉,是因為查詢緩存的失效非常頻繁,如果在一個寫多讀少的環境中,緩存會頻繁的新增和失效。對于某些更新壓力大的數據庫來說，查詢緩存的命中率會非常低,MySQL為了維護緩存可能會出現一定的伸縮性的問題,目前在5.6的版本中已經默認關閉了，比較推薦的一種做法是將緩存放在客戶端，性能大概會提升5倍左右

分析器

分析器的主要作用是將客戶端發過來的sql語句進行分析，這將包括預處理與解析過程，在這個階段會解析sql語句的語義，并進行關鍵詞和非關鍵詞進行提取、解析，并組成一個解析樹。具體的關鍵詞包括不限定于以下：select/update/delete/or/in/where/group by/having/count/limit等.如果分析到語法錯誤，會直接給客戶端拋出異常:ERROR:You have an error in your SQL syntax.

優化器

夠進入到優化器階段表示sql是符合MySQL的標準語義規則的并且可以執行的，此階段主要是進行sql語句的優化

執行器

在執行器的階段,此時會調用存儲引擎的API,API會調用存儲引擎，主要有一下存儲的引擎，不過常用的還是myisam和innodb:

---

執行到存儲引擎，聊一聊數據頁

在操作系統中，我們知道為了跟磁盤交互，內存也是分頁的，一頁大小4KB。同樣的在MySQL中為了提高吞吐率，數據也是分頁的，不過MySQL的數據頁大小是16KB，1mb 分區

一行或者多行數據便是一頁

數據庫的多行數據就算多列，排列開來就是一個鏈表。

上一頁下一頁鏈表左右節點相連

#####數據區？
在MySQL的設定中，同一個表空間內的一組連續的數據頁為一個extent（區），默認區的大小為1MB，頁的大小為16KB。16*64=1024，也就是說一個區里面會有64個連續的數據頁。連續的256個數據區為一組數據區。

數據頁分裂合并

其實頁分裂，你可以理解為鏈表中間插入一條數據，假設你現在已經有兩個數據頁了。并且你正在往第二個數據頁中寫數據。

關于B+Tree，你肯定知道B+Tree中的葉子結點之間是通過雙向鏈表關聯起來的。

在InnoDB索引的設定中，要求主鍵索引是遞增的，這樣在構建索引樹的時候才更加方便。你可以腦補一下。如果按1、2、3…遞增的順序給你這些數。是不是很方便的構建一棵樹。然后你可以自由自在的在這棵樹上玩二分查找。

那假設你自定義了主鍵索引，而且你自定義的這個主鍵索引并不一定是自增的。

這種情況，比如使用雪花算法， uuid做主鍵就會造成大量io替換頁未知，造成頁分裂的概念

上圖是隨機插入的數據

上圖是需要整理成順序id > id -位移1 數據

存儲引擎

聊完了，數據的存儲過程，執行過程，那么mysql對于存儲引擎也是有區分的

常見的對比 常用的有myISAM INNODB 這兩種都是B+樹結構的

MyISAM 和 innodb 對比

MyISAM存儲引擎的特點和應用場景

MyISAM是MySQL 5.1及之前的版本的默認的存儲引擎。MyISAM提供了大量的特性，包括全文索引、壓縮、空間函數（GIS)等，但MyISAM不「支持事務和行級鎖」，對于只讀數據，或者表比較小、可以容忍修復操作，依然可以使用它。

特性
MyISAM「不支持行級鎖而是對整張表加鎖」。讀取時會對需要讀到的所有表加共享鎖，寫入時則對表加排它鎖。但在表有讀取操作的同時，也可以往表中插入新的記錄，這被稱為并發插入。

MyISAM表可以手工或者自動執行檢查和修復操作。但是和事務恢復以及崩潰恢復不同，可能導致一些「數據丟失」，而且修復操作是非常慢的。

對于MyISAM表，即使是BLOB和TEXT等長字段，也可以基于其前500個字符創建索引，MyISAM也支持「全文索引」，這是一種基于分詞創建的索引，可以支持復雜的查詢。

如果指定了DELAY_KEY_WRITE選項，在每次修改執行完成時，不會立即將修改的索引數據寫入磁盤，而是會寫到內存中的鍵緩沖區，只有在清理鍵緩沖區或者關閉表的時候才會將對應的索引塊寫入磁盤。這種方式可以極大的提升寫入性能，但是在數據庫或者主機崩潰時會造成「索引損壞」，需要執行修復操作。

Innodb數據結構

目前Mysql 用的是Innodb存儲引擎，Innodb支持事務，外鍵，表鎖，從liunx來看，數據和主鍵索引是分開放的。

Innodb和myisam使用的都是B+樹 聊Innodb 其實主要也就是聊一下B+樹

平衡二叉樹

平衡二叉樹是采用二分法思維把數據按規則組裝成一個樹形結構的數據，用這個樹形結構的數據減少無關數據的檢索，大大的提升了數據檢索的速度；平衡二叉樹的數據結構組裝過程有以下規則：

（1）非葉子節點只能允許最多兩個子節點存在。

（2）每一個非葉子節點數據分布規則為左邊的子節點小當前節點的值，右邊的子節點大于當前節點的值(這里值是基于自己的算法規則而定的，比如hash值)；

平衡樹的層級結構：因為平衡二叉樹查詢性能和樹的層級（h高度）成反比，h值越小查詢越快、為了保證樹的結構左右兩端數據大致平衡降低二叉樹的查詢難度一般會采用一種算法機制實現節點數據結構的平衡，實現了這種算法的有比如Treap、紅黑樹，使用平衡二叉樹能保證數據的左右兩邊的節點層級相差不會大于1.，通過這樣避免樹形結構由于刪除增加變成線性鏈表影響查詢效率，保證數據平衡的情況下查找數據的速度近于二分法查找

總結平衡二叉樹特點：

（1）非葉子節點最多擁有兩個子節點；

（2）非葉子節值大于左邊子節點、小于右邊子節點；

（3）樹的左右兩邊的層級數相差不會大于1;

（4）沒有值相等重復的節點;

B樹(B-tree)

B樹和平衡二叉樹稍有不同的是B樹屬于多叉樹又名平衡多路查找樹（查找路徑不只兩個），數據庫索引技術里大量使用者B樹和B+樹的數據結構，讓我們來看看他有什么特點;

（1）排序方式：所有節點關鍵字是按遞增次序排列，并遵循左小右大原則；

（2）子節點數：非葉節點的子節點數>1，且<=M ，且M>=2，空樹除外（注：M階代表一個樹節點最多有多少個查找路徑，M=M路,當M=2則是2叉樹,M=3則是3叉）；

聊完了這些樹 聊一下B+樹

B+樹

（1）B+跟B樹不同B+樹的非葉子節點不保存關鍵字記錄的指針，只進行數據索引，這樣使得B+樹每個非葉子節點所能保存的關鍵字大大增加；

（2）B+樹葉子節點保存了父節點的所有關鍵字記錄的指針，所有數據地址必須要到葉子節點才能獲取到。所以每次數據查詢的次數都一樣；

（3）B+樹葉子節點的關鍵字從小到大有序排列，左邊結尾數據都會保存右邊節點開始數據的指針。

（4）非葉子節點的子節點數=關鍵字數（來源百度百科）（根據各種資料 這里有兩種算法的實現方式，另一種為非葉節點的關鍵字數=子節點數-1（來源維基百科)，雖然他們數據排列結構不一樣，但其原理還是一樣的Mysql 的B+樹是用第一種方式實現）;

基于樹的結構聊一聊mysql存儲結構

MYSQL 數據存放方式

下圖是 MySQL（5.7.29）在 Windows 系統下安裝的數據文件目錄，可以看到有如下幾類文件。

Data 目錄用來存放數據庫相關的數據信息，包括數據庫信息，表信息等。

MySQL 5.7 及之后的版本開始支持集群模式，installer_config.xml 配置文件主要用于配置單節點或集群模式。

my.ini 文件是 MySQL 服務端和客戶端主要的配置文件，包括編碼集、默認引擎、最大連接數等設置。MySQL 服務器啟動時會默認加載此文件。

Data 目錄中存放的文件如下圖所示：

對 Data 目錄中的文件說明如下：

• mysql、performance_schema、sakila、sys 和 world 是系統數據庫，information_schema 數據庫比較特殊，這里沒有相應的數據庫目錄。
• test 是用戶自定義的數據庫，也就是用戶自己創建的數據庫。
• auto.cnf：MySQL 服務器的選項文件，用于存儲 server-uuid 的值。server-uuid 與 server-id 一樣，用于標識 MySQL 實例在集群中的唯一性。
• ib_logfile0、ib_logfile1 是支持事務性引擎的 redo 日志文件
• ibdata1 為共享表空間（系統表空間）。如果采用 InnoDB 引擎，默認大小為 10M 。
• ibtmp1 為存儲臨時對象的空間，比如臨時表對象等。

db.opt

用來保存數據庫的配置信息，比如該庫的默認字符集編碼和字符集排序規則。如果你創建數據庫時指定了字符集和排序規則，后續創建的表沒有指定字符集和排序規則，那么該表將采用 db.opt 文件中指定的屬性。

對于 InnoDB 表，如果是獨立的表空間，數據庫中的表結構以及數據都存儲在數據庫的路徑下（而不是在共享表空間 ibdata1 文件中）。但是數據中的其他對象，包括數據被修改之后，事務提交之間的版本信息，仍然存儲在共享表空間的 ibdata1 文件中。

.frm

在 MySQL 中建立任何一張數據表，其對應的數據庫目錄下都會有該表的 .frm 文件。.frm文件用來保存每個數據表的元數據（meta）和表結構等信息。數據庫崩潰時，可以用 .frm 文件恢復表結構。

.MYD和.MYI

.MYD 理解為 My Data，用于存放 MyISAM 表的數據。
.MYI 理解為 My Index，主要存放 MyISAM 表的索引及相關信息。

可以看出Myisam數據和索引是分開的

.ibd

對于 InnoDB 存儲引擎的數據表，一個表對應兩個文件，一個是 .frm，存儲表結構信息；一個是.ibd，存儲表中數據。

.ibd和.ibdata

.ibd 和 .ibdata 都是專屬于 InnoDB 存儲引擎的數據庫文件。當采用共享表空間時，所有 InnoDB 表的數據均存放在 .ibdata 中。所以當表越來越多時，這個文件會變得很大。相對應的 .ibd 就是采用獨享表空間時 InnoDB 表的數據文件

MyISAM 存儲結構

同樣是B+樹，可以看到數據存放的葉子節點是地址 由于Myisam 存儲結構是索引數據是分開的，所以底層縮影上面可以看到，存儲的地址值，根據地址值去.MYD找到對應數據

MyISAM 的索引方式也叫做“非聚集索引”,之所以這么稱呼是為了與 InnoDB的聚集索引區分。

InnoDB 存儲結構

區別是 InnoDB 的數據文件本身就是索引文件。從上文知道,MyISAM 索引文件和數據文件是分離的,索引文件僅保存數據記錄的地址，而上面從結構上面可以看到innoDB是索引和文件放在.IDB 里面的

圖不是很好，大概意思可以看到，主鍵找到對應的值之后，葉子節點上面存放著數據，這種我們叫做聚集索引。

我再找一個好圖

大概就算這樣

聊一聊索引

mysql 索引分為很多，常見的

• 主鍵索引
• 全文索引
• -唯一索引
• 普通索引
• 聯合索引
• 覆蓋索引

普通索引（這個是最基本的索引）

建表時：INDEX IndexName(字段名(length))

唯一索引，要求字段所有的值是唯一的，這一點和主鍵索引一樣，但是允許有空值。

建表時：UNIQUE INDEX IndexName(字段名(length))
建表后：CREATE UNIQUE INDEX IndexName ON TableName(字段名(length))

主鍵索引

一般在建表的時候自動創建或者手動選擇

全文索引

建表時：FULLTEXT INDEX IndexName(字段名(length))

建表后：CREATE FULLTEXT INDEX IndexName ON TableName(字段名(length))

使用： SELECT * FROM TableName
WHERE MATCH(column1， column2) AGAINST(‘xxx′， ‘xx′， ‘x′)
這條命令將把column1和column2字段里有xxx、xx和x的數據記錄全部查詢出來。

組合索引

建表時：INDEX IndexName(字段名(length)，字段名(length)，…)
建表后：CREATE INDEX IndexName ON TableName(字段名(length)，字段名(length)，…)
或ALTER TABLE TableName ADD INDEX IndexName(字段名(length)，字段名(length)，…)

覆蓋索引

所有字段的組合索引，加上之后會覆蓋data信息，就不用回標掃描了

1. 什么是索引?

項目里面，基本聽到添加索引，甚至于建立一個字典表，字典表里面存放的都是索引。索引的作用是mysql最低限度的快速找到對應字段，并且加了索引的字段，可以很大提升查詢效率，那么索引是什么呢，是一種數據結構。

2. 索引是個什么樣的數據結構呢?

說了索引的作用跟是什么，那么接下來追溯下去，索引既然是數據結構，哪屬于什么數據結構，索引的數據結構是跟具體的存儲引擎有關的。比較多的索引為hash結構的索引，B+樹索引等，我們常用的mysql InnoDB存儲引擎使用的便是B+樹索引。

3. Hash索引和B+樹所有有什么區別或者說優劣呢?

既然知道索引是一種數據結構，方便查詢，那么更具存儲引擎不同，索引數據結構不同，那么這兩種常見索引又有什么區別呢。hash索引不用說大家也知道的，hash類型的底層肯定是hash表。所以hash索引肯定是通過hash函數通過hash表返回回來鍵值然后再查詢數據出來。至于B+樹，既然是樹類型的，肯定是多節點的，從樹根節點去向上查詢，查詢子分支樹獲得鍵值然后再判斷是否要查詢數據出來

說了這么多，對比一下，有什么區別

第一，一個是通過hash函數查詢hash表 查詢數據，一個是通過平衡樹查詢節點，查詢數據。

第二，由于hash函數查詢是無序的，所以不可能覆蓋查詢，而樹狀節點，天然支持覆蓋查詢。

第三，hash數據查詢中如果鍵值一對，容易出現hash碰撞，相對不穩定，而平衡樹，從根部查詢到節點，相對穩定。

第四，平衡樹，可以存儲聚族索引，而hash不行。

4. 什么是聚簇索引

聚族索引是以索引為主鍵作為聚族索引，聚族索引比如存儲引擎B+樹里面存儲的聚族索引。那么查詢到這個主鍵索引鍵值，就不需要回標通過索引查詢數據，而是直接拿這個數據，這個查詢數據在聚族索引內。避免重復問題

舉個簡單的例子,假設我們在員工表的年齡上建立了索引,那么當進行select age from employee where age < 20的查詢時,在索引的葉子節點上,已經包含了age信息,不會再次進行回表查詢. 如果命中非主鍵的索引如果全部命中也不需要回表查詢。 如果是select * from employee where age < 20，那么必然是回表查詢。

5. 建立索引的時候,都有哪些需要考慮的因素呢?

說了這么多索引的問題，總結一下，索引是為了快速找到數據，優化查詢速度的，索引是數據結構，什么數據結構，取決于存儲引擎，常見的是B+平衡樹，和Hash索引。區別簡單了解幾點就可以了。InnoDB使用的便是平衡樹，什么是聚族索引。 那么我們創建這個索引又需要考慮什么呢。

首先既然是為了優化查詢的東西，必然是對某個字段查詢比較頻繁，比如現在有學校表。學校表id必然對應教師，學生，食堂，書館，等等關聯。在查詢這個學校的信息比如按是where 學校等于學校表的某個id，那么這個頻繁使用查詢的必然要在id字段加上索引。我們正常開發是以判斷條件比較常用的作為索引。如果需要建立聯合索引的話,還需要考慮聯合索引中的順序。

7. 聯合索引是什么?為什么需要注意聯合索引中的順序?

在mysql中，MySQL可以使用多個字段同時建立一個索引,叫做聯合索引.在聯合索引中,如果想要命中索引,需要按照建立索引時的字段順序挨個使用,否則無法命中索引.

MySQL使用索引時需要索引有序,假設現在建立了"name,age,school"的聯合索引

當進行查詢時,此時索引僅僅按照name嚴格有序,因此必須首先使用name字段進行等值查詢,之后對于匹配到的列而言,其按照age字段嚴格有序,此時可以使用age字段用做索引查找,以此類推.

簡單一點就是猶如三個高能機器，第一個執行給第二個第二個執行給第三個。

因此在建立聯合索引的時候應該注意索引列的順序,一般情況下,將查詢需求頻繁或者字段選擇性高的列放在前面.此外可以根據特例的查詢或者表結構進行單獨的調整.

select name,age,school from t_school_list

8. 那么如果創建的索引有沒有被使用到?或者說怎么才可以知道這條語句運行很慢的原因?

這個時候就要用到mysql提供的特殊字段explain命令來查看語句的執行計劃,MySQL在執行某個語句之前,會將該語句過一遍查詢優化器,之后會拿到對語句的分析,也就是執行計劃,其中包含了許多信息.

這個表里面沒有加索引，所以可以看到type 查詢全部，key無，key長度無，rows查詢7行。

添加一個普通索引

查詢表示 使用了索引 index_summ

總結可以通過explain 來查看sql執行計劃，進行優化。

9. 那么在哪些情況下會發生針對該列創建了索引但是在查詢的時候并沒有使用呢?

這個問題面試官常考這個，其實很簡單，

第一，使用不等于這個字段自然不會有這個索引。
第二，使用like模糊查詢不會使用索引
第三，使用函數不會使用索引。
第四，使用聯合索引，沒命中所有索引字段自然不會用這個索引。

稍微想一下便可以記住。

10，簡單說一下索引創建。

中文是，操作數據庫 庫名稱 增加索引 索引名 索引（）

alter table xxx add index index_index_name (ziduan)

其中xxx表示庫名

index_index_name（）表示索引名括號里面是字段名。

聊一聊事務

什么是事務?

這個問題一般面試問的比較多，說到查詢多表之間值賦值傳遞。都有可能用到事務，那么這個事務是什么

事務就是一系列的操作。當初程序員創建庫的時候，由于查詢修改數據不確定性，不一致性，所以有了事務的定義。

事務就是對數據的一系列的操作。主要為，要么全部成功要么全部失敗。
一般我們再使用對庫的增刪改 都需要用事務模板TransactionTemplate ，進行包含，或者對此方法進行@Transaction 加這個注解。

那么事務有什么特性呢

原子性

一致性

可持續化

隔離性

原子性決定了作為一個單元運行，要么全部成功要么全部失敗。
比方我再對數據進行修改的時候，修改了很多次，調了很多此Service方法，那么要么全部成功，要么全部失敗，避免修改出現與實際想法不符。

一致性的意思是 數據永遠保持一致，不會出現中間狀態。

隔離性，當一個事務再運行的時候，其他事務是看不到的。避免了我對這個數據修改，另一個指令刪除。這樣可能回導致數據非一致性。

持續化，數據是保存到硬盤上面的，一旦提交是不會改變的。

那么多個事務在進行會怎么樣呢?

如果單個增刪改其實沒什么，主要是避免出現出現多個線程同時增刪改，可以用代碼測一下，創建多個線程同時對數據增刪改。

臟讀 可以讀到未提交數據

一般如果不加事務模板，會出現，臟讀，讀到未提交的數據，

這就好像你買東西，10塊錢，老板突然準備漲價，寫了15塊錢，準備提交，你著急買，發現15塊錢就扔了15塊錢買了這個商品走了，后來老板想了想不漲了，回滾了，東西還是10塊，那么你讀到的數據就是錯的。

不可重復讀:

只能讀到已經提交的

原理和臟讀差不多，你買東西10塊錢，你10塊錢買了，老板相通了，賣15了。你再看就變成15了。這便是不可重復讀。會導致兩次查詢結果不一樣。

幻讀:

A事務讀取了一個范圍的內容list ,而同時B事務在此期間插入了一條數據.造成"幻覺"，突然多一條數據。數據不準確

3.既然多個事務有這么多問題，那么我們應該怎么處理這些問題

MySQL的提供四種隔離級別如下:

未提交讀(READ UNCOMMITTED)

這就是上面所說的例外情況了,這個隔離級別下,其他事務可以看到本事務沒有提交的部分修改.因此會造成臟讀的問題(讀取到了其他事務未提交的部分,而之后該事務進行了回滾).

這個級別的性能沒有足夠大的優勢,但是又有很多的問題,因此很少使用.

已提交讀(READ COMMITTED)

其他事務只能讀取到本事務已經提交的部分.這個隔離級別有 不可重復讀的問題,在同一個事務內的兩次讀取,拿到的結果竟然不一樣,因為另外一個事務對數據進行了修改.

REPEATABLE READ(可重復讀)

可重復讀隔離級別解決了上面不可重復讀的問題(看名字也知道),但是仍然有一個新問題,就是幻讀

當你讀取id> 10 的數據行時,對涉及到的所有行加上了讀鎖,此時例外一個事務新插入了一條id=11的數據,因為是新插入的,所以不會觸發上面的鎖的排斥

那么進行本事務進行下一次的查詢時會發現有一條id=11的數據,而上次的查詢操作并沒有獲取到,再進行插入就會有主鍵沖突的問題.

SERIALIZABLE(可串行化)

這是最高的隔離級別,可以解決上面提到的所有問題,因為他強制將所以的操作串行執行,這會導致并發性能極速下降,因此也不是很常用.

基于上面所有，再聊一聊優化

mysql 優化其實最大限度來說，就本人而言，是索引優化，其次再是語句優化，因為一般別人寫sql工程方面不會有多復雜，一般加上索引就可以解決百分之80的問題，但是如何查看執行計劃，可以通過mybatis的statement 進行攔截校驗，也就是重寫sql。這個是一種辦法還有就是使用執行計劃查看命令explain，看下執行計劃，查看有沒有索引，有沒有走索引，先從索引來說

sql優化

• 在業務密集的SQL當中盡量不采用IN操作符，in是在數據達到1w之后才會走索引··索引不要用

• 關鍵詞 %yue%， 由于yue前面用到了“% 模糊查詢不走索引

• 二者都能使用盡量使用where （與having比較）where 先過濾（數據就少了）再分組

• 避免使用子查詢，如果使用了，同上查看子查詢

• 盡量避免使用select *，返回無用的字段會降低查詢效率

• 盡量避免使用or，會導致數據庫引擎放棄索引進行全表掃描

這幾個搞定之后，加索引，基本就搞定一般了；

然后

當語句執行時間較長時，通過日志的方式進行記錄，這種方式就是慢查詢的日志。

臨時開啟慢查詢日志（如果需要長時間開啟，則需要更改mysql配置文件）
在服務器運行命令

set global slow_query_log = on; set globle log_output = file; set global slow_query_log = off

對于記錄的慢sql進行重點分析一下

然后工程方面

MybatisPlus自定義查詢sql 判斷時間 配置bean

/*** SQL執行效率插件 性能分析插件*/@Bean@Profile({"dev","test"})// 設置 dev test 環境開啟public PerformanceInterceptor performanceInterceptor() {PerformanceInterceptor performanceInterceptor = new PerformanceInterceptor();performanceInterceptor.setFormat(true);//格式化語句//performanceInterceptor.setMaxTime(5);//執行時間超過多少秒會拋出異常return performanceInterceptor;}

參考：https://zhuanlan.zhihu.com/p/27700617

總結

以上是生活随笔為你收集整理的1113123123123的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。