
发展过程:优化数据结构和索引–>文件缓存(io)–>memcached
垂直拆分(读写分离)
水平拆分(MySQL集群)
通过非聚簇索引找到主键索引,再通过主键索引找到行记录的过程被称作回表
MySQL文集
深入MySQL复制
mysql命令行参数
EXPLAIN字段详解&测试
关注type,key,extra 三列
减低io: 1. 次数 2. 单次的量
show variables like “%innodb%”;
SELECT 0 = “id” ; // 1, id为列
以下2条语句走索引. 字符串自动转数字
EXPLAIN SELECT * FROM userinfo WHERE id = 3
EXPLAIN SELECT * FROM userinfo WHERE id = "3"
对字段进行操作会导致索引失效
EXPLAIN SELECT * FROM userinfo WHERE id+1 = 4
1. 为什么B+树?
二叉树插入数据高度不可控,影响整体IO次数,影响数据访问效率.
innoDB默认读取16KB数据
在单个节点存储尽可能多数据,降低树的高度
os页4kB
单页16kB, BIGINT占8B,指针占6B, 非叶子节点16384/14=1170
叶子节点单节点按1KB,则叶子节点条数为16k/1k=16条.
1170*1170*16=2190万. 即3层可存储2000多万条数据
2. 存储引擎
myISAM数据和索引分开存储
myISAM和innoDB使用B+树,MEMORY使用hash表
innoDB支持自适应hash(自动选择)
使用最多是主键索引和组合索引
3. 为什么不是hash表?
等值查询很快
1. 需要好的hash算法. 不合适会hash冲突和hash碰撞,会导致数据散列不均匀,会退化成链表
2. 不支持范围查询.范围查询需要挨个对比,效率太低
3. 需要将所有的数据文件添加到内存,需要大量的内存空间
4. B+树
每个节点存储: 1. 键值,即表中记录的主键 2. 指针,存储了节点地址信息 3. 数据,即表记录中除主键外的数据
叶子节点两两指针相互连接(符合磁盘的预读特性),顺序查询性能更高
B+树有2个头指针,一个指向头节点,一个指向关键字最小的叶子节点
2种查找:1.对于主键的范围查找和分页查找 2.从根节点开始的随机查找
非叶子节点不存储数据,只存储key.叶子节点存储key和数据. 千万级别3-4层
5. 聚簇索引
插入数据时,必须将数据与索引列绑定,主键,唯一键或6字节rowid
innoDB存在聚簇索引和非聚簇索引
6. 分库分表
mycat,shardingsphere(推荐),drds(阿里云)
7. 索引
300万数据量
show index from abc;
InnoDB普通索引的叶子节点存储主键值。
MyISAM的索引叶子节点存储记录指针

- 回表
(1)先通过普通索引定位到主键值;
(2)再通过聚集索引定位到行记录;
这就是所谓的回表查询,先定位主键值,再定位行记录,它的性能较扫一遍索引树更低
需要回表的都是非聚簇索引 - 索引覆盖
从索引的叶子节点就能获取全量查询列的过程
常见的方法是:将被查询的字段,建立到联合索引里去
索引覆盖场景
场景1:全表count查询优化
原表为:
user(PK id, name, sex);
直接:
select count(name) from user;
不能利用索引覆盖。
添加索引:
alter table user add key(name);
就能够利用索引覆盖提效。
场景2:列查询回表优化
select id,name,sex … where name=‘shenjian’;
这个例子不再赘述,将单列索引(name)升级为联合索引(name, sex),即可避免回表。
场景3:分页查询
select id,name,sex … order by name limit 500,100;
将单列索引(name)升级为联合索引(name, sex),也可以避免回表。
-
最左前缀
MySQL优化器会选择合适的顺序执行.and -
索引下推
show variables like “%opt%”;
索引下推(index condition pushdown )简称ICP,在Mysql5.6的版本上推出,用于优化查询。5.7默认开启- 在不使用ICP的情况下,在使用非主键索引(又叫普通索引或者二级索引)进行查询时,存储引擎通过索引检索到数据,然后返回给MySQL服务器,服务器然后判断数据是否符合条件 。
- 在使用ICP的情况下,如果存在某些被索引的列的判断条件时,MySQL服务器将这一部分判断条件传递给存储引擎,然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件,只有当索引符合条件时才会将数据检索出来返回给MySQL服务器 。
- 索引条件下推优化可以减少存储引擎查询基础表的次数,也可以减少MySQL服务器从存储引擎接收数据的次数
优化器:cbo基于成本的优化,rbo基于规则的优化
当表中所有字段都是索引列的时候,无论进行怎样的查询都会用到索引
不需要索引字段加索引
key
8. SQL调优
表结构,数据量,执行计划
- MySQL优化,主要分4个方向:SQL语句跟索引、表结构、系统配置、硬件。总优化思路就是最大化利用索引、尽可能避免全表扫描、减少无效数据查询:
- 减少数据访问:设置合理的字段类型,启用压缩,通过索引访问等减少磁盘 IO。
- 返回更少的数据:只返回需要的字段和数据分页处理,减少磁盘 IO 及网络 IO。
- 减少交互次数:批量 DML 操作,函数存储等减少数据连接次数。
- 减少服务器 CPU 开销:尽量减少数据库排序操作以及全表查询,减少 CPU 内存占用 。
- 分表分区:使用表分区,可以增加并行操作,更大限度利用 CPU 资源。
- 主键类型:
- 自然主键:就是充当主键的字段本身具有一定的含义,是构成记录的组成部分,比如学生的学号,除了充当主键之外,同时也是学生记录的重要组成部分。
- 代理主键:就是充当主键的字段本身不具有业务意义,只具有主键作用,比如自动增长的ID。
建议使用代理主键
- MySQL优化
设计数据库时:数据库表、字段的设计,存储引擎
利用好MySQL自身提供的功能,如索引等
横向扩展:MySQL集群、负载均衡、读写分离
SQL语句的优化(收效甚微)
9. 索引优化
大数据分页查询可以使用子查询或union all,好过直接limit
dv值(distinct value)区分度可以使用 count(distinct(列名))/count(*) 来计算>80%,建议建索引



单表索引建议控制在5个以内,现在没有太多限制
10. 索引使用率监控
show status like 'Handler_read%';

Handler_read_first 代表读取索引头的次数,如果这个值很高,说明全索引扫描很多。
Handler_read_key代表一个索引被使用的次数,如果我们新增加一个索引,可以查看Handler_read_key是否有增加,如果有增加,说明sql用到索引。
Handler_read_next 代表读取索引的下列,一般发生range scan。
Handler_read_prev 代表读取索引的上列,一般发生在ORDER BY … DESC。
Handler_read_rnd 代表在固定位置读取行,如果这个值很高,说明对大量结果集进行了排序、进行了全表扫描、关联查询没有用到合适的KEY。
Handler_read_rnd_next 代表进行了很多表扫描,查询性能低下。
11.主从复制
show variables like 'log_%';
MySQL8默认开启binlog
show binlog events;
binlog(MySQL server),建议开启,可以恢复
undo log(innoDB):回滚日志
redo log(innoDB):前滚日志
12.插入百万数据的存储过程
CREATE DEFINER=`root`@`localhost` PROCEDURE `mock`()
BEGIN
DECLARE n INT;
SET n=1000000;
WHILE n > 0
DO
INSERT INTO app_user(`name`,`email`,`phone`,`gender`,`password`,`age`) VALUES(CONCAT('user',n),'123@qq.com',CONCAT('18',FLOOR(RAND()*999999999)),FLOOR(RAND()*2),UUID(),FLOOR(RAND()*100));
SET n = n - 1;
END WHILE;
END
以上执行时间较久,可以参见
MySQL使用存储过程30秒插入百万数据!!!
13. 导入导出
- 导入
登录后切换到指定的数据库,执行 source sql文件
- 导出
mysqldump -h 主机 -u 用户 -p密码 数据库 表 > 导出位置.sql
10万+

被折叠的 条评论
为什么被折叠?



