Error message here!

Hide Error message here!

忘记密码?

Error message here!

请输入正确邮箱

Hide Error message here!

密码丢失?请输入您的电子邮件地址。您将收到一个重设密码链接。

Error message here!

返回登录

Close

聊聊数据库~4.SQL优化篇

鲲逸鹏 2019-02-22 14:16:00 阅读数:196 评论数:0 点赞数:0 收藏数:0

1.5.查询的艺术

上期回顾:https://www.cnblogs.com/dotnetcrazy/p/10399838.html

本节脚本:https://github.com/lotapp/BaseCode/blob/master/database/SQL/02.索引、查询优化.sql

文章有点小长,但认真阅读肯定会有所感触和收获的。PS:我把我能想到的都列下来了,如果有新的会追加,欢迎补充和纠错~

1.5.1.索引

大方向:减少冗余索引,避免重复(无用)索引

1.概念

大一统分类:

  1. 聚簇索引、非聚簇索引:看看数据是否与索引存储在一起(一起是聚簇索引)
  2. 主键索引、辅助索引
  3. 稠密索引、稀疏索引
  • 是否索引了每一个数据项(是则为稠密索引)
  • B+ Tree
    索引、

hash索引(键值索引,

只有Memory存储引擎支持)、

R Tree索引(空间索引,

MyISAM存储引擎支持)、

Fulltext索引(全文索引)

  • 简单索引、组合索引

PS:索引通常做查询条件的字段(索引是在存储引擎级别实现的)

常用分类:

  1. 语法分类:
  2. 普通索引:一列一索引
  3. 唯一索引:设置unique之后产生(可空)
  • 可以这么理解:唯一+非空=主键
  • 复合索引:多列一索引
  • 物理存储:(Innodb和MyISAM存储引擎)
  1. 聚簇索引:一般都是主键
  • 数据和索引存储在一起的存储方式
  • Innodb文件后缀:frm、ibd(数据+索引)
  • 非聚簇索引:不是聚集索引的索引
  • 数据和索引分开存放
  • MyISAM文件后缀:frm、myd(数据)、myi(索引)
  • PS:它俩都是b树索引,frm(表结构)和存储引擎无关

2. 语法基础

  1. 查看索引:

show index from tb_name;

  • show index from worktemp.userinfoG;
  • show index from worktemp.userinfo;
  • 创建索引:
  • create [unique] index index_name on tb_name(列名,...)
  • alter table tbname add [unique] index [indexname] on (列名,...)
  • 删除索引:
  • drop index indexname on tbname
  • alter table tbname drop index indexname

1.5.2.执行计划

1.往期回顾

先回顾下上节课内容:

手写SQL的语法顺序:select distinct list> from name> type> join table> on condition> where condition> group by bylist> having condition> order by bylist> limit number>

SQL执行顺序:

1.from 1.on 1.type> join table>1.where 1.group by bylist>1.having 1.select [distinct] 1.order by bylist>1.limit

2.基础

语法:explain + SQL语句

执行计划:**使用

explain关键词可以模拟优化器执行SQL查询语句,一般用来

分析查询语句或者表结构的性能瓶颈**

执行计划一般用来干这些事情:

  1. 查看表的读取顺序
  2. 查看数据读取操作的操作类型
  3. 查看哪些索引可以使用
  4. 查看哪些索引被实际使用
  5. 查看表之间的引用
  6. 查看每张表有多少行被优化器读取

主要参数

主要是看这几个参数:

  1. id:当前查询语句中,每个select语句的编号
  • 主要是针对子查询、union查询
  • select_type
    :查询类型
  • 简单查询:simple(一般的查询语句)
  • 复杂查询:(详解见附录1)
  • subquery
    :用于where中的子查询(简单子查询)
  • derived
    :用于from中的子查询
  • union
    :union语句的第一个之后的select语句
  • union result
    :匿名临时表
  • type
    :访问类型(MySQL查询表中行的方式)
  1. all:全表扫描
  2. index:根据索引的次序进行全表扫描(覆盖索引效率更高
  3. range:根据索引做指定范围扫描
  4. ref:返回表中所有匹配某单个值的所有行
  5. eq_ref:等同于ref,与某个值做比较且仅返回一行
  6. const:根据具有唯一性索引查找时,且返回单个行(性能最优
  • eg:主键、唯一键
  • PS:1~6 ==> 数字越大效率越高(性能递增),(详解见附录2)
  • possible_keys
    :查询可能会用到的索引
  • key
    :查询中使用了的索引
  • key_len
    :索引使用的字节数(详解见附录3)
  • 根据这个值,可以判断索引使用情况
  • eg:使用组合索引时,判断所有索引字段是否都被查询到
  • ref
    :显示key列索引用到了哪些列、常量值
  • 在索引列上查找数据时,用到了哪些列或者常量
  • rows
    :估算大概需要扫描多少行
  • Extra
    :额外信息(性能递减)
  1. using index:使用了覆盖索引
    1.
    using where
    :在存储引擎检索后,再进行一次过滤
  2. using temporary:对结果排序时会使用临时表
  3. using filesort:对结果使用一个外部索引排序
  • 没有有索引顺序,使用了自己的排序算法
  • 可能出现的情况:(出现这个情况基本上都是需要优化的
  • where后面的索引列和

order by|group by后面的索引列不一致(只能用到一个索引)

  • eg:

explain select /* from users where id<10 order by email;(只用到了id)

附录

1.select_type

**select_type:查询类型**-- subquery:用于where中的子查询(简单子查询) explain select name, age from students where age > (select avg(age) from students); -- union:union语句的第一个之后的select语句 -- union result:匿名临时表 explain select name, age, work from students where name = '小张' union select name, age, work from students where name = '小明'; -- derived:用于from中的子查询 explain select /* from (select name, age, work from students where name = '小张' union select name, age, work from students where name = '小明') as tmp;

图示输出:1.sql_type.png

2.type

**type:访问类型(MySQL查询表中行的方式)**-- all:全表扫描(效率极低) explain select / from students where name like '%小%'; -- index:根据索引的次序进行全表扫描(效率低) explain select name, age, work from students where name like '%小%'; -- 其实就是上面全表扫描的改进版 -- range:根据索引做指定范围扫描 explain select name, age, work from students where id > 5; -- ref:返回表中所有匹配某单个值的所有行 explain select name, age, work from students where name = '小明'; -- eq_ref:等同于ref,与某个值做比较且仅返回一行 explain select / from userinfo inner join (select id from userinfo limit 10000000,10) as tmp on userinfo.id = tmp.id; -- 1s -- const:根据具有唯一性索引查找时,且返回单个行(//性能最优//) explain select name, age, work from students where id = 3; -- 一般都是主键或者唯一键

图示输出:

2.type1.png2.type2.png

3.key-len

  1. 是否为空:
  • not null 不需要额外的字节
  • null 需要1字节用来标记
  • PS:索引最好不要为null,这样需要额外的存储空间而且统计也变得更复杂
  • 字符类型(char、varchar)的索引长度计算:
  • 字符编码:(PS:不同字符编码占用的存储空间不同)
  • latin1
    |

ISO8859占1个字节,

gbk占2个字节,**utf8占3个字节**

  • 变长字段(varchar)需要额外的2个字节
  • 1字节用来保存需要的字符数
  • 1字节用来记录长度(PS:如果列定义的长度超过255则需要2个字节【总共3字节】)
  • 定长字段(char)不需要额外的字节
  • 数值类型、日期类型的索引长度计算:
  • 一般都是其本身长度,如果可空则+1
  • 标记是否为空需要占1个字节
  • PS:datetime在5.6中字段长度是5,在5.5中字段长度是8
  • 复合索引有最左前缀的特性。如果复合索引能全部用上,则为复合索引字段的索引长度之和
  • PS:可以用来判断复合索引是否全部使用到
  • 举个栗子:
  • eg:

char(20) index 可空

  • key-len=20/*3(utf8)+1(可空)=61
  • eg:

varchar(20) index 可空

  • key-len=20/*3(utf8)+2(可变长度)+1(是否可空的标记)=63

建表语句

create table if not exists students ( id int unsigned autoincrement primary key, name varchar(25) not null default '' comment '姓名', age tinyint unsigned not null default 0 comment '年龄', work varchar(20) not null default '普通学生' comment '职位', createtime datetime not null comment '入学时间', datastatus tinyint not null default 0 comment '数据状态' ) charset utf8 comment '学生表'; -- select currenttimestamp(), now(), unixtimestamp(); insert into students(name, age, work, createtime, datastatus) values ('111', 22, 'test', now(), 99), ('小张', 23, '英语课代表', now(), 1), ('小李', 25, '数学课代表', now(), 1), ('小明', 21, '普通学生', now(), 1), ('小潘', 27, '物理课代表', now(), 1), ('张小华', 22, '生物课代表', now(), 1), ('张小周', 22, '体育课代表', now(), 1), ('小罗', 22, '美术课代表', now(), 1); -- 创建一个组合索引 create index ixstudentsnameage_work on students (name, age, work);

说了这么多题外话,现在进入正题:

1.5.3.建表优化

  1. 定长和变长分离(具体得看业务)
  • eg:varchar、text、blob等变长字段单独出一张表和主表关联起来即可
  • 常用字段和不常用字段分离
  • 根据业务来分析,不常用的字段拎出来
  • 在1对多需要关联统计的字段上添加点冗余字段
  • 分表分库时,扩表跨库查询的情景(注意数据一致性)
  • eg:在分类表中添加一个数量字段,统计每天新增商品数量
  • 添加商品时,选完分类就update一下count值(第二天清零)
  • 字段类型一般都是按照这个优先级:(尽量使用优先级高的类型)
  • 数值 > 日期 > char > varchar > text、blob
  • PS:总体原则就是够用即可,然后尽量避免null(不利于索引,浪费空间)
  • eg:varchar(10)和varchar(300),在表连接查询时,需要的内存是不一样的
  • 伪hash法:比如商品url是一个varchar的列
  • 这时候再建一个hash(url)之后的列,把索引设置到该列
  • 推荐使用**
    crc32
    **(用bigint存储)索引空间就会小很多而且可以避免全表扫描
  • eg:

select crc32('http://www.baidu.com/shop/1.html');

  • PS:如果DBA配置了crc64,则使用;如果没有,可以加个条件(

CRC32碰撞后的解决方案)

  • 对于少部分碰撞的记录,只需要多扫描几行就行了,不会出现全表扫描的情况
  • eg:

select xxx from urls where crc_url=563216577 and url='url地址'

**PS:需要关注的技术点:

crc32**

1.5.4.组合索引专题

项目里面使用最多的是组合索引,这边先以组合索引为例:

1.尽可能多的使用索引列,尽可能使用覆盖索引

-- 如果我查询的时候,索引的三列都用到了,那么速度无疑是最快的 -- Extra:using where explain select id, name, age, work, create_time from students where name = '小张' and age = 23 and work = '英语课代表'; -- PS:★尽量使用覆盖索引★(近乎万能) -- 覆盖索引:仅仅查找索引就能找到所需要的数据 -- Extra:using where;using index explain select name, age, work from students where name = '小张' and age = 23 and work = '英语课代表'; -- PS:一般把经常select出的列设置一个组合索引,一般不超过5个

图示:3.1.覆盖索引.png

2.最左前缀原则

类比火车,火车头自己可以开,车身要是没有了车头就开不了-- 查询的时候从最左边的列开始,并且不跳过中间的列,一直到最后 explain select id, name, age, work, createtime from students where name = '小张' and age = 23 and work = '英语课代表'; -- 跳过了中间的age,这时候只用到了name列的索引(work列没用到) explain select id, name, age, work, createtime from students where name = '小张' and work = '英语课代表';

图示:3.2.组合索引失效.png

再看两个补充案例:-- PS:如果跳过了第一列,这时候索引一个也用不到,直接全表扫描了 explain select id, name, age, work, createtime from students where age = 23 and work = '英语课代表'; -- PS:列不一定需要按照指定顺序来写 explain select id, name, age, work, createtime from students where age = 23 and work = '英语课代表' and name = '小张';

图示:3.2.组合索引失效2.png

2.3.范围条件放在最后面(范围条件后面的列索引会失效)

-- name、age、work索引生效时,keylen=140 explain select id, name, age, work, createtime, datastatus from students where name = '小张' and age = 23 and work = '英语课代表'; -- 现在keylen=78 ==> work列索引就失效了(PS:age索引列未失效,只是age之后的列失效了) explain select id, name, age, work, createtime, datastatus from students where name = '小张' and age > 22 and work = '英语课代表';

图示:3.3.范围后面索引失效.png

补充说明:-- 加快查询速度可以使用覆盖索引 explain select name, age, work from students where name = '小张' and age > 22 and work = '英语课代表'; -- PS:多个主键列也一样 explain select id, name, age, work from students where name = '小张' and age > 22 and work = '英语课代表'; -- PS:调换顺序是没法解决范围后面索引失效的(本来对顺序就不在意) explain select id, name, age, work, create_time, datastatus from students where name = '小张' and work = '英语课代表' and age > 22;

图示:3.3.范围后面索引失效2.png

2.4.不在索引列上做其他操作

容易导致全表扫描,这时候利用覆盖索引可以简单优化下

1.

!=、

is not null、

is null、

not in、

in、

like慎用

**!=、

is not null、

is null的案例**-- 1.不等于案例 -- 索引失效(key,keylen ==> null) explain select id, name, age, work, createtime, datastatus from students where name != '小明'; -- <> 等同于 != -- 项目里面很多使用都要使用,那怎么办呢?==> 使用覆盖索引 -- key=ixstudentsnameagework,keylen=140 explain select name, age, work from students where name != '小明'; -- <> 等同于 != -- 2.is null、is not null案例 -- 索引失效(key,keylen ==> null) explain select id, name, age, work, createtime, datastatus from students where name is not null; -- 解决:覆盖索引 key=ixstudentsnameagework,keylen=140 explain select name, age, work from students where name is not null;

图示:3.4.不等于和null.png

**not in、

in的案例**-- 3.not in、in案例 -- 索引失效(key,keylen ==> null) explain select id, name, age, work, createtime, datastatus from students where name in ('小明', '小潘', '小李'); explain select id, name, age, work, createtime, datastatus from students where name not in ('小明', '小潘', '小李'); -- 解决:覆盖索引 key=ixstudentsnameagework,keylen=140 explain select name, age, work from students where name in ('小明', '小潘', '小李'); explain select name, age, work from students where name not in ('小明', '小潘', '小李');

图示:3.5.in和notin的案例.png

**like案例**:尽量使用

xxx%的方式来全文搜索,能和覆盖索引联合使用更好-- 4.like案例 -- 索引不失效 key=ixstudentsnameagework,keylen=77(尽量这么用like) explain select id, name, age, work, createtime, datastatus from students where name like '张%'; -- 索引失效 explain select id, name, age, work, createtime, datastatus from students where name like '%张'; -- 索引失效 explain select id, name, age, work, createtime, datastatus from students where name like '%张%'; -- 解决:覆盖索引 key=ixstudentsnameagework,key_len=140(尽量避免) explain select name, age, work from students where name like '%张%';

3.6.like案例.png

2.计算、函数、类型转换(自动 or 手动)【尽量避免】

-- 4.2.计算、函数、类型转换(自动 or 手动)【尽量避免】 -- 这时候索引直接失效了,并全表扫描了 -- 解决虽然可以使用覆盖索引,但是尽量避免下面的情况: -- 1.计算 explain select id, name, age, work, createtime, datastatus from students where age = (10 + 13); -- 2.隐式类型转换(111==>'111') explain select id, name, age, work, createtime, datastatus from students where name = 111; -- PS:字符类型不加引号索引就直接失效了 -- 虽然覆盖索引可以解决,但是不要这样做(严格意义上讲,这个算个错误) -- 3.函数 explain select id, name, age, work, create_time, datastatus from students where right(name, 1) = '明';

图示:3.7.其他案例.png

光看没意思,再举个简单的业务案例:eg:用户一般都是根据商品的大分类=>小分类=>品牌来查找,有时候到不看品牌,直接小分类后就自己找了。那么组合索引可以这么建:

index(分类id,商品价格),

index(分类id,品牌id,商品价格)(一般都需要根据查询日记来确定)

PS:有些条例是流传甚广的,有些是工作中的经验,至少都是我踩过坑的,可以相对放心(业务不同优化角度不同)

1.5.5.写法上的优化

5.1.or改成union

-- 5.1.or改成union -- 现在高版本对只有一个or的sql语句有了优化 explain select id, name, age, work, createtime, datastatus from students where name = '小明' or name = '小张' or name = '小潘'; -- PS:等同上面or的语句 explain select id, name, age, work, createtime, datastatus from students where name in ('小明', '小张', '小潘'); -- 高效 explain select id, name, age, work, createtime, datastatus from students where name = '小明' union all select id, name, age, work, createtime, datastatus from students where name = '小张' union all select id, name, age, work, create_time, datastatus from students where name = '小潘';

4.union.png

PS:union总是产生临时表,优化起来比较棘手一般来说union子句尽量查询最少的行,union子句在内存中合并结果集需要去重(浪费资源),所以使用union的时候尽量加上all(在程序级别去重即可)

5.2.count优化

一般都是

count(主键|索引),但现在

count(/*)基本上数据库内部都优化过了(根据公司要求使用即可)PS:记得当时踩了次坑,等复现的时候补上案例(记得好像跟null相关)

看下就知道为什么说无所谓了(PS,你

count(非索引)就有所谓了)

explain select count(id) -- 常用 from userinfo; explain select count(/*) from userinfo; -- 你`count(非索引)`就有所谓了 explain select count(password) from userinfo;

4.2.count.png

我想说的优化是下面这个count优化案例:(有时候拆分查询会更快)-- 需要统计id>10000的数据总量(实际中可能会根据时间来统计) explain select count(/) as count from userinfo where id > 10000; -- 2s -- 分解成用总数-小数据统计 ==> 1s explain select (select count(/) from userinfo) - (select count(/*) from userinfo where id <= 10000) as count;

执行图示:4.2.count2.png

分析图示:4.2.count3.png

5.3.group by和order by

**group by和

order by的列尽量相同,这样可以避免filesort**-- 5.3.group by和order by的列尽量相同,这样可以避免filesort explain select / from students group by name order by work; explain select / from students group by name order by name; -- 加where条件也一样 explain select / from students where name like '小%' group by age order by work; -- PS:一般group by和order by的列都和where索引列相同(不一致也只会使用一个索引) explain select / from students where name like '小%' and age>20 group by name order by name; -- where后面的索引列和order by|group by后面的索引列不一致 -- id和email都是索引,但只用了一个索引 explain select /* from users where id < 10 order by email;

图示:4.3.orderby.png

PS:不一致也只会使用一个索引(在索引误区有详细说明)

5.4.用连接查询来代替子查询

一般来说都是用连接查询来代替子查询,有些时候子查询更方便(具体看业务吧)-- 用exists代替in?MySQL查询优化器针对in做了优化(改成了exists,当users表越大查询速度越慢) explain select / from students where name in (select username from users where id < 7); -- ==> 等同于: explain select / from students where exists(select username from users where username = students.name and users.id < 7); -- 真正改进==>用连接查询代替子查询 explain select students./ from students inner join users on users.username = students.name and users.id < 7; -- 等效写法:这个tmp是临时表,是没有索引的,如果需要排序可以在()里面先排完序 explain select students./ from students inner join (select username from users where id < 7) as tmp on students.name = tmp.username;

图示:(内部已经把in转换成exists了,所以改不改写无所谓了)4.4.子查询.png

5.5.★limit优化★

**limit offset,N**:mysql并不是跳过

offset行,然后取

N行,而是取

offset+N行,然后放弃前

offset行,返回

N行

  • PS:

offset越大效率越低(你去翻贴的时候,页码越大一般越慢)

知识点

为了更加的直观,我们引入一下**profiling**-- 查看profiling系统变量 show variables like '%profil%'; -- profiling:开启SQL语句剖析功能(开启之后应为ON) -- 来查看是否已经启用profile select @@profiling; -- 启动profile(当前会话启动) set profiling = 1; -- 0:未启动,1:启动 show profiles; -- 显示查询的列表 show profile for query 5; -- 查看指定编号查询的详细信息

输出:

MariaDB [dotnetcrazy]> show variables like '%profil%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | have_profiling | YES | | profiling | OFF | | profiling_history_size | 15 | +------------------------+-------+ 3 rows in set (0.002 sec) MariaDB [dotnetcrazy]> select @@profiling; +-------------+ | @@profiling | +-------------+ | 0 | +-------------+ 1 row in set (0.000 sec) MariaDB [dotnetcrazy]> set profiling = 1; Query OK, 0 rows affected (0.000 sec)

正文

上面设置完后,分别执行下面SQL:select / from userinfo limit 10,10; select / from userinfo limit 1000,10; select / from userinfo limit 100000,10; select / from userinfo limit 1000000,10; select /* from userinfo limit 10000000,10;

输出:

+----------+------------+------------------------------------------+ | Query_ID | Duration | Query | +----------+------------+------------------------------------------+ | 1 | 0.00060250 | select /* from userinfo limit 10,10 | | 2 | 0.00075870 | select /* from userinfo limit 1000,10 | | 3 | 0.03121300 | select /* from userinfo limit 100000,10 | | 4 | 0.30530230 | select /* from userinfo limit 1000000,10 | | 5 | 3.03068020 | select /* from userinfo limit 10000000,10 | +----------+------------+------------------------------------------+

图示:4.4.profiles.png

解决方法

  1. 业务上解决,eg:不许翻页超过100(一般都是通过搜索来查找数据)
  • PS:百度搜索页面也只是最多翻到76
  • 使用where而不使用offset
  • id完整的情况:eg:

limit 5,3 ==> where id > 5 limit 3;

  • PS:项目里面一般都是逻辑删除,id基本上算是比较完整的
  • 覆盖索引+延迟关联
    :通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据
  • 使用场景:比如

主键为uuid或

id不连续(eg:部分数据物理删除了等等)

说太空洞,演示下就清楚了:-- 全表扫描 explain select / from userinfo limit 10000000,10; -- 3s -- 先range过滤了一部分 explain select / from userinfo where id > 10000000 limit 10; -- 20ms -- 内部查询使用了索引覆盖 explain select /* from userinfo inner join (select id from userinfo limit 10000000,10) as tmp on userinfo.id = tmp.id; -- 2s

分析图示:4.5.limit.png

查询图示:4.5.limit2.png

扩展:索引误区和冗余索引

1.索引误区

很多人喜欢把where条件的常用列上都加上索引,但是遗憾的事情是:**独立的索引只能同时用上一个**

  • **PS:在实际应用中往往选择

组合索引**

别不信,来验证一下就知道了:-- id和email都是索引,但是只能使用一个索引(独立的索引只能同时用上一个) -- id的key-len=4(int4个字节) -- email的key-len=152(50/3(utf8下每个字符占3位)+2(varchar需要额外两个字节存放)==>152) -- 1.唯一索引和主键:优先使用主键 explain select / from users where id = 4 and email = 'xiaoming@qq.com'; -- 2.组合索引和主键:优先使用主键 explain select / from users where id=4 and createtime='2019-02-16 17:10:29'; -- 3.唯一索引和组合索引:优先使用唯一索引 explain select / from users where createtime='2019-02-16 17:10:29' and email='xiaoming@qq.com'; -- 4.组合索引和一般索引:优先使用组合索引 -- create index ixusersdatastatus on users(datastatus); -- create index ixusersusernamepassword on users(username,password); explain select /* from users where datastatus=1 and username='小明'; -- 删除临时添加的索引 -- drop index ixusersdatastatus on users; -- drop index ixusersusernamepassword on users;

图示:5.2个索引.png

**PS:根据测试得知,一次只能使用1个索引。

索引优先级:主键 > 唯一 > 组合 > 普通**

2.冗余索引

举个标签表的例子:create table tags ( id int unsigned auto_increment primary key, aid int unsigned not null, tag varchar(25) not null, datastatus tinyint not null default 0 ); insert into tags(aid,tag,datastatus) values (1,'Linux',1),(1,'MySQL',1),(1,'SQL',1),(2,'Linux',1),(2,'Python',1); select id, aid, tag, datastatus from tags;

输出:

+----+-----+--------+------------+ | id | aid | tag | datastatus | +----+-----+--------+------------+ | 1 | 1 | MySQL | 1 | | 2 | 1 | SQL | 1 | | 3 | 2 | Linux | 1 | | 4 | 2 | Python | 1 | +----+-----+--------+------------+

**实际应用中可能会

根据tag查找文章列表,也可能

通过文章id查找对应的tag列表**

项目里面一般是这么建立索引(冗余索引):index(文章id,tag),index(tag,文章id),这样在上面两种情况下可以直接用到覆盖索引

create index ixtagsaidtag on tags(aid,tag); create index ixtagstagaid on tags(tag,aid); select tag from tags where aid=1; select aid from tags where tag='Linux';

3.修复碎片

这边简单说下,下一章应该还会继续说运维相关的知识

数据库表使用时间长了会出现碎片,可以定期修复一下(不影响数据):**optimize table users;**修复表的数据以及索引碎片会把数据文件整理一下,这个过程相对耗费时间(数据量大的情况下)一般根据情况选择按周|月|年修复一下

PS:可以配合

crontab(定时任务)使用:

  • 使用命令:

crontab -e:

/////* 命令 [ > /dev/null 2>&1 ]

  • **
    5个/*的含义
    **:

分、

时、

日、

月、

  • 从定向知识:
  • >> /xx/日志文件
    :输出重定向到日记文件(不包含错误信息)
  • >> /xx/日志文件 2>&1
    :输出信息包括错误信息
  • > /dev/null 2>&1
    :出错信息重定向到垃圾桶(黑洞)
  • 举几个栗子:
  • 21///* xxx
    ==> 每天 1:02 执行 xxx命令
  • 5921///* xxx
    ==> 每天 21::59 执行 xxx命令
  • ///1///* xxx
    ==> 每1小时 执行一次xxx命令
  • 定时任务以

/*/开头

课后拓展:【推荐】一步步分析为什么B+树适合作为索引的结构 https://blog.csdn.net/weixin30531261/article/details/79312676 善用mysql中的FROMUNIXTIME()函数和UNIX_TIMESTAMP()函数 https://www.cnblogs.com/haorenergou/p/7927591.html 【推荐】MySQL crc32 & crc64函数 提高字符串查询效率 https://www.jianshu.com/p/af6cc7b72dac MySQL优化之profile https://www.cnblogs.com/lizhanwu/p/4191765.html

版权声明
本文为[鲲逸鹏]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/dotnetcrazy/p/10416523.html

编程之旅,人生之路,不止于编程,还有诗和远方。
阅代码原理,看框架知识,学企业实践;
赏诗词,读日记,踏人生之路,观世界之行;

支付宝红包,每日可领