本周同步一張歷史數(shù)據(jù)（大約1億）表入ES，1000條為一個批次，最開始時按照表的創(chuàng)建時間（有索引）以天為單位進行的數(shù)據(jù)同步，在同步的過程中聯(lián)系DBA老師查看數(shù)據(jù)庫負載情況，最開始同步時CPU還算穩(wěn)定，但是越到后面，CPU就開始飆升的非常高，甚至達到了90%以上，這時候其實出現(xiàn)了MySQL的深分頁問題，導致大量的慢SQL，如下圖：
數(shù)據(jù)庫CPU監(jiān)控
優(yōu)化前sql為：
-- 以創(chuàng)建時間進行范圍查詢
select * from table where create_time>=#{startDate} and create_time <=#{startDate} order by id asc limit 900000,1000;
以上sql不僅導致CPU飆升，同時效率比較低，耗時較長，存在回表問題，于是將上面的sql進行優(yōu)化，拆分為以下2個sql來處理，sql如下：
-- 獲取范圍查詢的結(jié)束主鍵ID（endID）
select id from table where id>=#{startID} order by id asc limit 1000,1;
-- 以主鍵進行范圍查詢
select * from table where id>=#{startID} and id<#{endID}
優(yōu)化完之后數(shù)據(jù)庫CPU負載正常，同步時間降為1.5小時（分8個線程）完成。
