1.大表的資料修改最好分批處理。
1000萬行的記錄表中刪除更新100萬行記錄，一次只刪除或更新5000行資料。每批處理完成後，暫停幾秒中，進行同步處理。
2.如何修改大表的表結構。
對錶的列的字段型別進行修改，改變字段寬度時還是會鎖表，無法解決主從資料庫延遲的問題。
解決辦法：
1.建立乙個新錶。
2.在老表上建立觸發器同步老表資料到新錶。
3.同步老表資料到新錶。
4.刪除老表。
5.將新錶重新命名為老表。
可以使用命令，完成上面的工作：
pt-online-schema-change –alter=」modify c varchar(150) not null default 『』」 –user=root –password=root d=sakia, t=表名 –charset=utf8 –execute
3.優化not in 和 <> 的查詢
例子：select customer_id ,firstname,email from customer where customer_id
not in (select customer_id from payment)
會多次查詢payment 表，如果payment表記錄很多效率將很低。
改寫後的sql
select a.customer_id ,a.firstname,a.email from customer a left join payment b
on a.customer_id=b.customer_id where b.customer_id is null;
4.對彙總表的優化查詢
select count(1) from product_comment where product_id=999;
建立彙總表:
create table product_comment_cnt (product_id ,cnt int);
select sum(cnt) from (
select cnt from product_comment_cnt where product_id=999 union all
select count(1) from product_comment where product_id =999 and timestr>date(now())
) a每天定時更新彙總表，再加上當天的資料。
優化案例 分割槽表場景下的SQL優化
有個表做了分割槽，每天乙個分割槽。該錶上有個查詢，經常只查詢表中某一天資料，但每次都幾乎要掃瞄整個分割槽的所有資料，有什麼辦法進行優化嗎？有乙個大表，每天產生的資料量約100萬，所以就採用表分割槽方案，每天乙個分割槽。下面是該錶的ddl create table t1 id bigint 20 no...
特定場景下代替優化 if else 的方案，好用
1 多個與條件 相信大家都會遇到可能會有多個條件組合的問題 比如有乙個參與熱賣活動贈積分活動，活動狀態 status 預熱中 status 1 進行中 status 2 使用者型別 type 也有分普通使用者 type 1 vip使用者 type 2 規則是 1.在預熱中參與活動，vip使用者贈送 ...
DOM幾個場景的優化場景？
問題 在input的onchange事件中進行實時請求，當輸入框輸入發生改變時就會傳送一次請求。比如輸入react 解決方式 新增防抖功能，設定乙個合理的時間間隔，避免時間在時間間隔內頻繁觸發，同時又能保證輸入後可以看到結果 1 每次value改變，就會發出一次請求 const handlechan...