由於這個專案一直都是mysql所以寫點mysql的
1.資料儲存引擎的選擇，myisam 和 innodb 的選擇
innodb 一般都會選擇這個，但是如果真的涉及到一些不涉及增刪的表，可以考慮下myisam 該引擎不支援事務，不支援外來鍵，優點就是訪問速度快，如果都是查詢的話，這個儲存引擎可能會使你的效率更高點
2.查詢sql中新增 limit 我們專案組sql規範中都有寫，任何查詢都應該加上 limit ，這麼做有兩個原因：1.防止表中資料過大，導致大量資料一把撈出，導致記憶體溢位，gg 2.在查詢一條資料是加上 limit 1 會時效率更高
3.not exexists 代替 not in not exists 查詢時會走索引，而not in就沒戲了，在資料量比較大的時候尤其能看出顯著的效果。
4.like 關鍵字的使用 『關鍵字%』 不要使用兩側都有%% 這樣也會使索引失效
5.適當的建立索引
《以下都是扯犢子，一點點蛋用，還是別看下面的了》
慢sql核查
select
count(1)
from
t_sr_problem_proces t1,
select
wrkfm_id
from
t_sr_problem_process_modify
group by
wrkfm_id
) t2
where
t1.acpt_time >= '2018-07-31 00:00:00'
and t1.acpt_time <= '2018-08-31 23:59:59'
and t1.tenant_id = '100000'
and t1.prov_code = '00030016'
and t1.wrkfm_id = t2.wrkfm_id
and t1.wrkfm_sts_cd in ('3', '4', '5', '7', '8');
分析：子查詢的結果集t2在與t1表聯合時會走全表掃瞄，且沒有索引。
改造：select
count(distinct t1.wrkfm_id)
from
t_sr_problem_proces t1,
t_sr_problem_process_modify t2
where
t1.acpt_time >= '2018-07-31 00:00:00'
and t1.acpt_time <= '2018-08-31 23:59:59'
and t1.tenant_id = '100000'
and t1.prov_code = '00030016'
and t1.wrkfm_id = t2.wrkfm_id
and t1.wrkfm_sts_cd in ('3', '4', '5', '7', '8');
改造後的sql兩條執行計畫均走索引查詢
select
count(1)
from
t_sr_problem_proces_h_2018 t1,
select
wrkfm_id
from
t_sr_problem_process_modify_his_2018
group by
wrkfm_id
) t2
where
t1.acpt_time >= ?
and t1.acpt_time <= ?
and t1.tenant_id = ?
and t1.prov_code = ?
and t1.wrkfm_id = t2.wrkfm_id
分析：子查詢的結果集t2在與t1表聯合時會走全表掃瞄，且沒有索引。
select
rec_id,
tenant_id,
prov_code,
srv_reqst_type_id,
city_code,
srv_reqst_big_cla_id,
htpoint_srv_reqst_type_nm,
htpoint_srv_reqst_type_full_nm,
op_staff_id,
arge_seqno,
org_brnch_id,
crt_time,
modf_time,
htpoint_srv_type_cd,
batch_num,
valid_flag,
acpt_flag,
big_cla_nm,
ltsz_wrkfm_flag,
eff_time,
invld_time,
front_show_nm
from
t_sr_cfg_hot_srtype
order by
limit ?,?
分析：手動熱點服務請求型別查詢：
1.該sql是簡單的單標查詢，經過排查該xml中的sql語句可以刪除
distinct
2.該sql查詢的字段可以看出，包含主鍵，因此distinct 將毫無意義，如果誤傳的話還會降低該查詢的效能
該查詢是簡單的單錶查詢，經核查 t_sr_cfg_hot_srtype 在配置庫，所有省份共用一張表，該錶主鍵是rec_id，在查詢是rec_id不會由前台傳過來，因此where 子句中不會有 rec_id 導致查詢不會走索引查
改造: 建議對於該錶新增其他列的索引
select
rule_id,
tenant_id,
prov_code,
htpoint_srv_type_cd,
embr_city_flag,
embr_big_cla_flag,
intervalg,
topn,
op_staff_id,
org_brnch_id,
crt_time,
modf_time
from
t_sr_cfg_hot_srtype_rule
where
order by
分析：1.該sql是簡單的單標查詢，經過排查該xml中的sql語句可以刪除distinct
該sql查詢的字段可以看出，包含主鍵，因此distinct 將毫無意義，如果誤傳的話還會降低該查詢的效能
2.該錶位於配置庫，多省共用一張表儲存資料，經查詢該錶僅有主鍵乙個索引，在查詢時不會傳主鍵到where 子句中，因此導致該簡單查詢為全表掃瞄且不走索引，無論哪個省的資料量足夠大都會影響其他省的正常查詢。
改進：建議該錶新增索引
select
dsps_proc_id,
tenant_id,
lg_id,
route_lg_id,
wrkfm_id,
op_type_cd,
fct_no,
fct_nm,
fct_val,
dsps_staff_id,
dsps_org_brnch_id,
crt_time,
modf_time,
prov_code,
element_display_name
from
t_sr_process_detail_his_201808
where
route_lg_id in (?,?,?)
分析：1.排查xml的時候，發現# 沒有新增jdbctype
2.以 t_sr_process_detail_his_201808 為例，該表中除主鍵外 還有在wrkfm_id上有索引，但是針對該sql wrkfm_id 不在where子句中，因此查詢為全表掃面且不走索引
改進：在 route_lg_id 欄位上新增索引
no.6 srpageinfo.selectcfgpagetype
select distinct
from
t_sr_page_info
where
tenant_id = ?
and prov_code = ?
分析：t_sr_page_info位於配置庫，主鍵：page_id 除主鍵外無其他索引
該查詢雖然是簡單查詢，但是在資料量很大的時候，全表掃面會效率極低。
改進：在prov_code 欄位上新增索引
查詢表中索引：
show index from table_name
sql 語句 的一些優化小總結
1.用exists 代替 in 原理 exists 是存在乙個即返回乙個 而in是做全盤掃瞄得出所有條件內的資料 高效 select from member where age 18and exists select x from person where member.name person.na...
關於uboot的一些優化
本人的開發環境是 u boot 1.1.6 版本，fedora 9 虛擬機器的 linux 系統，開發板 cpu為 at9263ek 的板子，以下是本人在試驗過程中總結出來的步驟，1 修改 u boot 1.1.6 common main.c 第269 行udelay 10000 改為udelay ...
關於死鎖的一些SQL
查詢表空間 select tablespace name,file id,file name,round bytes 1024 1024 0 total space from dba data files order by tablespace name 設定表空間大小 alter database...