一、明确搜索优化的整体思路以及查询优化的因素：
（1）搜索优化的整体思路：
索引优化，查询优化，查询缓存，服务器设置优化，操作系统和硬件优化，应用层面优化（web服务器，缓存）等等。对于一个整体项目而言只有这些齐头并进，才能实现mysql高性能。
（2）
1.是否向数据库请求了不需要的数据：
也就是说不要轻易使用select * from ，能明确多少字段就写多少字段
2.mysql是否扫描额外的纪录：
查询是否扫描了过多的数据。最简单的衡量查询开销三个指标如下：响应时间；扫描的行数；返回的行数。
没有哪个指标能够完美地衡量查询的开销，但它们大致反映了mysql在内部执行查询时需要多少数据，并可以推算出查询运行的时间。
这三个指标都会记录到mysql的慢日志中，所以检查慢日志记录是找出扫描行数过多的查询的好办法。
响应时间：是两个部分之和：服务时间和排队时间。服务时间是指数据库处理这个查询真正花了多长时间。 排队时间是指服务器因为等待某些资源而没有真正执行查询的时间。—可能是等io操作完成，也可能是等待行锁，等等。
扫描的行数和返回的行数：分析查询时，查看该查询扫描的行数是非常有帮助的。这在一定程度上能够说明该查询找到需要的数据的效率高不高。
扫描的行数和访问类型： 在expain语句中的type列反应了访问类型。访问类型有很多种，从全表扫描（ALL）到索引扫描（index）到范围扫描（）到唯一索引查询到常数引用等。这里列的这些，速度由慢到快，扫描的行数也是从小到大。
如果发现查询需要扫描大量的数据但只返回少数的行，那么通常可以尝试下面的技巧去优化它：
使用索引覆盖扫描。
改变库表结构。例如使用单独的汇总表。
重写这个复杂的查询。让mysql优化器能够以更优化的方式执行这个查询。
三 1. 一个复杂查询 or 多个简单查询
设计查询的时候一个需要考虑的重要问题是，是否需要将一个复杂的查询分成多个简单的查询。
2.切分查询
有时候对于一个大查询我们需要“分而治之”，将大查询切分为小查询，每个查询功能完全一样，只完成一小部分，每次只返回一小部分查询结果。
3.分解关联查询
让缓存的效率更高。
将查询分解后，执行单个查询可以减少锁的竞争。
在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。
查询本身效率也可能会有所提升。
可以减少冗余记录的查询，
更进一步，这样做相当于在应用中实现了哈希关联，而不是使用mysql的嵌套循环关联。
四 查询的流程
1.客户端发送一条查询给服务器
2.服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果，否则进入下一阶段。
3.服务器进行SQL解析，预处理，再由优化器生成对应的执行计划，
4.mysql根据优化器生成的执行计划，调用存储引擎的API来执行查询。
5.将结果返回给客户端。
五
（1）查看MySQL整体状态：
-
Mysql> show status; ——显示状态信息（扩展show status like ‘XXX’）
-
Mysql>show variables ——显示系统变量（扩展show variables like ‘XXX’）
-
Mysql>show innodb status ——显示InnoDB存储引擎的状态
-
Mysql>show processlist ——查看当前SQL执行，包括执行状态、是否锁表等
-
Shell> mysqladmin variables -u username -p password——显示系统变量
-
Shell> mysqladmin extended-status -u username -p password——显示状态信息
-
Shell> mysqld –verbose –help [|more #逐行显示] 查看状态变量及帮助；
（2） 开启慢日志：
1.如图
2 查看日志启动状态：show variables like “slow%”;
3 设置慢日志开启: set global slow_query_log = ON;
4 查询long_query_time 的值 ：show variables like “long%”;
也可以自己选择修改慢查询时间短一点
