PS：如果查询占大多数，那么性能优化就用慢查询日志，查询哪些select语句需要优化
PS：查询慢查询开启否
PS：还有要优化那种业务简单却相对较长的select语句，通过profile
以上都是通过时间来粗略判定SQL语句的性能，要想真正的查看性能要用explain，查询是否使用索引等
PS：尽量使用大于等于或小于等于，否则后面的status的索引失效
PS：索引使用如果不注意就会变成全表扫描，费时
PS：因为大多数都符合条件，那么还不如走全表扫描省时
有了复合索引还能对字段再创建一个单列索引，这时候如果查询的时候可以用SQL提示来说明想用哪个索引来查询
PS：索引有单列索引和联合索引，分别就是一个和多个
PS：第一个use只是建议，用不用是系统来评估的也可能不接受建议，第三条是强制使用
PS：在二级索引的叶子上就能找到ID，如果还要查询别的字段就需要在通过ID走聚集索引来找其他的字段，也就是回表查询数据，如果在聚集索引中用ID找*也数据覆盖索引的原则，不用回表
PS：这里就可以多建立联合索引，这样就不用回表查询了
PS：自己平衡性能和大小来选择选前几个，降低索引体积提高查询效率
PS：一定要考虑顺序，根据最左前缀法则最左边的一定要存在，上图中是phone
PS：如果数据量超过一百万就要考虑建立索引
SQL优化
PS：避免频繁的事务的提交
PS：二级索引有很多并且叶子节点都是主键，如果主键太长会耗费大量的磁盘空间，像UUID这类生成的时候没有规矩很可能造成乱序插入
PS：可以定义不同的排序规则，这样优化的时候可以也可以一个升序一个降序
PS：下面满足最左前缀法则，不用临时表，提高效率
PS：一旦升级为表锁那么并发性能就会降低
视图
