前言
索引加快了檢索的速度，但是卻降低了資料列裡插入、刪除以及修改數值的速度。也就是說，索引降低了許多涉及寫入的操作速度。之所以出現這種情況，是由於寫入一條資料不僅僅是要寫入到資料行，還需要所有的索引都作出相應的改變如更新或是重新編排。mysql在為檢索生成乙個執行方案時候，要仔細對索引進行計算，建立過多的索引對查詢優化程式就加上了更多的工作，而且當你有太多的索引的時候，mysql還有可能無法選出最好的索引來使用。於是在選擇索引的時候，需要採取一些策略。
策略1在選擇索引列的時候，盡量為用搜尋、分類或者分組的資料列編制索引，不要為作為輸出的資料列編制索引。換句話說，最合適有索引的資料列是那些在where字句**現的資料列，在連線字句中給出的資料列、或是在order by或是group by子句**現的資料列。
策略2綜合考慮資料列的維度勢。資料列的維度，等於它所容納的非重複值的個數。
策略3盡量選擇短小的值進行索引
短小的值可以讓比較操作更快完成，加快索引查詢速度。
短小的值可以讓索引的體積更小，減少磁碟i/o活動
短小的鍵值意味著鍵快取裡的索引塊可以容納更多的鍵值，讓mysql可以在記憶體中容納更多的鍵，這樣較少了i/o活動的概率。
innodb儲存引擎採用的聚族索引。所謂的聚族索引就是把資料行和主鍵索引集中儲存在一起，其他的索引都是二級索引，它們儲存著主鍵值和二級索引值。對於二級索引查詢過程是先通過二級索引找到主鍵，然後通過主鍵找到對應的資料。選擇短小的值進行索引，可以減少二級索引佔據的空間。
策略4為字串值的字首新增索引
如果打算給乙個字串列新增索引，盡可能的給出字首長度。
策略5不要建立過多的索引
Java事務設計策略
最近閱讀了infoq上的電子書 之後受益匪淺,單獨花了兩周時間將其翻譯了一下.由於英語只是四級水準,所以翻譯內容中的不足之處也請見諒.附件裡第乙份是翻譯後的文件,第二份是英文原文.下面列出文中映象深刻的幾點 事務模型的分類 list 本地事務模式,管理連線 程式設計式事務模式,程式設計管理jta事務...
軟體架構設計策略
制定軟體架構設計策略 1 全面認識需求。下面的這個圖可以用作全面需求分析圖。功能需求 質量屬性 約束 組織級軟體系統實現的功能 成本，上線時間，業務限制 使用者級軟體系統實現的功能 易用性，效能，持續可用性，魯棒性 使用者的計算機水平有限 開發級軟體系統實現的功能 可擴充套件性，可重用性，可移植性，...
商業Web站點設計策略
相信很大一部分人知道，我們國內的很多web站點設計專案都存在著乙個特點，那就是將設計和製作混為一談。所謂的設計站點，就是簡單的把客戶給的資料圖形化，不考慮任何其他的因素，比如能否讓站點實現預期的商業收益，讓站點真正給使用者提供他們想要的資訊和服務。於是，大量的站點形同虛設，成了白白浪費時間 金錢 人...