索引的使用？正確規(guī)則1、表的主鍵、外鍵必須有索引；2、數(shù)據(jù)量達(dá)到300的表估計(jì)有索引；3、每天都與其他表并且直接連接的表，在連接上字段上肯定確立索引；4、你經(jīng)常再次出現(xiàn)在Where子句中的字段，特別是

索引的使用？

正確規(guī)則

1、表的主鍵、外鍵必須有索引；

2、數(shù)據(jù)量達(dá)到300的表估計(jì)有索引；

3、每天都與其他表并且直接連接的表，在連接上字段上肯定確立索引；

4、你經(jīng)常再次出現(xiàn)在Where子句中的字段，特別是大表的字段，估計(jì)建立起索引；

5、索引估計(jì)建在中,選擇性高的字段上；

6、索引肯定建在小字段上，相對于大的文本字段甚至還超長字段，最好不要建索引；

7、純索引的建立需要通過仔細(xì)思考；最好就是考慮用單字段索引不用：

真確選擇復(fù)合索引中的主列字段，好象是你選擇性比較好的字段；

純索引的幾個(gè)字段如何確定你經(jīng)常而以AND再次出現(xiàn)在Where子句中？單字段網(wǎng)站查詢有無屈指可數(shù)甚至還沒有？如果不是是，則這個(gè)可以建立復(fù)合索引；不然的話考慮到單字段索引；

如果不是復(fù)合索引中包含的字段你經(jīng)常單獨(dú)出現(xiàn)在Where子句中，則分解成為多個(gè)單字段索引；

如果合么索引所包涵的字段最多3個(gè)，這樣翻看考慮到其必要性，確定增加業(yè)胎關(guān)系的字段；

如果沒有既有單字段索引，又有這幾個(gè)字段上的合么索引，一般這個(gè)可以刪除純索引；

8、過度參與數(shù)據(jù)操作的表，千萬不能建立太大的索引；

9、刪除掉無濟(jì)的索引，盡量的避免對不能執(zhí)行計(jì)劃產(chǎn)生嚴(yán)重影響；

以上是一些普遍的確立索引時(shí)的判斷依據(jù)。索引的建立需要慎重，對每個(gè)索引的必要性都肯定經(jīng)過仔細(xì)分析，要有確立的依據(jù)。

畢竟太的索引與不充分、不真確的索引對性能都絲毫益處：在表上確立的每個(gè)索引都會減少存儲開銷，索引相對于直接插入、刪除掉、更新操作也會增加處理上的開銷。別外，過多的復(fù)合索引，在有單字段索引的情況下，象大都是沒有修真者的存在價(jià)值的；反過來，還會降底數(shù)據(jù)減少刪除掉時(shí)的性能，特別是對正常自動更新的表來說，壞影響極大。

我認(rèn)為，銀色表肯定不建索引，或者數(shù)據(jù)庫記錄信息在億條數(shù)據(jù)級以上，肯定建議使用非關(guān)系型數(shù)據(jù)庫。還有些普通字段的數(shù)據(jù)庫，諸如BLOB，CLOB字段當(dāng)然也不適合我建索引。

對千萬級MySQL數(shù)據(jù)庫成立索引的事項(xiàng)及提高性能的手段

注意事項(xiàng)：

簡單，應(yīng)當(dāng)考慮到表空間和磁盤空間是否需要起碼。我們知道索引也一種數(shù)據(jù)，在建立索引的時(shí)候那樣一來也會占用大量表空間。因此在對一大表組建索引的時(shí)候簡單應(yīng)當(dāng)由考慮的是空間容量問題。其次，在對成立索引的時(shí)候要對表進(jìn)行加鎖，但應(yīng)當(dāng)注意一點(diǎn)操作在業(yè)務(wù)多余的時(shí)間的時(shí)候進(jìn)行。

mysql數(shù)據(jù)庫在進(jìn)行事務(wù)的時(shí)候會鎖表嗎？要鎖整張表應(yīng)該怎樣操作？

要是建議使用的是myisam存儲引擎，帶的是表級鎖，不過不支持什么事務(wù)。要是專用是innodb，則得用是行級鎖，如果要鎖表，一這個(gè)可以在該表刪除所有的索引，二把事務(wù)等級改成串行化，三select*outsidetableofversion，或則在有讀該表的業(yè)務(wù)層代碼加鎖。