?最近做的公司的項(xiàng)目，主要負(fù)責(zé)和移動端交互后臺，有一個(gè)接口返回時(shí)間7 秒，一個(gè)20 秒；項(xiàng)目結(jié)構(gòu)是springMVC 和hibernate ，hibernate覺得查詢多還可以，但是添加刪除更新多，又是 奪標(biāo)關(guān)聯(lián)，映射，就很慢了；這是慢的一個(gè)小原因；

?現(xiàn)在說一個(gè)接口 ，answer 表? ，錄音表 ，會有很多錄音； 評論表 answer_comment，對錄音的評論，關(guān)聯(lián)字段 answer_id ; 一條錄音有多條評論，

第一個(gè)接口；查錄音answer表， 把 所有沒被評論的分頁查詢出來按時(shí)間排序， 實(shí)現(xiàn)是這樣， 把 所有的common的表 answer_id? 去拿出來，和answer表比較，

以前的sql ： select * from answer a where a.id not in(select b.answer_id from answer b)? and a.....

沒有的查出來，如果數(shù)據(jù)量小，可以接受，現(xiàn)在線上 數(shù)據(jù)，錄音多，評論也多，這種時(shí)間負(fù)責(zé)度 為n? 的平方，就會特別慢，我用exists 替換了in ，不行，加了索引也不行，

解決辦法：answer表加個(gè) 字段是否已 被評論 flag ，先把 線上數(shù)據(jù)用sql更新? update answer a set a.isComment=1 where EXISTS(select 1 from? answer_comment b where b.answer_id=a.id);

?然后程序Java控制，如果有評論，就把那條錄音isComment 更新為1 ，這樣查詢 就是單表查詢，不會有關(guān)聯(lián)了 ，時(shí)間 復(fù)雜度為1 ；sql ：select a from answer a where a.isComment=1;

第二個(gè)接口：返回高分錄音? 同樣是answer 表， answer_Comment , 用戶對錄音的點(diǎn)評 分為四個(gè)維度存在 answer_Comment ,高分錄音是4 個(gè)維度求和 大于3 的算高分；

之前的sql：select *? from answer a ?? group by a.id ? having a.id in (select? c. answer_id? avg(c.1+c.2+c.3+c.4) >3 from answer_Comment c? )??? and a.sum(secounds)>100? 這里也是求和 和in 執(zhí)行時(shí)間很慢

大約20 秒了，當(dāng)我接受這個(gè)項(xiàng)目的時(shí)候，添加索引 或者基本的sql優(yōu)化也回力無天，這里又是 計(jì)算，又是in ;

解決 辦法，還是添加字段，但是這個(gè) 計(jì)算是實(shí)時(shí) 的，多了一條評論， 積分 就會改變 ，這里應(yīng)為 才用了存儲過程，每天晚上去統(tǒng)計(jì)計(jì)算情況在answer表加一個(gè)字段 ， 平均分， 更新后，類似于第一個(gè)接口 ；

?

=====================================================================================================================

?

其實(shí)sql 優(yōu)化那些查詢，網(wǎng)上那些辦法，什么查詢結(jié)果需要的字段啊 ，加索引啊，都是空話，我覺得關(guān)鍵在于表的設(shè)計(jì) ，盡量減少多表交互太多， 當(dāng)然不是單表；

?

轉(zhuǎn)載于:https://www.cnblogs.com/zgghb/p/4655388.html

總結(jié)

以上是生活随笔為你收集整理的关于数据库性能优化小经验的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。