Mysql优化思路

1、整体优化思路

    首先构建脚本观察查询数，链接数等数据，肯定环境缘由以及内部SQL执行缘由，而后根据具体缘由作具体处理。

2、构建脚本观察状态

mysqladmin -uroot -p  ext \G

 

该命令可获取当前查询数量等信息，定时轮询并将结果重定向到文本中，而后处理成图表。

3、处理对策

    1.如果规律性出现查询慢，考虑缓存雪崩问题。

        对于该问题只需将缓存的失效时间处理成不要相近时间同时失效，失效时间尽可能离散化，或者集中到午夜失效。

    2.若非规律性查询缓慢，考虑设计缺少优化

      处理方法：

      a：开启profiling记录查询操做，并获取语句执行详细信息

show variables like '%profiling%';
set profiling=on;

select count(*) from user; 
show profiles;

show profile for query 1;


>>>
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000060 |
| Executing hook on transaction  | 0.000004 |
| starting                       | 0.000049 |
| checking permissions           | 0.000007 |
| Opening tables                 | 0.000192 |
| init                           | 0.000006 |
| System lock                    | 0.000009 |
| optimizing                     | 0.000005 |
| statistics                     | 0.000014 |
| preparing                      | 0.000017 |
| executing                      | 0.001111 |
| end                            | 0.000006 |
| query end                      | 0.000003 |
| waiting for handler commit     | 0.000015 |
| closing tables                 | 0.000011 |
| freeing items                  | 0.000085 |
| cleaning up                    | 0.000008 |
+--------------------------------+----------+

 

      b：使用explain 查看语句执行状况，索引使用，扫描范围等等

mysql> explain select count(*) from goods \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: goods
   partitions: NULL
         type: index   
possible_keys: NULL
          key: gid
      key_len: 5
          ref: NULL
         rows: 3
     filtered: 100.00
        Extra: Using index

 

      c：相关优化手法

表的优化与列类型选择

列选择原则：
1：字段类型优先级 整型 > date,time > char,varchar > blob
缘由：整型,time运算快，节省空间
char/varchar要考虑字符集的转换与排序时的校对集，速度慢
blob没法使用内存临时表
2：够用就行，不要慷慨(如 smallint,varchar(N))
缘由：大的字段浪费内存，影响速度
以varchar(10), varchar(300)存储的内容相同，但在表联查时，varchar(300)要花更多内存
3：尽可能避免使用NULL
缘由：NULL不利于索引，要用特殊的字节来标注.
在磁盘上占据的空间其实更大

索引优化策略

1.索引类型
1.1 B-tree索引(排好序的快速查找结构)
注：Myisam,innodb中，默认用的是B-tree索引
1.2 hash索引
在memory表里，默认是hash索引，hash的理论查询时间复查度为O（1）
疑问：既然hash索引如此高效，为什么不都用他？
a.hash函数计算后的结果是随机的，若是是在磁盘上放置数据，以主键为id为例，那么随着id的增加，id对应的行，在磁盘上随机放置。
b.没法对范围查询进行优化
c.没法利用前缀索引，好比在b-tree中，field列的值为“helloworld”，索引查询xx=hello/xx=helloworld均可以利用索引（左前缀索引），但hash索引没法作到，由于hash(hello)与hash(helloworld)并没有关联关系。
d.排序也没法优化
e.必须回行，经过索引拿到数据位置，必须回到表中取数据.

2.b-tree索引的常见误区
2.1 在where条件经常使用的列上都加上索引
例：where cat_id=3 and price>100； //查询第3个栏目，100元以上的商品
误：cat_id和price上都加上索引。其实只能用上一个索引，他们都是独立索引.
2.2 在多列上创建索引后，查询哪一个列，索引都将发挥做用
2.2 在多列上创建索引后，查询哪一个列，索引都将发挥做用
正解：多列索引上，索引起挥做用，须要知足左前缀要求（层层索引）
以index(a,b,c)为例：
语句 索引是否发挥做用
where a=3 是
where a=3 and b=5 是
where a=3 and b=5 and c=4 是
where b=3 or where c=4 否
where a=3 and c=4 a列能发挥索引做用，c列不能
where a=3 and b>10 and c=7 a,b能发挥索引做用，c列不能

高性能索引策略
1.对于innodb而言，由于节点下有数据文件，所以节点的分裂将会变得比较慢，对于innodb的主键，尽可能用整型，并且是递增的整型。
2.索引的长度直接影响索引文件的大小，影响增删改的速度，并间接影响查询速度（占用内存多）。
3.针对列中的值，从左往右截取部分来建索引。
a.截的越短，重复度越高，区分越小，索引效果越很差
b.截的越长，虽然区分度提升，但索引文件变大影响速度
因此尽可能在长度上找到一个平衡点使性能最大化，惯用手法：截取不一样长度来测试索引区分度
区分度测试： select count(distinct left(word, 1)) / count(*) from table;
测试完成后能够按测试得出的最优长度创建索引 alter table table_name add index word(word(4));

理想的索引1.查询频繁2.区分度高3.长度小4.尽可能覆盖经常使用查询字段