观察 show status; 里面的这三个参数;Queries Threads_connected Threads_running
判断周期性变化
————————————————————
mysql -uroot -e ‘show processlist’
1.show processlist 获取sql语句
2.show profiles 检查sql语句
set profiling=1; 开启关闭 Query Profiler
show profiles 显示所有sql;
show profile for query 2 查看 Copying to tmp table 复制到临时表的时间过大,说明索引不对
show profile cpu for query 1; 查看cpu的消耗情况
show profile memory for query 1; 查看内存消耗
show profile block io,cpu for query 1; 查看io及cpu的消耗
reset query cache 清除缓存
—————————————————————–
表优化,列类型选择
速度
int>date,time>char,varchar>blob
避免使用null
enum
——————————————————————
btree 排好序 的快速索引
左前缀要求:从左到右连续使用,断了,后面的索引就不起左右
索引有关的主要是possible_keys,key,key_len这三项，
possible_keys是指可能会用到的索引，key是当前sql使用到的索引，key_len是索引的使用字节数\
extra
using temporary 使用了临时表
using filesort 额外的文件排序
———————————————————————-
索引覆盖: 索引覆盖指 如果查询的列恰好是索引的一部分,那么查询只需要在索引文件上进行,不需要回行到磁盘上查询
explain extra: using index 用了索引覆盖
Innodb 是 聚簇索引
————————————————————————————-
1:查询频繁 2:区分度高 3:长度小 4: 尽量能覆盖常用查询字段.
select count(distinct left(word,1))/count(*) from dict;
区分度和长度
crc32 伪哈希
————————————————————————————
大数据分页 limit offset 并不是先跳过,再查询
而是,先查询,后跳过
limit 100W,10 是先把100W条取出来,然后跳过
1.select id,name from lx_com where id>1000000 limit 10; 数据没有删除过
(一般来说,大网站的数据都是不物理删除的,只做逻辑删除 ,比如 is_delete=1)
2.延迟关联
select id,name from lx_com inner join (select id from lx_com limit 5000000,10) as tmp using(id);
先用 索引覆盖 找出id,在找到对应id的值
——————————————————————————–
1.重复索引 一个列建立2个索引
alert table goods add index ck1(click_count);
alert table goods add index ck2(click_count);
ck1,ck2 重复索引
2.冗余索引
多个索引有重叠;
——————————————-
慢的原因:
1.等待时间 IO,被锁,加连接数
2.执行时间(取出了多少行,扫描多少行)
explain
1.type:all表示最差,全表扫描,index 全部扫描索引,rang范围,ref 索引迅速定位
效率 all
