【MySQL-索引调优】02：单列索引

1-问题查询EXPLAINSELECT*FROMordersWHEREuser_id1234;发现idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra1SIMPLEordersALL9952010Using where分析select_type SIMPLE说明这是一个简单查询没有子查询或UNIONtable orders查询的表就是orderspartitions NULL没有分区type ALL这是最关键的表示执行计划是 全表扫描。也就是说它没有用索引而是把整张表都扫一遍possible_keys NULL没有可用的索引key NULL关键实际使用的索引也是空的说明没有用索引key_len NULL索引长度为空ref NULL没有引用索引rows 99520关键预估需要扫描大约 99,520 行数据filtered 10表示大约只有 10% 的数据符合条件Extra Using where说明是靠WHERE user_id 1234这个条件来过滤查询在orders表上做了全表扫描效率比较低。如果orders表很大性能会很差。原因是user_id字段没有索引所以数据库只能把整张表读一遍再过滤2-优化执行计划显示type ALL也就是全表扫描possible_keys NULL说明数据库认为没有合适的索引可以用查询条件是WHERE user_id 1234可以新增user_id索引提高查询速度# 新增索引CREATEINDEXidx_user_idONorders(user_id);# 再次运行EXPLAINSELECT*FROMordersWHEREuser_id1234;结果为idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra1SIMPLEordersrefidx_user_ididx_user_id9const8100分析type ref这表示查询使用了非唯一索引普通索引通过索引来定位行而不是全表扫描。相比之前的ALL性能提升很大possible_keys idx_user_id数据库识别到可以用idx_user_id这个索引key idx_user_id实际使用的索引就是你刚建的idx_user_idkey_len 9索引字段的长度这里是user_id的存储长度ref const说明查询条件是一个常量user_id 1234直接用这个值去索引里查rows 8数据库预估只需要扫描大约8行而不是之前的99,520行filtered 100表示这些行几乎全部符合条件