索引降維 我們mysql優化，一般採用建立索引的方式，來提高查詢的速度，怎麼在使用索引的情況下更高效的，充分的使用索引，追求極致，提高自己的查詢速度。都知道在where子句中不要使用一些計算之類的語句，避免索引的失效。
什麼是降維？ 一級級的篩選，一層層的過濾。
業務要求查詢某乙個人的記錄，如何查高效。遊戲很火爆，記錄表達到千萬條資料。
表結構：
pid 自增 active_id 活動id be_watered 參賽使用者的uid 關鍵的幾個字段。
注：active_id 是活動id，基於業務邏輯的可重用性，sass平台，多家機構都可以建立活動，區分不同的活動的id.
業務要求：查詢 active_id 為 1 ，使用者 uid 為 666 的遊戲記錄資訊
1、select * from active_log where active_id = 1 and uid = 666
此sql 有沒有毛病，很顯然，沒有任何毛病。但是不是最優的呢，在大資料量的時候，不是。
2、select * from active_log where uid = 666 and active_id = 1;
sql 語句1 和 sql 語句2 有沒有區別，條件只不過調換了一下位置。顯然，sql2 更高效。
為什麼：
假設，活動 active_id 1 有10w條資料，uid 有100條資料。
那麼，sql 1 的執**況是 先查出來10w條，然後篩選100條資料返回。sql 2 就是直接找到uid 100條，實際上uid是自增的，不需要在篩選active_id。~~~~就是舉這個例子，說明一下where子句的順序，會影響到查詢的效率，所以，在一層層的篩選中，我們應該盡可能的降低查詢的條數，mysql解析器快速定位。
這個只是小例子，具體的實際的業務還是要使用explain 和 profiling 來分析。
我為人人，人人為我；美美與共，天下大同；
mysql 優化 聚集索引 mysql 索引優化
一.聚集索引 clustered index innodb預設依據主鍵列聚集，myisam不使用 特點 b樹每個葉子包含實際資料行，資料按照索引順序地儲存在物理頁上。優點 1.範圍查詢，獲取指定id的全部資料只需從磁碟讀取少量資料頁 如果不使用聚集索引，每條資料可能引起一次磁碟io。2.由於索引和資...
mysql索引優化原則 MySQL 索引優化原則
索引優化原則 1 最左字首匹配原則，聯合索引，mysql會從做向右匹配直到遇到範圍查詢 3 and d 4 如果建立 a,b,c,d 順序的索引，d是用不到索引的，如果建立 a,b,d,c 的索引則都可以用到，a,b,d的順序可以任意調整。2 和in可以亂序，比如a 1 and b 2 and c ...
mysql索引優化原則 MySQL索引優化
mysql官方對索引的定義 索引是幫助mysql高效獲取資料的資料結構。索引是在儲存引擎中實現的，所以每種儲存引擎中的索引都不一樣。如myisam和innodb儲存引擎只支援btree索引 memory和heap儲存引擎可以支援hash和btree索引。這裡僅針對常用的innodb儲存引擎所支援的b...