一條sql執行時間特別長，很多時候頁面都直接504 timeout，sql內容大致如下，其中a表的資料有2000w+資料，b表有600w+資料
select
a.*from
awhere
a.user_id =
123and a.id notin(
select
b.pay_record_id as pay_record_id
from
bwhere
b.user_id =
456)
order
by create_time desc
;
於是把每條sql都單獨執行一下，發現速度很快，但是放到一起就很慢，於是就知道問題出在了2個表的關聯條件上了。
於是檢視了 a表的id的字段型別為 int，而b表中pay_record_id是bigint。這就找到原因了，a表和b表的字段型別不匹配，所以導致了a表的全表掃瞄。所以超時！
解決辦法就是為b表的字段進行型別轉換 ，讓它跟a表的字段型別一致，修改後sql如下:
select
a.*from
awhere
a.user_id =
123and a.id notin(
select
-- 把 bigint 轉換為 int
cast(b.pay_record_idas signed)
as pay_record_id
from
bwhere
b.user_id =
456)
order
by create_time desc
;
解決思路：
單獨分析每一條sql執行時間，如果有特別慢的sql那麼先優化單獨的sql，如果單獨執行sql速度很快，那麼問題就應該出現在表管理的條件上，表關聯條件慢一般就是資料型別不匹配：包括 int 跟 bigint不匹配，varchar的字符集不匹配都可能導致全表掃瞄。
IOS swift資料型別不匹配問題
swift的資料運算使用起來感覺比oc要嚴格,oc有時候即使型別不同也可以直接運算,swift則會報錯.例如 let circleview y self.view.center.y cgfloat screen width 0.1 oc screen width 0.1這裡是不用強轉型別的 又如 c...
MySQL資料型別優化
mysql資料型別眾多，選擇正確的資料型別對於獲得高效能至關重要。遵從以下幾條原則有助力做出更好的選擇。1 更小的資料型別。更小的資料型別通常更快，因為它們占用更少的磁碟 記憶體和cpu快取，並且處理時需要的cpu週期也更少。但也要確保自己沒有低估需要的儲存範圍。2 簡單的資料型別。簡單的資料型別通...
MYSQL資料型別優化
mysql支援的資料型別很多，選擇正確的資料型別對於獲得高效能至關重要，不管儲存哪種資料型別，下面幾個簡單原則都有助於我們做出更好的選擇。1 更小的通常更好，更小的資料型別通常更快，因為它們占用更少的磁碟，記憶體和cpu快取，並且處理時需要的cpu週期也更少。但是要確保不會低估要儲存值的範圍 2 簡...