話說有這麼乙個表：
create table`user_group` (
`id`int(11) not nullauto_increment,
`uid`int(11) not null,
`group_id`int(11) not null,primary key(`id`),key`uid` (`uid`),key`group_id` (`group_id`),
) engine=innodb auto_increment=750366 default charset=utf8
看auto_increment就知道資料並不多，75萬條。然後是一條簡單的查詢：
select sql_no_cache uid from user_group where group_id = 245;
很簡單對不對?怪異的地方在於：
如果換成myisam做儲存引擎的時候，查詢耗時只需要0.01s，用innodb卻會是0.15s左右
如果只是就這麼點差距其實不是什麼大不了的事，但是真實的業務需求比這個複雜，造成的差距也很大：myisam只需要0.12s，innodb則需要2.2s.，最終定位到問題癥結是在這條sql。
explain的結果是：
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
| 1 | ****** | user_group | ref | group_id | group_id | 4 | const | 5544 | |
看起來已經用上索引了，而這條sql語句已經簡單到讓我無法再優化了。最後請前同事gaston診斷了一下，他認為：資料分布上，group_id相同的比較多，uid雜湊的比較均勻，加索引的效果一般，但是還是建議我試著加了乙個多列索引：
alter table user_group add index group_id_uid (group_id, uid);
然後，不可思議的事情發生了……這句sql查詢的效能發生了巨大的提公升，居然已經可以跑到0.00s左右了。經過優化的sql再結合真實的業務需求，也從之前2.2s下降到0.05s。
再explain一次：
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
| 1 | ****** | user_group | ref | group_id,group_id_uid | group_id_uid | 4 | const | 5378 | using index |
原來是這種叫覆蓋索引(covering index)，mysql只需要通過索引就可以返回查詢所需要的資料，而不必在查到索引之後再去查詢資料，所以那是相當的快!!但是同時也要求所查詢的字段必須被索引所覆蓋到，在explain的時候，輸出的extra資訊中如果有「using index」，就表示這條查詢使用了覆蓋索引。
不過，還有乙個無法解釋的問題就是，不用覆蓋索引的情況下，為什麼用myisam就快那麼多，而innodb就慢這麼多呢?求真相……
原文出處：
資料理解常用函式
1 資料的相關性 通常用來計算兩個屬性的相關性的方法是皮爾遜相關係數，介於 1 1之間。通過dataframe的corr 方法來計算資料相關性，如果資料屬性之間關聯性過高，則進行降維處理。from pandas import read csv filename iris.csv names sepa...
資料理解和預處理
一 資料理解 很重要！關係到如何分析與挖掘資料 二 變數型別 1.名義變數 無順序程度的差別，如 安卓與ios 動作片與愛情片 2.定序變數 有一定程度的排序，如 優良差 教育程度 小學 初中 高中 大學及以上 如何處理？從模型角度，有的處理模型可直接處理分類變數，如決策樹，但對於其他模型，就需要對...
mysq資料庫再次理解
1.表中的一條記錄就是乙個object，object有很多屬性，對應表中的字段。object的屬性對應的值就是字段值 2.外來鍵是關聯表關係用的。表關係的確立只能通過外來鍵 但更高效的策略是，在資料庫中部設定任何外來鍵，只是在 中進行控制。不設定外來鍵是指不指定foreign key，但是外來鍵這個...