mysql 索引優化

select * from doc where title like '%xx'； --不能使用索引

select * from doc where title like 'xx%'； --非前導模糊查詢，可以使用索引

2.1 union能夠命中索引，並且mysql 耗費的 cpu 最少。

select * from doc where status=1
union all
select * from doc where status=2;

2.2in能夠命中索引，查詢優化耗費的 cpu 比union all多，但可以忽略不計，一般情況下建議使用in。

select * from doc where status in (1, 2);

2.3or新版的 mysql 能夠命中索引，查詢優化耗費的 cpu 比in多，不建議頻繁用or

select * from doc where status = 1 or status = 2

2.4補充：有些地方說在where條件中使用or，索引會失效，造成全表掃瞄，這是個誤區：

例如status欄位的取值是1,2,3,4,5 ，並且status 設定了索引

select * from doc where status != 1 and status != 2;

可以優化為

select * from doc where status in (3,4,5);

如果在(a,b,c)三個欄位上建立聯合索引，那麼他會自動建立a|(a,b)|(a,b,c)組索引。

登入業務需求，sql語句如下：

select uid, login_time from user where login_name=? and passwd=?

可以建立(login_name, passwd)的聯合索引。因為業務上幾乎沒有passwd的單條件查詢需求，而有很多login_name的單條件查詢需求，所以可以建立(login_name, passwd)的聯合索引，而不是(passwd, login_name)。

select * from employees.titles where emp_no < 10010' and title='senior engineer'and from_date between '1986-01-01' and '1986-12-31'

select * from user where phone=13800001234

複製**

select * from user where phone='13800001234';

覆蓋索引：查詢的列和所建立的索引的列個數相同，字段相同。

只要列中包含有null值都將不會被包含在索引中，復合索引中只要有一列含有null值，那麼這一列對於此復合索引就是無效的。所以我們在資料庫設計時，盡量使用not null約束以及預設值。

order by最後的字段是組合索引的一部分，並且放在索引組合順序的最後，避免出現file_sort 的情況，影響查詢效能。

如果索引中有範圍查詢，那麼索引有序性無法利用，如where a>10 order by b;，索引(a,b)無法排序。

索引越多越好，認為需要乙個查詢就建乙個索引。

寧缺勿濫，認為索引會消耗空間、嚴重拖慢更新和新增速度。

抵制惟一索引，認為業務的惟一性一律需要在應用層通過「先查後插」方式解決。

過早優化，在不了解系統的情況下就開始優化。

一般兩種情況下不建議建索引：

第一種情況是表記錄比較少，例如一兩千條甚至只有幾百條記錄的表，沒必要建索引，讓查詢做全表掃瞄就好了。至於多少條記錄才算多，這個個人有個人的看法，我個人的經驗是以2000作為分界線，記錄數不超過 2000可以考慮不建索引，超過2000條可以酌情考慮索引。

另一種不建議建索引的情況是索引的選擇性較低。所謂索引的選擇性（selectivity），是指不重複的索引值（也叫基數，cardinality）與表記錄數（#t）的比值：

index selectivity = cardinality / #t