一、使用索引 1.單表索引建議控制在5個以內 2.單索引欄位數不允許超過5個因為欄位超過5個時，實際已經起不到有效過濾資料的作用了。 3.禁止在更新十分頻繁、區分度不高的屬性上建立索引，因為更新會變更B+樹，更新頻繁的欄位建立索引會大大降低資料庫效能。 4.性別”這種區分度不大的屬性，建立索引是沒有什麼意義的，不能有效過濾資料，性 能與全表掃描類似。 5.建立組合索引，必須把區分度高的欄位放在前面，因為能夠更加有效的過濾資料。
二、SQL使用規範最佳化 1.禁止使用SELECT *，只獲取必要的欄位，需要顯示說明列屬性。
1.1讀取不需要的列會增加CPU、IO、NET消耗。 1.2不能有效的利用覆蓋索引。 2.禁止使用INSERT INTO t_xxx VALUES(xxx)，必須顯示指定插入的列屬性。 2.1容易在增加或者刪除欄位後出現程式BUG。 3.禁止使用屬性隱式轉換。 3.1 SELECT uid FROM t_user WHERE phone=13812345678 會導致全表掃描，而不 能命中phone索引。 4.禁止在WHERE條件的屬性上使用函式或者表示式。 4.1SELECT uid FROM t_user WHERE from_unixtime(day)>="2019-07-15" 會導致全 表掃描。 4.2正確的寫法是：SELECT uid FROM t_user WHERE day>= unix_timestamp("2019-07-15 00:00:00")。 5.禁止負向查詢，以及%開頭的模糊查詢。 5.1 負向查詢條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會導致全表掃描。 5.2 %開頭的模糊查詢，會導致全表掃描。 6.禁止大表使用JOIN查詢，禁止大表使用子查詢。 6.1會產生臨時表，消耗較多記憶體與CPU，極大影響資料庫效能。 7.禁止使用OR條件，必須改為IN查詢。 7.1舊版本Mysql的OR查詢是不能命中索引的，即使能命中索引，為何要讓資料庫耗費 更多的CPU幫助實施查詢最佳化呢？ 8.應用程式必須捕獲SQL異常，並有相應處理 總結：大資料量高併發的網際網路業務，極大影響資料庫效能的都不能用哦。
一、使用索引 1.單表索引建議控制在5個以內 2.單索引欄位數不允許超過5個因為欄位超過5個時，實際已經起不到有效過濾資料的作用了。 3.禁止在更新十分頻繁、區分度不高的屬性上建立索引，因為更新會變更B+樹，更新頻繁的欄位建立索引會大大降低資料庫效能。 4.性別”這種區分度不大的屬性，建立索引是沒有什麼意義的，不能有效過濾資料，性 能與全表掃描類似。 5.建立組合索引，必須把區分度高的欄位放在前面，因為能夠更加有效的過濾資料。
二、SQL使用規範最佳化 1.禁止使用SELECT *，只獲取必要的欄位，需要顯示說明列屬性。
1.1讀取不需要的列會增加CPU、IO、NET消耗。 1.2不能有效的利用覆蓋索引。 2.禁止使用INSERT INTO t_xxx VALUES(xxx)，必須顯示指定插入的列屬性。 2.1容易在增加或者刪除欄位後出現程式BUG。 3.禁止使用屬性隱式轉換。 3.1 SELECT uid FROM t_user WHERE phone=13812345678 會導致全表掃描，而不 能命中phone索引。 4.禁止在WHERE條件的屬性上使用函式或者表示式。 4.1SELECT uid FROM t_user WHERE from_unixtime(day)>="2019-07-15" 會導致全 表掃描。 4.2正確的寫法是：SELECT uid FROM t_user WHERE day>= unix_timestamp("2019-07-15 00:00:00")。 5.禁止負向查詢，以及%開頭的模糊查詢。 5.1 負向查詢條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會導致全表掃描。 5.2 %開頭的模糊查詢，會導致全表掃描。 6.禁止大表使用JOIN查詢，禁止大表使用子查詢。 6.1會產生臨時表，消耗較多記憶體與CPU，極大影響資料庫效能。 7.禁止使用OR條件，必須改為IN查詢。 7.1舊版本Mysql的OR查詢是不能命中索引的，即使能命中索引，為何要讓資料庫耗費 更多的CPU幫助實施查詢最佳化呢？ 8.應用程式必須捕獲SQL異常，並有相應處理 總結：大資料量高併發的網際網路業務，極大影響資料庫效能的都不能用哦。