每日一劑—mysql事務鎖 & git reflog

查找mysql事務鎖

• 查看事務和鎖的信息

  show engine innodb status;

• explain內容解析

  mysql> explain select * from t where cell="111111111111";
  +----+-------------+-------+-------+---------------+------+---------+-------+------+-------------+
  | id | select_type | table | type  | possible_keys | key  | key_len | ref   | rows | Extra       |
  +----+-------------+-------+-------+---------------+------+---------+-------+------+-------------+
  |  1 | SIMPLE      | t     | const | cell          | cell | 83      | const |    1 | Using index |
  +----+-------------+-------+-------+---------------+------+---------+-------+------+-------------+
  1 row in set (0.00 sec)

  • select_type：SIMPLE，這是一個簡單類型的SQL語句，不含子查詢或者UNION。

  • type：index，訪問類型，即找到所需數據使用的遍歷方式，潛在的方式：

    • ALL（Full Table Scan）：全表掃描；
    • index：走索引的全表掃描；
    • range：命中where子句的範圍索引掃描；
    • ref/eq_ref：非惟一索引/惟一索引單值掃描；
    • const/system：常量掃描；
    • NULL：不用訪問表；

    上述掃描方式，ALL最慢，逐步變快，NULL最快。

  • possible_keys：NULL，可能在哪一個索引找到記錄。

  • key：PRIMARY，實際使用索引。(畫外音：使用PK進行的全表掃描。)

  • ref：NULL，哪些列，或者常量用於查找索引上的值。

  • rows：1，找到所需記錄，預估須要讀取的行數。

git-reflog

reflog 是一個很是實用的命令，你可使用這個命令去找回無心間刪除的代碼，或者去掉一些剛剛添加的卻把倉庫裏的代碼弄壞的內容。同時也能夠拯救一下失敗的 merge，或者僅僅是爲了回退到以前的版本。

• 情景1：我剛恰好像搞錯了一個很重要的東西，可是 git 有個神奇的時間機器能幫我復原！

  $ git reflog
  # reflog 能夠查看在全部分支上所作的所有改動
  # 每個改動都會有一個編號 HEAD@(index)
  # 找到問題所在
  
  $ git reset HEAD@(index)
  # git 神奇的時間機器，將代碼重置到指定位置

• 情景2：我 commit 完纔想起來還有一處小地方要修改！

  # 先作好修改
  $ git add . # or add 相關文件
  $ git commit --amend
  # 而後選擇要不要保留或者更高 commit message
  # 如今你的 commit 已經包含最新的修改內容

  當我 commit 完而後跑測試的時候，常常忽然發現忘了在等於號前面加空格。雖然能夠把修改過的代碼再從新 commit 一下，而後 rebase -i 將兩次揉在一塊兒，不過上面的方法會比較快。

• 情景3：我要改一下上一個 commit message！

  $ git commit -amend 
  # 而後能夠更改 commit message

  當大家組對 commit message 有格式要求時，或者當你忘了中英文間要加空格，這個命令能救你狗命。

• 情景4：我不當心把本應在新分支上的內容commit 到 master 了！

  # 先以現有 master 的狀態建立一個新的分支
  $ git branch some-new-branch-name
  # 移除錯誤的 commit
  $ git reset HEAD~ --head
  
  $ git checkout some-new-branch-name
  # 如今的分支就含有全部你所須要的東西了

  注意： 這個指令必須在錯誤的 commit 後直接執行，若是你已經試了其餘的方式，你可能就須要用 git reset HEAD@{number} 來代替 HEAD~ 了。

• 情景5： 我不當心 commit 到錯誤的分支上了！

  # 撤回上一次 commit 可是保留改動
  $ git reset HEAD~ --soft
  $ git stash
  
  # 將改動提交到正確的分支
  $ git checkout name-of-the-correct-branch
  $ git stash pop
  $ git add . # or add individual files
  $ git commit -m "提交信息"
  # 如今的你改動已經成功 commit 到正確的分支上了

  也有不少人推薦了 cherry-pick 的解決方案，因此選哪一個就看你心情了。

  $ git checkout name-of-the-correct-branch
  
  # 將改動從錯誤的分支上摘取下來放到正確的分支上
  $ git cherry-pick name-of-the-wrong-branch
  
  # 而後再錯誤的分支上刪除相應的改動
  $ git checkout name-of-the-wrong-branch
  $ git reset HEAD~ --hard

• 情景6：我執行了 diff 可是啥也沒出現

  $ git diff --staged

  Git 不會給經過 add 加入到 staging 區域裏面的文件作 diff ，除非你加了 --staged 的標籤，別懷疑了這是一個 feature 不是一個 bug，固然對於第一次碰到這個問題的人來講仍是有些很差理解的。

  $ git checkout name-of-the-correct-branch
  
  # 將改動從錯誤的分支上取下來放到正確的分支上
  $ git cherry-pick name-of-the-wrong-branch
  
  # 而後再錯誤的分支上刪除相應的改動
  $ git checkout name-of-the-wrong-branch
  $ git reset HEAD~ --hard