一.一个复杂查询还是多个简单查询
设计查询的时候一个需要考虑的重要问题是，是否需要将一个复杂的查询分成多个简单的查询。
- MySQL从设计上让连接和断开连接都很轻量级，在返回一个小的查询结果方面很高效。运行多个小查询不是问题
- MySQL内部每秒能够扫描内存中上百万行数据，相比之下，MySQL相应数据给客户端就慢的多。在其他条件都相同的时候，使用尽可能少的查询更好
二、切分查询
有时候对于一个大查询，我们需要“分而治之”，将大查询切分成小查询，每个查询功能完全一样，但只完成一小部分
删除旧的数据就是一个很好的例子。定期地清除大量数据时，如果用一个大的语句一次性完成的话，则可能需要一次锁住很多数据、占满整个事务日志，耗尽系统资源、阻塞很多小但重要的查询。
将一个大的DELETE语句切分成多个较小的查询可以尽可能小地影响MySQL性能，同时还可以减少MySQL复制的延迟。例如，我们需要每个月运行一次下面的查询：
那么可以用类似下面的办法来完成同样的工作：循环每次删除10000条数据，直到没有可删除的数据为止结束循环
这是一个比较高效且对服务器影响也最小的做法（如果是事务型的引擎，很多时候小事务能够更加高效）。同时，需要注意的是，如果每次删除数据后，都暂停一会儿再做下一次删除，这样也可以将服务器上原本一次性的压力分散到到一个很长的时间段中，就可以大大降低对服务器的影响，还可以大大减少删除时，锁的持有时间
三、分解关联查询
很多高性能的应用都会对关联查询进行分解。简单地，可以对每一个表进行一次单表查询，然后将结果在应用程序中进行关联。例如：下面这个查询：
可以分解成下面这些查询来代替：
为什么要这么做？
- 让缓存的效率更高。许多应用程序可以方便地缓存单表查询对应的结果对象。 例如，上面查询中的tag已经被缓存了，那么应用程序就可以跳过第一个查询。但如果关联中的某个表发生了变化，那么就无法使用查询缓存了，而拆分后，如果某个表很少改变，那么基于该表的查询就可以重复利用查询缓存结果了。
- 将查询分解后，执行单个查询可以减少锁的竞争
- 在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可拓展。
- 查询本身效率也可能会有所提升，上面的例子用IN()代替关联查询，可以让MySQL按照ID顺序进行查询，这可能比随机的关联要更高效。
- 可以减少冗余记录的查询。在应用层做关联查询，意味着对于某条记录应用只需要查询一次，而在数据库中做关联查询，则可能重复的访问一部分数据。重构可能减少网络也和内存的消耗
- 更进一步，这样做相当于在应用中实现了哈希关联，而不是使用MySQL的嵌套循环关联。某些场景哈希关联的效率要高很多