* 所建立的索引最好支援多種過濾條件 *
* 在所建立的索引列上避免多個範圍條件 *
* 過濾資料的同時最好能照顧到排序 *
找到並修復損壞的表 ( corruption )
分為 * 索引損壞 * 和 * 資料損壞 *
check table 來檢查是否發生了表損壞 (myisam友好)
repair table 修復損壞的表 (myisam友好)
innodb 表 alter table t1 engine=innodb; 來重建表.
如果資料損壞了, 恢復備份吧.
維護索引統計資訊
mysql 的查詢優化器會通過兩個api介面 records_in_range() 和 info() 提供的索引值分布資訊, 來決定
如何使用索引.
records_in_range(): 通過向儲存引擎傳入兩個邊界值 來獲取 這個範圍大概有多少條記錄.
myisam 返回精確值: innodb 返回估算值.
info(): 返回各種型別的資料, 索引的基數(每個索引有多少條記錄)等等.
* mysql 優化器使用基於成本的模型, 衡量成本的主要指標就是乙個查詢需要掃瞄多少行. 所以, 如果 mysql 優化器 records_in_range() 和 info() 提供的資訊不準確. 那麼優化器可能做出錯誤的決定.*
analyze table —> 重新生成統計資訊
減少碎片
* 索引的碎片 * 和 * 資料的碎片 *
* 索引的碎片化 * 會降低查詢效率, 尤其是 範圍查詢, 索引覆蓋掃瞄等.
* 資料的碎片 *
* 行碎片: 單條資料行 被儲存在多個地方的多個片段中. (根據 id 去訪問一條資料行, 也會產生影響)
* 行間碎片: 多個資料行之前 不是被順序的儲存在磁碟中. (對全表掃瞄和聚簇索引掃瞄有很大影響影響)
* 剩餘空間碎片: 硬碟上的 『資料頁』 中有大量的空餘空間. (伺服器會讀取大量不需要的資料, 浪費)
myisam 三種情況都會發生, innodb 不會出現短小的行碎片, 會將其合併到乙個片段中.
* optimize table * 來優化表 , 不支援此命令的 儲存引擎可以 alter table t1 engine=< engine >來操作.
高效能JavaScript讀後感 一 載入與執行
當你剛開始寫 的時候肯定有人告訴你，js 的引用應該放在最後面，如果沒人告訴你的話，那麼就當我告訴你了，這是最簡單的辦法 html 當然凡事無絕對，放在後面的引用往往是頁面載入不需要的，先讓看你 的人快速看到頁面先，ps.畢竟他們只是看看 當你按著上面的設定會出現第三種情況，就是當你載入js 的時候...
構建之法讀後感三
今天看了 構建之法 第三章，該章的內容是關於軟體工程師的個人發展，既然決定進入軟工這個行業我們就應該對自身未來的發展有乙個大致的規劃，現在的軟體大多都是由乙個團隊完成所以軟體工程師在發展個人能力的同時也要培養自己的團隊協作能力。在個人發展方面，軟體工程師要積累軟體開發的相關知識，提公升技術能力 積累...
《監控》讀後感
監控 讀後感 監控 更合適被定義為一本偵探 它非常引人入勝地描述了幾起錯綜複雜的案件，描寫得棒極了，以致我夜以繼日地讀完了它，為的是找到事情的真相。它使用了倒序的方式，一開始，作者就用不安的口氣說道 到現在為止，我都無法從那些恐怖中掙脫開來。呵呵，到底是什麼事情呢，這麼勾人？很難為情，但我不得不說，...