有關(guān)mysql的一些小技巧
1. 大批量亂序數(shù)據(jù)導(dǎo)入InnoDB很慢如何解決?
InnoDB因?yàn)橹麈I聚集索引的關(guān)系,如果沒(méi)有主鍵或者主鍵非序列的情況下,導(dǎo)入會(huì)越來(lái)越慢,如何快速的遷移數(shù)據(jù)到InnoDB?借助MyISAM的力量 是很靠譜的,先關(guān)閉InnoDB的Buffer Pool,把內(nèi)存空出來(lái),建一張沒(méi)有任何索引的MyISAM表,然后只管插入吧,concurrent_insert=2,在文件末尾并發(fā)插入,速度剛剛 的,插入完成后,ALTER TABLE把索引加上,記得還有ENGINE=InnoDB,就把MyISAM轉(zhuǎn)到InnoDB了,這樣的速度遠(yuǎn)比直接往InnoDB里插亂序數(shù)據(jù)來(lái)得快。
2. 在基于ROW的雙Master復(fù)制下,如何快速大批量訂正?
在A<->B的雙Master結(jié)構(gòu)下,假設(shè)只有一臺(tái)提供服務(wù),這是我們常用的架構(gòu),需要大批量訂正數(shù)據(jù),如何做最快?用存儲(chǔ)過(guò)程一批批提交?這有很多的限制,有時(shí)候并不可以把一條或多條SQL拆成幾段,怎么辦呢?binlog不是很好的工具嘛?! ROW格式的binlog,Slave在應(yīng)用時(shí)是直接使用Handler API,并沒(méi)有走SQL解析,速度非常快,基本上是IO操作了,那么我們可以在備庫(kù)上直接執(zhí)行訂正SQL,產(chǎn)生的ROW binlog傳到主機(jī),就會(huì)很快訂正完,基本上都比寫(xiě)存儲(chǔ)過(guò)程快。
3. ROW格式Replication如何實(shí)現(xiàn)不帶庫(kù)名的replicate-do-db?
雖然MySQL有replicate-do-db這個(gè)參數(shù),但是在ROW格式的binlog下必須使用”db.table”的方式才能生效,USE對(duì)ROW格式是無(wú)效的?,F(xiàn)在我有一個(gè)Instance,只需要復(fù)制Master的某幾個(gè)庫(kù),但是是ROW格式,SQL都 沒(méi)有使用db前綴,怎么辦?可以這么做,把主庫(kù)需要的庫(kù)導(dǎo)出來(lái),不需要的庫(kù)導(dǎo)出結(jié)構(gòu)即可,在Slave導(dǎo)入這些數(shù)據(jù)及結(jié)構(gòu),配置skip-slave- errors=all,這樣Master復(fù)制過(guò)來(lái)的binlog,只要發(fā)現(xiàn)有庫(kù)有表結(jié)構(gòu),就不會(huì)報(bào)找不到表,就不會(huì)阻塞復(fù)制,但是 UPDATE/DELETE過(guò)來(lái)沒(méi)有數(shù)據(jù)也會(huì)被跳過(guò)錯(cuò)誤,間接的實(shí)現(xiàn)了replicate-do-db。
4. A<–>B–>C–>D結(jié)構(gòu)切換到A<–>B, C<–>D結(jié)構(gòu)出現(xiàn)Slave_lag一直增常如何避免?
這種情況常見(jiàn)與一個(gè)雙Master集群分離出一套雙Master集群,例如從原集群分離一部分庫(kù)。過(guò)快的切換B–>C到C<–>D容易導(dǎo)致主備出現(xiàn)slave_lag,并且一直增長(zhǎng),原因在于A<–>B集群產(chǎn)生的SQL,隨同server_id帶到了C–>D這個(gè)M-S中,當(dāng)A,B產(chǎn)生的SQL在C,D還沒(méi)消化完成就CHANGE MASTER為C<–>D時(shí),會(huì)導(dǎo)致這寫(xiě)SQL在C,D之間來(lái)回傳輸,因?yàn)镃,D都認(rèn)為這個(gè)SQL不是自己產(chǎn)生的,因而不銷(xiāo)毀,自己執(zhí)行后寫(xiě)入binlog,于是Slave_Lag就一直增長(zhǎng)。
避免的方法很簡(jiǎn)單,部分寫(xiě)切到C后,先斷開(kāi)B–>C的復(fù)制,等一會(huì),看D上已經(jīng)沒(méi)有Slave_Lag了,再CHANGE MASTER為C<–>D,這樣A,B傳過(guò)來(lái)的SQL都消化完了。
5. 表中存在很多重復(fù)數(shù)據(jù)時(shí),如何刪除這些重復(fù)數(shù)據(jù)最快?
在需要給表中某些字段加唯一索引時(shí),而字段中又存在需要重復(fù)清理數(shù)據(jù)的問(wèn)題,不少DBA都應(yīng)該遇到過(guò)。一般在處理時(shí)總是想在數(shù)據(jù)庫(kù)中只保留一條,其他的刪除,但是這樣的SQL寫(xiě)出來(lái)總是效率不高,怎么辦?其實(shí)可以轉(zhuǎn)換思路,把重復(fù)的都選出一條出來(lái),存到一張臨時(shí)表,然后刪除原表中所有存在重復(fù)的,再把臨時(shí)表的數(shù)據(jù)庫(kù)全部插入原庫(kù),這是比較通用并且高效的做法。
相關(guān)文章
LEFT JOIN關(guān)聯(lián)表中ON,WHERE后面跟條件的區(qū)別
本文主要介紹了LEFT JOIN關(guān)聯(lián)表中ON,WHERE后面跟條件的區(qū)別,文中通過(guò)示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-01-01MySQL性能優(yōu)化之max_connections配置參數(shù)淺析
這篇文章主要介紹了MySQL性能優(yōu)化之max_connections配置參數(shù)淺析,本文著重講解了3種配置max_connections參數(shù)的方法,需要的朋友可以參考下2014-07-07MySQL為id選擇合適的數(shù)據(jù)類(lèi)型
為 id 列選擇一個(gè)好的數(shù)據(jù)類(lèi)型非常重要,id 列會(huì)經(jīng)常用于做比較(例如聯(lián)合查詢(xún)的條件),以及用于查找其他列。而且,id 也經(jīng)常用于外鍵。因此,id 列的數(shù)據(jù)類(lèi)型不僅僅關(guān)系自身數(shù)據(jù)表,也關(guān)系到與之關(guān)聯(lián)的其他數(shù)據(jù)表。因此,id 用何種數(shù)據(jù)類(lèi)型就顯得十分重要2021-06-06MySQL服務(wù)器進(jìn)程CPU占用100%的解決方法
早上幫朋友一臺(tái)服務(wù)器解決了 Mysql cpu 占用 100% 的問(wèn)題。稍整理了一下,將經(jīng)驗(yàn)記錄在這篇文章里。2010-12-12命令行模式下備份、還原 MySQL 數(shù)據(jù)庫(kù)的語(yǔ)句小結(jié)
為了安全起見(jiàn),需要經(jīng)常對(duì)數(shù)據(jù)庫(kù)作備份,或者還原,學(xué)會(huì)在命令行模式下備份、還原數(shù)據(jù)庫(kù),還是很有必要2012-11-11

MySQL中的聚合查詢(xún)和聯(lián)合查詢(xún)操作代碼

MySQL存儲(chǔ)過(guò)程和函數(shù)的操作(十二)