千万级用户场景的调优
SELECT id, name FROM users WHERE id IN (SELECT user_id FROM users_extent_info WHERE latest_login_time < xxxxx) 一般存储用户数据的表会分为两张表，一个表用来存储用户的核心数据，比如id、name、昵称、手机号之类的信息，也就是上面SQL语句里的users表。另外一个表可能会存储用户的一些拓展信息，比如说家庭住址、兴趣爱好、最近一次登录时间之类的，就是上面的users_extent_info表。
直接就是用了id IN字句去查询 id 在子查询结果范围里的users表的所有数据，此时这个SQL往往一下子会查出来很多数据，可能几千、几万、几十万，都有可能，所以其实一般运行这类SQL之前，都会先跑一个count聚合函数，看看有多少条，比如下面这儿样：
SELECT COUNT(id) FROM users WHERE id IN (SELECT user_id FROM users_extent_info WHERE latest_login_time < xxxxx)
亿级数据量商品系统的SQL调优实战
select * from products where category='xx' and sub_category='xx' order by id desc limit xx,xx
这其实是一个很稀松平常的SQL语句，就是用户在电商网站上根据商品的品类以及子类在进行筛选，当然真实的SQL语句里，可能还包含其他的一些字段的筛选，比如什么品牌以及销售属性之类的，这里是做了一个简化，然后按id倒序排序，最后是分页，就这么一个语句。这个语句执行的商品表里大致是1亿左右的数据量，这个量级已经稳定了很长时间了，主要也就是这么多商品，但是上面的那个语句居然一执行就是几十秒！
explain select * from products where category='xx' and sub_category='xx' order by id desc limit xx,xx
发现索引其实真正使用的主键索引
select * from products force index(index_category) where category='xx' and sub_category='xx' order by id desc limit xx,xx
强制让MySQL走组合索引
