之前工作和mysql強相關，在進一步了解mysql以後，覺得資料庫很牛，水很深。不只是因為資料庫對我來說是黑盒，更因為資料庫對我來說很難成為白盒。一直一來有稍微不爽就看原始碼的習慣，但mysql原始碼，呵呵，演算法、結構設計甚至**量和其他很多經典原始碼都不是乙個量級的。以我現在的能力，寫關於mysql的部落格不過就是堆砌事實，提出疑問，逐步找答案罷了。
千里之行始於足下，就從本文開始，先列舉工作中的問題。
當然，所列舉的潛在的正反面因素還和mysql版本有關。後面對此不再宣告。
1.用儲存過程防注入
背景：為了防注入公司決定所有mysql互動都採用框架自帶的儲存過程。
正思：很多語言框架都支援儲存過程，使得專案編碼風格統一不易出錯；儲存過程解析一次反覆使用，降低代價；每次呼叫相同的過程傳送的資料較少；安全，很多情況下安全第一；
2.外來鍵的使用
背景：網際網路行業流傳甚廣的說法「千萬別用外來鍵」。
正思：只有外來鍵才能真正保證資料的一致性；外來鍵mysql自動建立索引，小索引可以常駐記憶體，對應的b+樹樹高增加得慢，代價相對較小；
反思：可以從業務端去保證某種資料一致性，看業務複雜度和對不一致的容忍程度；外來鍵有額外的合法性校驗代價；
3.主鍵用自增主鍵？
背景：主鍵是否應該帶應用資訊？比如對於一般web應用記錄使用者的登入情況，每個使用者登入一次建立一條記錄；業務場景是匯出乙個id的使用者最近一百次上線時間。
正思：自增主鍵錶小緊湊；沒有中間插入，寫入區域集中，寫硬碟有利；
反思：以使用者id+登入時間戳作為主鍵，插入常發生在表內部，儲存也不緊湊；但是同一使用者的資訊都放到了一起，區域性性好，如果用自增主鍵做id對乙個上線時間間隔很大的使用者一百次上線時間可能導致查詢一百個不同的mysql頁；
4.查詢快取開不開，開多少
背景：對於某一類具體的業務，是否從mysql層次開查詢快取？快取開多大？其實就是引數調優。
反思：對於論壇性質的，看兩貼就回一次那種覺得快取可能可以關了（這種說法好無力感），不過真得看業務和測試。
5.連表查詢還是業務方取資料來自己join
背景：網際網路行業流傳甚廣的說法「千萬別連表查詢」。比如a表是作者表，b是書表，c表是作者id和書名id表，已知幾個作者，要找出這些作者的書名。
正思：連表查編碼簡單；連表查網路流量小因為只返回有用的結果；
反思：讀a表查id，讀c表查書名id，讀b表查書名，這樣mysql只用簡單的取和返回，把可能比較耗時的join實際操作給省掉了；實際業務操作機器可以無限擴充；
備註：這個我最是無語，當然也聽到得最多，如果join都沒優化好mysql也該禁止這種語法了。
6.「點讚」表設計：聯合主鍵和redis
背景：乙個使用者id只能對一篇文章id點讚一次。點讚次數較多，設計方案和表。讀方案都是從mysql讀，至於用不用redis快取或本地快取另算；寫方案一mysql表文章id+使用者id為聯合主鍵，innodb_flush_log_at_trx_commit設為0，定期刷回硬碟；方案二把點讚事件寫入redis，點讚顯示前端渲染，之後定期（或者由下一次點讚激發）把這些事件持久化到mysql。這是實際工作遇到的問題，找了下有點類似於的討論。
問題二：redis方案已經有了丟失點讚的風險，那麼把這種風險轉給mysql，讓mysql自己不是條條寫硬碟。redis方案最終還是要持久化到mysql的，只是「刷」的頻率和前台寫的可以不一致。問題最終大約等於，純記憶體寫的mysql能抗住多少壓力？
工作中的工具羅列
svn git 程式版本控制 qttabbar 資料夾像網頁一樣開啟 anaconda3 python整合 ditto 增強複製貼上 emeditor professional 大檔案開啟 eyefoo3 護眼工具 pycharm 2.7.3 python ide securecrtportable...
工作中相關概念整理
boss business operations support system客戶費用及訂購關係管理 pboss product business operation support system，產品運營支撐系統 cboss center boss 一級boss介面系統 esop enterpri...
工作中碰到的乙個問題（cookie相關）
今天上線了乙個api，6臺機器做的集群。api的第一步是讀取cookie，判斷使用者是否登入。例如，線上伺服器分別是 10.255.242.1 10.255.242.2 10.255.242.3 10.255.242.4 10.255.242.5 10.255.242.6，api位址是 mlserv...