前段時間，某個深夜，突然接到專案的告警**，專案執行異常，檢視告警資訊是由於專案資料庫cpu使用率接近100%導致的。為此深夜中忙活了一陣，當個教訓，且記錄一次。
現象：服務資料庫cpu使用率接近100%，一直居高不下。
原因：sql語句使用不合理的索引，導致資料庫中大量資料的排序，大資料量的記錄排序消耗盡cpu，出現慢查詢，導致服務告警。
具體分析如下：
select
id, msg_title, msg_type, status, msg_time，.........
from msg
where (
is_deleted = 0
and status = 0
and mall_id = 909942
and importance = 1
and is_latest = 1 )
order by
msg_time desc
limit 0, 1
如上是出現問題的sql語句，相關的輔助日誌顯示，sql的explain執行計畫是先做order by 排序，然後執行where條件篩選，和預期的執行順序不符。預期mysql查詢優化器會先執行where條件做篩選，篩選掉大部分資料後，在執行order by做少量資料的排序。出現該現象的分析認為，查詢語句使用了msg_time欄位索引先做排序（msg_time建有索引）， 全表千萬級別的表資料量排序必然消耗大量的cpu資源，而且大資料量的排序必然出現慢查詢，這才導致cpu消耗居高不下。
改進方式：
分析業務需求後，其實可以使用主鍵id代替msg_time作為order by的字段，問題消除。
記錄一次SQL查詢語句
以前發現比較經典的句子，都是記錄在電腦上，我今天想搬到部落格上，在我看來，寫部落格真的是一件非常頭疼的事，它是內心的一道坎，我必須得跨過它。1 create table t jeff 2 id int notnull 3 vinnumber varchar 255 default null 4 ch...
記錄一次sql優化查詢
場景 關聯查詢，一張主表關聯4張表進行查詢。主表資料量是16萬，其中被關聯的一張表的數量是6萬。遇到頁面響應速度過慢的情況，首先考慮是否是sql查詢緩慢引起的。第一步開啟mysql的慢查詢日誌 網上教程很多，本篇文章不再贅述 第二步分析慢查詢日誌，這裡要說下分析工具。常用的有兩種，一是mysql自帶...
記錄Hive中一次查詢慢的問題
hive查詢問題 快速查詢hive資料倉儲表中的總條數 需要連線hive的元資料 mysql select d.name,t.tbl name,t.tbl id,p.part id,p.part name,a.param value from tbls t left join dbs d on t....