减少查询的影响结果集，避免涌现全表扫描。
影响结果集是SQL优化的核心。影响结果集不是查询返回的记录数，而是查询所扫描的结果数。通过Explain或Desc剖析SQL，rows列的值即为影响结果集(还可以通过慢查询日志的Rows_examined后面的数字得到)。以下是常用的一些SQL优化策略：
去掉不必要的查询和搜索。其实在项目的实际运用中，很多查询条件是可有可无的，能从源头上避免的多余功能只管即便砍掉，这是最大略粗暴的办理方案。
合理利用索引和复合索引。建索引是SQL优化中最有效的手段。查找、删除、更新以及排序时常用的字段可以适当建立索引。不过要把稳，单条查询不能同时利用多个索引，只能利用一个索引。查询条件较多时，可以利用多个字段合并的复合索引。牢记，利用复合索引时，查询条件的字段顺序须要与复合索引的字段顺序保持同等。
谨慎利用not in等可能无法利用索引的条件。索引也不是什么时候都可以发挥浸染的，当涌现\"大众not in\"大众，\"大众!=\"大众，\公众like '%xx%'\"大众，\公众is null\公众等条件时，索引是无效的。利用这些条件的时候，请放到能有效利用索引的条件的右边。设计表构造时，个人建议尽可能用int类型代替varchar类型，int类型部分时候可以通过大于或小于代替\"大众!=\公众等条件，同时也方便知足一些须要按类型排序的需求，至于可读性的问题，完善好数据库设计文档才是明智的选择。同时建议把所有可能的字段设置为\"大众not null\"大众，并设置默认值，避免在where字句中涌现\"大众is null\"大众的判断。
不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将无法精确利用索引。尽可能少用MySQL的函数，类似Now()完备可以通过程序实现并赋值，部分函数也可以通过适当的建立冗余字段来间接替代。
在where条件中利用or，可能导致索引无效。可用 \"大众union all\"大众 或者 \"大众union\公众 (会过滤重复数据，效率比前者低) 代替，或程序上直接分开两次获取数据再合并，确保索引的有效利用。
不该用select ，倒不是能提高查询效率，紧张是减少输出的数据量，提高传输速率。
避免类型转换，这里所说的“类型转换”是指where子句中涌现字段的类型和传入的参数类型不一致的时候发生的类型转换。
分页查询的优化。页数比较多的情形下，如limit 10000,10 影响的结果集是10010行，查询速率会比较慢。推举的办理方案是：先只查询主键select id from table where .. order by .. limit 10000,10(搜索条件和排序请建立索引)，再通过主键去获取数据。
统计干系的查询。影响结果集每每巨大，且部分SQL语句本身已经难以优化。因此，应避免在业务高峰期实行统计干系的查询，或者仅在从库中实行统计查询。部分统计数据，可以通过冗余的数据构造保存，同时建议把数据先保存在内存、缓存中(如redis)，再按一定策略写入数据库。
不该用任何连表查询，通过分库和分表实现负载均衡。
随着数据量的增加，连表操作每每会导致影响结果集大增，从SQL优化的层面已经办理不了问题了。
到了这里可能很多人会想要详细学习SQL优化，没紧要，我为大家准备了一套佳构PHP教程，里面涵盖SQL优化，如果你已经会了，想要进阶中高等PHP，我这里也有专注于PHP中高等进阶的教程，点击下方标题链接即可获取方法！
全套laravel框架、ThinkPHP框架全套教程分享，PHP程序员福利！
PHP开拓三年只懂增编削查？那是你没有方案好php学习路线
此时，分库和分表是办理数据库性能压力的最优选择(详细分库和分表的方案常日结合实际业务的运用处景来确定，此处略过)。这里重点谈，如何更好的实现或者过渡到分库、分表的分布式数据库架构。
核心点便是必须先去除数据表之间的关联，即不用外键，不该用任何连表查询。为了确保不进行连表操作，在设计数据库表构造的时候，就须要设计适度冗余的字段来达到不连表的目的。
对付一些操作日志、支付记录等，设计一些记录用户信息的字段，个人认为实在不能算冗余，毕竟用户信息每每会变动，但是这种类似操作日志的表确实是须要记录用户操作时的信息，并且不须要在用户更新信息时同步更新。
实际开拓中，为了实现不进行连表而冗余的字段，每每是须要在原表更新数据的时候同步更新冗余字段的数据的，如果运用层没有对数据表操作做合理封装，这每每是个棘手的问题，也未便利掩护。
当然，现在主流的运用框架，一样平常采取orm的办法处理数据表，以是问题不大。相反，不连表事实上还可以提高开拓效率，比如通过用户ID获取用户姓名操作，如果不连表就可以确保各个业务模块都通过同样的办法去获取用户姓名，调用同一个封装好的方法，这样，就能很方便的统一在运用层加入缓存机制或添加统一的业务逻辑。
同时如果要对用户表进行分库分表，通过运用层程序就可以大略平滑的实现。
利用Innodb。
关于Innodb和Myisam比拟，我就不多说了。Myisam的表级锁是致命问题，考虑到MySQL已经默认利用Innodb作为数据库引擎，个人建议大部分情形可以直策应用Innodb，其他引擎这里就不详细谈论了。
利用缓存。
1) 尽可能在程序上实现常用数据的缓存，目前主流的运用框架该当都能快速实现缓存的需求。如果在程序上没有实现数据缓存，开启数据库的query cache也是缓解数据库压力的办法之一，如果确认利用，记得定时清理碎片flush query cache。
做事器干系优化
MySQL做事配置以及分布式架构的实现，请根据实际运用处景和业务需求定制，非本文重点，不做深入磋商。
