這幾天都在看一個性能調(diào)優(yōu)的存儲過程，該存儲過程在客戶生產(chǎn)環(huán)境（數(shù)據(jù)庫為mysql 5.1 ）的運行時間為30到40多分鐘，客戶的要求是提高
該存儲過程的實現(xiàn)：
1.兩個表的查詢（由于業(yè)務(wù)需要，還涉及到該表的子查詢），分別插入到臨時表；兩個表的數(shù)據(jù)分別為310W+，120W
2. ?中間還需要做一些處理，將臨時表的數(shù)據(jù)group by插入到另一個臨時表；
3.最后將臨時表的數(shù)據(jù)group by插入到一張正式表，插入的數(shù)據(jù)140W+
接著這幾天就在優(yōu)化性能的路上越走越遠，嘗盡了各種方法，也嘗到了各種苦頭。
圖片發(fā)自App
各種各樣的嘗試：
一、我感覺這實現(xiàn)的邏輯有點復(fù)雜，然后按照我的想法把實現(xiàn)簡化了。然而性能并沒有得到改善。因為我的實現(xiàn)是把大數(shù)據(jù)量提到了前面，而后面的操作還得爭對這部分大數(shù)據(jù)量進行操作，比如group by。所以雖然我的實現(xiàn)在邏輯上簡化了，但是性能并沒有提升。
二、根據(jù)不同的邏輯標(biāo)識，創(chuàng)建了兩套臨時表，這樣一張表的數(shù)據(jù)量就不會那么大，希望給后面的操作減少些壓力。還是以失敗告終。原因是因為邏輯標(biāo)識的設(shè)置，所有都是走的一套邏輯，第二套邏輯根本就只是走過過場，不會真正去查那百萬數(shù)據(jù)的表，所以壓力還是在那300多萬的表。
三、使用預(yù)處理語句。其實對預(yù)處理語句的機制不是太明白，只是聽說預(yù)處理的效率更高。性能還是沒提升，大概是因為并沒有太多相似的查詢或插入吧。嗯，不是太明白預(yù)處理機制。
四、將子查詢拿掉，先用臨時表保存這部分?jǐn)?shù)據(jù)。這樣那300多萬數(shù)據(jù)的表還是得查兩次，沒啥性能提升。
五、將臨時表的引擎由myisam改為memory，數(shù)據(jù)庫的全局變量max_heap_table_size，tmp_table_size也設(shè)置為了1000M，同生產(chǎn)環(huán)境。結(jié)果還是報
The?table?'tmp_item_bu_parter_price'?is?full
，所以說數(shù)據(jù)量太大，導(dǎo)致內(nèi)存撐爆？
六、也是在邏輯上走不同分支，結(jié)果發(fā)現(xiàn)走的都是同一個邏輯。這個有點虧，之前在這方面考慮的時間也挺長，沒有先去查明客戶的設(shè)置。
七、多線程。由于存儲過程中使用了insert into …select…的句式，而且where條件未中索引，所以造成了全表鎖。而多線程的測試結(jié)果無疑就是鎖表了，有些數(shù)據(jù)執(zhí)行失敗。
八、在邏輯上不以全量的方式插入，而是增量，可是那些已存在的數(shù)據(jù)還是得更新啊。所以性能應(yīng)該差不多。
性能主要耗在了百萬數(shù)據(jù)的插入。現(xiàn)在完全是處于沒轍的狀態(tài)，不知道如何處理。
【相關(guān)推薦】
