MySQL优化_mysql不走缓存

MySQL优化总结：
1.查询缓存：
相同的查询被执行了多次的时候，查询结果会被放到一个HASH映射缓存中，后续的相同(完全一样，包括空格大小写)的查询就不用操作表而直接访问缓存结果。查询缓存是第一步，在sql语法解析之前，因此可以大大升级性能。查询缓存默认是开启的。
如下两种情况会导致不走查询缓存：
a. select语句中使用SQL_NO_CACHE强制不走缓存,如：

select SQL_NO_CACHE * from  table_name where xxxx = yyyy
1

b. 查询中有不确定数据，查询结果不会被缓存.因此,包含不确定数据的查询肯定找不到可用缓存的,例如CURRENT_DATE()和NOW()函数。解决方法是提前确定下变量对应的常量值，sql中传入常量。

select username from user where  date  >= CURDATE()
1

2. 当只要一行数据时使用 limit 1
当我们需要判断表中某个条件的数据行是否存在时，只要搜到到第一个条就可以确认存在了，没必要继续进行扫描剩余全部的数据。

select * from t_user where age=18               #需要扫描全部符合条件的列
select * from t_user where age=18 limit 1       #扫描到第一条符合条件的列就返回
select 1 from t_user where age=18 limit 1       #效率上更好一些
1
2
3

3.为主键和经常作为查询条件的字段建立索引
建立合适索引可以加速存储引擎搜索速度。索引是要占用磁盘空间的，一般一张表的索引不宜超过5个，索引字段越小越好。

4.根据业务情况，可以为不同表配置不同的存储引擎
如MyISAM引擎读性能非常好，对于写操作将会锁表，阻塞其他读写进程，因此写的性能比较差，适合于读频繁表。
InnoDB引擎读性能差一些，但它采用行级锁，因此写的操作基本不会阻塞别的进程读写，适合于更新频繁的表。

5.使用explain查看sql的执行计划情况
对于使用了索引列作为查询条件，我们要保证type为：constant，eq-ref，ref，range之一，性能依次递减，一般我们要求索引type至少要优化到range类型。
constant：一次索引就找到
eq_ref：唯一索引扫描，对于每个索引键表中只有一条记录与之匹配，常见于主键和唯一索引扫描
ref：非唯一索引扫描，返回匹配某个条件的所有记录行
range：只检索给定范围的行，使用一个索引来选择行，一般见于between and，> , <

6.大表拆分
分为垂直拆分、水平拆分。
a.垂直拆分是把不同的表拆到不同的数据库中，解决表与 表之间的IO流的竞争！如下可以将常用的职工表和紧急联系人表拆分到不动库里，对常用的职工表做集群处理。
甚至可以将一张表分为常用字段和不常用字段垂直拆分，如将户籍地址单独拆分出去。

b.水平拆分是把同一个表拆到不同的数据库中。如按照每张表200w条记录拆分。

7.慢查询日志