mysql的 insert常用方法——插入後返回插入成功後的主鍵
"insert" paramtype=
"object"
>
<
sql>
<
![cdata[
insert
into ucdp_budget_plan
(gmt_create,gmt_modified,biz_date,
status
,name,biz_code,scene_code,lasted_operator,plan_type,bu_info,total,budget_elements,assign_config,notify_time,digest,environment)
values
(current_timestamp
,current_timestamp
,?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,?)]]
>
<
/sql
>
<
![cdata[
insert
into ucdp_budget_plan(gmt_create,gmt_modified,biz_date,
status
,name,biz_code,scene_code,lasted_operator,plan_type,bu_info,total,budget_elements,assign_config,notify_time,digest,environment)
values
(current_timestamp
,current_timestamp
,#bizdate#, #status#,#name#, #bizcode#, #scenecode#, #lastedoperator#, #plantype#,#buinfo#,#total#, #budgetelements#, #assignconfig#, #notifytime#,#digest#,#environment#)
"long" keyproperty=
"id"
type
="post"
>
select last_insert_id(
)<
/selectkey>]]
>
<
/sqlmap>
<
/operation>
上面的方法利用的是mysql的last_insert_id()函式會返回當前連線上次插入記錄的自增主鍵。
public
long
insert
(budgetplanbo budgetplanbo)
public
long
insert
(budgetplanbo budgetplanbo)
catch
(duplicatekeyexception e)
}
public
long
insert
(budgetplanbo budgetplanbo)
", budgetplanbo)
;try
catch
(duplicatekeyexception e)
}
存在兩個問題:
以上語句只是一次建立,在實際專案中乙個介面要進行200+次的批量建立。開發環境沒問題,但在預發環境中批量建立出現了部分成功部分失敗的問題。唯一索引的搜尋,使得本語句變成了一寫多讀的情況。就會導致一直返回0,因為寫連線跟讀連線不是同乙個,解決方法是通過開啟事務,強制使用同一連線進行讀寫。除非一定要獲取插入id的情況,否則不推薦使用事務來獲取插入id。
public
long
insert
(budgetplanbo budgetplanbo)
", budgetplanbo)
;return
this
.ucdpmngtransactiontemplate.
execute
(new
transactioncallback
()catch
(duplicatekeyexception e)
catch
(throwable e)
", json.
tojsonstring
(e))
; transactionstatus.
setrollbackonly()
;throw
newucdpmngexception
(e.getmessage()
);}}
});}
記一次oracle sql調優過程
這裡兩天都在對一條sql進行調優。該sql並不複雜,類似於 select from some view union all select from some table where datetime d1 and datetime d2 and 底層使用ibatis2.1.6 oracle 10g。...
記一次web服務的調優
首先,描述一下環境,簡單的web服務,關鍵日誌寫入kafka,要求qps達到單機10k即可。後面將遇到的問題 解決方案和原理記錄如下 1 記憶體占用過大,雖然 jvm的堆記憶體設為 1g,但程序實際記憶體使用量達到了 12g 解決方案 程式中使用了 kafka new 出kafka producer...
記一次php fpm http502的調優
最近,公司產線幾乎每天都有短暫的http502錯誤,同時nginx會丟擲大量的報錯,報錯內容是no live upstreams while connecting to upstream 網上查詢,這種錯誤可能是php fpm 程序已經全部被占用,沒有空閒的程序來處理多餘的請求,查了一下php fp...