最近上线了一个10万户的管理系统，以前的客户没有这么多用户量，隐藏在代码中的慢sql渐渐显现出来了。
下面是我最近一周慢sql优化的总结：

	多表sql优化、count sql优化、超过10 0000条limit优化

一、多表sql优化

二、count sql优化

该表有2135067条记录，使用pageHelper默认生成的count sql，导致相关菜单页面完全没法使用


由于count(*)太慢，考虑到使用count(任意索引列)的方式写sql，字段的数据长度越长，建立的索引长度越长、查询性能越差。就找了长度只有1的status字段，这样能达到最好的索引性能。
使用如下sql建立索引：

alter table water add index idx_status (status)

从阿里规约得知，count(列名)不会统计此列为NULL值的行，status字段必须设置成非空，否则存在NULL值会导致统计数据错误；虽然该优化不符合规约，但实实在在的提升性能，故值得一试！

三、超过10 0000条limit优化

MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。

数值状态码查询条件，使用int代替varchar查询效率更高 status:char(1)