MYSQL大表加索引的實(shí)現(xiàn)
起因是這樣的,有一張表存在慢sql,查詢(xún)耗時(shí)最多達(dá)到12s,定位問(wèn)題后發(fā)現(xiàn)是由于全表掃描導(dǎo)致,需要對(duì)字段增加索引,但是表的數(shù)據(jù)量600多萬(wàn)有些大,網(wǎng)上很多都說(shuō)對(duì)大表增加索引可能會(huì)導(dǎo)致鎖表,查閱了一些資料,可以說(shuō)網(wǎng)上說(shuō)了很多,但是都很籠統(tǒng),聽(tīng)別人說(shuō)不如自己去驗(yàn)證,于是開(kāi)啟了驗(yàn)證之旅
首先新建一張表test_page1
CREATE TABLE `test_page1` ( `id` int(11) NULL, `username` int(252) not NULL, `password` int(252) NULL, `create_time` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci not NULL , `update_time` datetime(0) NULL DEFAULT NULL, PRIMARY KEY (`create_time`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 1000001 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
第二步,像表中干他個(gè)600w條數(shù)據(jù)這一步網(wǎng)上有很多教程,有通過(guò)sql直接在mysql客戶(hù)端插入數(shù)據(jù),還有通過(guò)代碼插入數(shù)據(jù)的,最初為了方便,我是想再mysql客戶(hù)端直接通過(guò)存儲(chǔ)過(guò)程插入數(shù)據(jù),但是插入速度十分感人
果斷放棄,畢竟600w條,不想等到猴年馬月,于是就選擇用代碼的方式插入,其實(shí)就是多費(fèi)了一些力氣而已,上代碼,開(kāi)整
public class Connect { // 導(dǎo)入驅(qū)動(dòng)jar包或添加Maven依賴(lài)(這里使用的是Maven,Maven依賴(lài)代碼附在文末) static { try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } } // 獲取數(shù)據(jù)庫(kù)連接對(duì)象 public static Connection getConn() { Connection conn = null; try { // rewriteBatchedStatements=true,一次插入多條數(shù)據(jù),只插入一次 conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/xxx?rewriteBatchedStatements=true", "root", "xxx"); } catch (SQLException throwables) { throwables.printStackTrace(); } return conn; } // 釋放資源 public static void closeAll(AutoCloseable... autoCloseables) { for (AutoCloseable autoCloseable : autoCloseables) { if (autoCloseable != null) { try { autoCloseable.close(); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } }
public class InsertData { private static ThreadPoolExecutor getDefaultThreadPool() { ThreadPoolExecutor result = new ThreadPoolExecutor(0, 1000, 1, TimeUnit.SECONDS, new SynchronousQueue<>()); result.setThreadFactory(new ThreadFactory() { @Override public Thread newThread(Runnable r) { return new Thread(r, "deterministic runner thread"); } }); return result; } /* 因?yàn)閿?shù)據(jù)庫(kù)的處理速度是非常驚人的 單次吞吐量很大 執(zhí)行效率極高 addBatch()把若干sql語(yǔ)句裝載到一起,然后一次送到數(shù)據(jù)庫(kù)執(zhí)行,執(zhí)行需要很短的時(shí)間 而preparedStatement.executeUpdate() 是一條一條發(fā)往數(shù)據(jù)庫(kù)執(zhí)行的 時(shí)間都消耗在數(shù)據(jù)庫(kù)連接的傳輸上面*/ public static void main(String[] args) { for (int j = 0; j < 100; j++) { long start = System.currentTimeMillis(); // 獲取系統(tǒng)當(dāng)前時(shí)間,方法開(kāi)始執(zhí)行前記錄 Connection conn = Connect.getConn(); // 調(diào)用剛剛寫(xiě)好的用于獲取連接數(shù)據(jù)庫(kù)對(duì)象的靜態(tài)工具類(lèi) String sql = "insert into test_page1 values(null,?,?,?,NOW())"; // 要執(zhí)行的sql語(yǔ)句 PreparedStatement ps = null; getDefaultThreadPool().execute(() -> { try { PreparedStatement finalPs = conn.prepareStatement(sql); // 不斷產(chǎn)生sql for (int i = 0; i < 20000; i++) { finalPs.setString(1, Math.ceil(Math.random() * 1000000) + ""); finalPs.setString(2, Math.ceil(Math.random() * 1000000) + ""); finalPs.setString(3, UUID.randomUUID().toString()); // UUID該類(lèi)用于隨機(jī)生成一串不會(huì)重復(fù)的字符串 finalPs.addBatch(); // 將一組參數(shù)添加到此 PreparedStatement 對(duì)象的批處理命令中。 } int[] ints = new int[0];// 將一批命令提交給數(shù)據(jù)庫(kù)來(lái)執(zhí)行,如果全部命令執(zhí)行成功,則返回更新計(jì)數(shù)組成的數(shù)組。 ints = finalPs.executeBatch(); // 如果數(shù)組長(zhǎng)度不為0,則說(shuō)明sql語(yǔ)句成功執(zhí)行,即數(shù)據(jù)添加成功! if (ints.length > 0) { System.out.println("數(shù)據(jù)添加成功??!"); } } catch (SQLException e) { throw new RuntimeException(e); }finally { Connect.closeAll(conn, ps); // 調(diào)用剛剛寫(xiě)好的靜態(tài)工具類(lèi)釋放資源 } }); long end = System.currentTimeMillis(); // 再次獲取系統(tǒng)時(shí)間 System.out.println("所用時(shí)長(zhǎng):" + (end - start) / 1000 + "秒"); // 兩個(gè)時(shí)間相減即為方法執(zhí)行所用時(shí)長(zhǎng) } } }
代碼之所以快,很大的原因是由與代碼開(kāi)啟了多線程,異步插入,但在實(shí)際執(zhí)行過(guò)程中,也會(huì)出現(xiàn)問(wèn)題,比如把插入的數(shù)據(jù)量搞太大導(dǎo)致了OOM,這個(gè)可以修改本地的JVM,另一種就是同時(shí)插入太多,數(shù)據(jù)庫(kù)連接不夠了,導(dǎo)致報(bào)錯(cuò),但這都不是重點(diǎn),因?yàn)槲覀兊闹攸c(diǎn)是大表加索引。代碼執(zhí)行后20分鐘內(nèi),插入了600w條數(shù)據(jù)。
這時(shí)候就開(kāi)始我們的驗(yàn)證表演了。
首先,說(shuō)一下網(wǎng)上描述的大表加索引會(huì)出現(xiàn)的問(wèn)題
- 如果在執(zhí)行事務(wù)的時(shí)候,如果存在目標(biāo)表的慢sql,這時(shí)對(duì)目標(biāo)表增加索引,會(huì)導(dǎo)致目標(biāo)表被鎖,進(jìn)入Waiting for table metadata lock狀態(tài),進(jìn)入Waiting for table metadata lock狀態(tài)后不能讀也不能寫(xiě)
- 加索引屬于DDL操作,DDL操作執(zhí)行的時(shí)候,會(huì)對(duì)表加鎖
然后開(kāi)始我的嘗試先對(duì)表加個(gè)索引,用時(shí)15.19s
alter table test_page1 add index create_time_index(create_time)
然后我們開(kāi)啟事務(wù),并對(duì)該表執(zhí)行個(gè)慢查詢(xún),并對(duì)表新建一個(gè)索引
BEGIN; select * from test_page1 where username = 852;
alter table test_page1 add index create_time_index(create_time)
這個(gè)慢查詢(xún)有8s,足夠出現(xiàn)問(wèn)題了,很有信心
然而,并沒(méi)有出現(xiàn)期望的結(jié)果,涼涼,難道網(wǎng)上說(shuō)的都是假的,本身不存在這種情況,苦思之下,似乎找到問(wèn)題我是通過(guò)dbveaer來(lái)執(zhí)行的sql,同事執(zhí)行兩個(gè)sql是在兩個(gè)tab頁(yè)上執(zhí)行,會(huì)不會(huì)是雖然在dbveaer的兩個(gè)tab頁(yè)同時(shí)執(zhí)行,但是dbveaer還是一個(gè)一個(gè)排隊(duì)執(zhí)行的sql呢?我想大概率是這樣
我又通過(guò)dbeaver新建一個(gè)數(shù)據(jù)庫(kù)連接,讓開(kāi)啟事務(wù),并對(duì)該表執(zhí)行個(gè)慢查詢(xún)和對(duì)表增加索引在兩個(gè)連接執(zhí)行,這時(shí)執(zhí)行show processlist
命令,終于復(fù)現(xiàn)了
加索引命令的進(jìn)程進(jìn)入了Waiting for table metadata lock
狀態(tài)網(wǎng)上說(shuō)Waiting for table metadata lock
狀態(tài)后不能讀也不能寫(xiě),是不是這樣呢?,來(lái)執(zhí)行下查詢(xún),暢通無(wú)阻,所以說(shuō)網(wǎng)上是錯(cuò)誤的,是可以讀的,那能不能寫(xiě)呢,我們執(zhí)行下sql
insert into test_page1(id,username,password,create_time,update_time) values(null,1,2,'6144423733',NOW());
報(bào)錯(cuò)了,死鎖了Deadlock found when trying to get lock; try restarting transaction
,這就驗(yàn)證了無(wú)法進(jìn)行寫(xiě)操作
那Waiting for table metadata lock
狀態(tài)會(huì)持續(xù)到什么時(shí)候呢,在驗(yàn)證過(guò)程中,發(fā)現(xiàn)了兩種方式第一種,事務(wù)提交后,鎖狀態(tài)取消第二種,這種比較神奇,就是剛剛操作過(guò)的,對(duì)表進(jìn)行插入操作,這個(gè)時(shí)候會(huì)報(bào)錯(cuò),但是報(bào)錯(cuò)后,mysql會(huì)自動(dòng)殺掉事務(wù)進(jìn)程并解鎖(這真的很神奇),但是事實(shí)就是這樣,很糟心。
還有另外一個(gè)點(diǎn)要驗(yàn)證就是加索引屬于DDL
操作,DDL
操作執(zhí)行的時(shí)候,會(huì)對(duì)表加鎖,之前我理解錯(cuò)了,以為加鎖是表鎖,會(huì)鎖表的數(shù)據(jù),但是執(zhí)行ddl操作時(shí)是不會(huì)組織數(shù)據(jù)的寫(xiě)入的,但是另一個(gè)連接去執(zhí)行DDL
操作會(huì)進(jìn)入等待狀態(tài),這就是多,DDL
操作的確會(huì)加鎖,但是他鎖的不是數(shù)據(jù)而是表結(jié)構(gòu)。
經(jīng)過(guò)一番蠻長(zhǎng)的論證,終于驗(yàn)證了什么情況下加索引會(huì)鎖表,為什么有時(shí)候加索引時(shí)間會(huì)很長(zhǎng),加字段時(shí)間會(huì)很長(zhǎng),所以,大家加索引最好選擇選擇在一個(gè)業(yè)務(wù)低峰期加,另外,要注意優(yōu)化系統(tǒng),減少系統(tǒng)中慢sql的出現(xiàn),這樣會(huì)降低鎖表的可能性。
另外如果表被鎖住,處于Waiting for table metadata lock
狀態(tài),這時(shí)候我們也可以通過(guò)殺掉線程id的方式來(lái)解鎖,執(zhí)行show processlist
命令,找到線程id,執(zhí)行kill +id,也能完成解鎖。
后記
通過(guò)自己實(shí)際驗(yàn)證,發(fā)現(xiàn)網(wǎng)上說(shuō)的大部分是正確的,但是沒(méi)有那么細(xì)致,比如解鎖的條件是什么,怎么解鎖,鎖表是鎖表結(jié)果還是鎖數(shù)據(jù),實(shí)際驗(yàn)證之后得到了很多收獲,所以技術(shù)還是要深挖
到此這篇關(guān)于MYSQL大表加索引的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)MYSQL大表加索引內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MySQL 5.5.x my.cnf參數(shù)配置優(yōu)化詳解
今天正好看到一篇有關(guān)my.cnf優(yōu)化的總結(jié),雖然還沒(méi)經(jīng)過(guò)我自己的實(shí)踐檢驗(yàn),但從文章內(nèi)容來(lái)說(shuō)已經(jīng)寫(xiě)的很詳細(xì)了(當(dāng)然,事實(shí)上下面這篇文章很多地方只是翻譯了my.cnf原始配置文件的說(shuō)明,呵呵),所以特地轉(zhuǎn)載收藏一下2015-08-08centos7下mysqldump定時(shí)備份數(shù)據(jù)庫(kù)的方法實(shí)現(xiàn)
MySQL Dump是MySQL提供的方便導(dǎo)出數(shù)據(jù)庫(kù)數(shù)據(jù)的工具,本文主要介紹了centos7下mysqldump定時(shí)備份數(shù)據(jù)庫(kù)的方法實(shí)現(xiàn),感興趣的可以了解一下2023-08-08MySQL之解決字符串?dāng)?shù)字的排序失效問(wèn)題
這篇文章主要介紹了MySQL之解決字符串?dāng)?shù)字的排序失效問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-08-08MySql閃退和服務(wù)無(wú)法啟動(dòng)的解決方法
今天小編就為大家分享一篇關(guān)于MySql閃退和服務(wù)無(wú)法啟動(dòng)的解決方法,小編覺(jué)得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來(lái)看看吧2019-02-02Mysql如何實(shí)現(xiàn)不存在則插入,存在則更新
這篇文章主要介紹了Mysql如何實(shí)現(xiàn)不存在則插入,存在則更新,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-03-03通過(guò)SQL語(yǔ)句來(lái)備份,還原數(shù)據(jù)庫(kù)
這里僅僅用到了一種方式而已,把數(shù)據(jù)庫(kù)文件備份到磁盤(pán)然后在恢復(fù).2010-02-02