◆当SQL语句是由代码动态生成的，如在运行时根据用户操作加入不同的where参数，应在测试阶段对SQL生成的典型情况和边界情况进行测试，看是否有可能造成性能问题。并应适当生成一些日志，供提取最终生成的SQL进行效率分析。

　　◆对数据应合理分库分表，由应用层去动态的选择库和表。MySQL的innodb表虽然理论上可以装海量的数据，但在我们的业务场景下，数据控制在500w以下会比较合理，追求性能的话，最好控制在200w以下，合理索引。

　　◆需要联合查询时善用left join/right join而不是直接多表联合，怎么用，查manul ^_^

　　◆尽量不要使用select套select的复合查询，如果能拆开，尽量拆开，多条精悍的SQL，组合起来可能就是一条庞大的SQL，应该避免。

　　◆善用cache，将不常修改的，数据量有限的，又是被密集查询的信息，加载到cache里，可以有效的降低数据库压力。在一般的业务场景里，推荐使用开源memcache，简单高效。

　　◆如果一些逻辑可以放到应用层去完成，可以考虑放到应用层去完成。但如果将SQL逻辑分拆到应用层可能导致对数据更频繁的访问的话，那么需要考虑修改应用逻辑，数据结构，或回到合理的联合查询上来。

　　比如某些数据的排序可以load到php数组里，再sort.又比如需要查询A，B两个表，A表里的数据是B表里某个字段的对照说明（如A：t_service表，B.t_task表），A表数据量有限，可以做联合查询，也可以先将A表先load到进程或内存里，用hash结构cache起来，再查B表，然后在cache里依次查询hash，获得对照说明。

　　◆关于导数据和统计性查询.导数据在计算和磁盘io上对数据库压力都会很大，应在时间和空间上合理分摊数据库压力如果需要导出批量的特定数据做分析，应建立专供数据分析的数据库服务器，或者建立临时库表，先导出数据，再在上面做分析运算。

　　导数据等可能引起批量数据读取的操作，应建立定时任务，在数据库不繁忙的时段（凌晨1~7时）运行一般的统计操作，对实时性要求都不会太高（5~10分钟以上，甚至一天，一周等），这种数据不应在每次访问时运行库中直接count，group，而是应该由定时任务导出，建立结果表或中间结果表，供最终用户使用。

　　◆生产数据库上的操作权限应严格控制，而开发人员在生产数据库上直接运行SQL语句，要尽量慎重。

　　能做到以上这些，基本上可以算MySQL以及相关系统优化入门，可以保证不要让我们的数据库整天累趴下了。

　　最后，即使做足了功课，也还是要例行的对数据库运行情况进行观察，监控，尽早发现其性能瓶颈，在未造成危害前解决掉。