起因程式執行資料錯誤需要修復資料
sql思路：以invalidtime排序，更新最新資料的幾個字段，限制條件為objectid必須為backup_am_card_20200603中存在的。其中am_card表是乙個大表（正式環境估計有幾千萬資料，我這是測試環境資料量沒這麼大），backup_am_card_20200603表是乙個小表（備份的錯誤資料的表大概30來條資料）。
現象：這個sql在正式環境執行超過了20分鐘還沒有執行完。
分析：
用plsql分析，耗費33171（標記1），第一步耗費和為2，第二步33163（標記2）耗費和為33163，可以看出來時間大多耗在這裡了，從描述看可以看出來這塊是個全查詢，對應的子查詢為標記3的位置。
時間耗費在分組取第乙個，對am_card分組取第乙個，由於am_card非常大所以這個分組及其慢。
解決思路：
先篩選am_card中符合條件的資料，在進行分組去第乙個。如下圖。執行時間10秒不到。
sql優化處理總匯
1 沒有索引或者沒有用到索引。經常會用到這樣問題這個地方該不該用索引？這個問題等下說先了解下索引。當你新增個索引的時候首先建立乙個索引檔案。一般來說，在where和join中出現的列需要建立索引，但也不完全如此，因為mysql只對 between，in，以及某些時候的like才會使用索引。因為在以萬...
記憶體優化處理
使用分析器，修改洩露的問題 避免循壞引用，dealloc rootviewcontroller block 的self 等引數 確定dealloc 方法按照預期呼叫了 基本上沒什麼好說了，你已經做了你該做的 顯然uikit本身還做了一些其它的你不需要知道的事情，也許是為了優化整個流程，也許是對特定的...
php fpm優化處理
php fpm.conf有兩個至關重要的引數 乙個是 max children 另乙個是 request terminate timeout 我的兩個設定的值乙個是 40 乙個是 900 但是這個值不是通用的，而是需要自己計算的。計算的方式如下 如 果你的伺服器效能足夠好，且寬頻資源足夠充足，php...