1：单表+索引而非多表join
多个表join很可能会出现using temporary和using filesort，并发高的时候对DB服务器有压力
并且如果用到分表分库，join的操作可能就没法用
虽然这样可能会造成一个业务逻辑需要执行多个SQL完成，但是对DB来说喜欢多个简单高效的SQL超过一个复杂低效的SQL
其实只要做好缓存和设计好索引，效率很高
1：让缓存的效率更高。不仅是针对MySQL缓存，应用层的缓存也有好处
2：将查询分解后，执行单个查询可以减少锁的竞争
3：在应用层做关联，可以更容易对数据库拆分，更容易做到高性能和可扩展
4：查询本身的效率也可能会提高。多表查询可能会有临时表和filesort，但是单表查询比较好控制走索引

2：复杂的查询或者逻辑不要交给DB，在应用中做
也包含第一条
比如，帖子在APP展示的排序顺序有多个，这时候可以先全部取出符合条件的数据（当然也要限制数量）
再在应用的内存中进行排序，把复杂的逻辑交给应用，而非丢给DB

3：确保每个查询用到索引
如果确实没办法用，那就想办法尽可能把范围缩小
比如，后台需要对帖子的标题进行模糊匹配也就是like ‘%key%’（没有其他的查询条件了）的查询
title这个字段肯定用不上索引了，那就只能尽量缩小查询范围，强制要求输入create_time发帖时间的限制
最起码create_time这个字段上可以用到索引

4：使用缓存
不是说MySQL的查询缓存，是指应用层的缓存，例如memcache、redis等，尽量能批量获取
基本信息单条缓存起来，尽量能根据key批量获取。没有命中缓存再去DB批量查询
比如，需要分页获取某个用户的帖子详情，可以先查询出用户的全部发帖ID（这个不会太多,缓存起来）
然后在内存中进行分页，获取到帖子的ID列表，去缓存匹配查询出来，没用命中缓存的再去DB一次性批量查询出

5：DB的查询和更新尽可能批量，但是要控制数量
比如，应用层需要获取ID为1，2，3，4的数据全部字段或者要删除ID为1，2，3，4的数据，那么可以用id in (1,2,3,4)的形式