MySQL（四）

本是古典何须时尚 2021-12-05 16:34 265阅读 0赞

**索引及执行计划**

索引就好比一本书的目录，它会让你更快的找到内容  
让获取的数据更有目的性，从而提高数据库检索数据的性能。

![1338158-20190619105204415-1436182356.png][]

常用btree索引![1338158-20190619110420615-1784354783.png][]

**索引基本管理：**

**![1338158-20190619110439136-1386185578.png][]**

![1338158-20190619110451615-1914168966.png][]

**desc 查看信息看key值有没有所有信息**

创建和删除：  
　　alter table student add index idx\_name(stu\_name); **idx\_name 索引的名字**

**　　　　这是在表的列上创建索引**

alter table student drop index idx\_name;  
或者

create index inx\_name on stu(stu\_name);   
　　drop index inx\_name on stu;

查询索引设置  
　　desc student;

show index from student;

用expain查看SQL的执行计划  
mysql> explain select id,name from test where name='oldboy'\\G  
explain select SQL\_NO\_CACHE \* from test where name='oldboy'\\G  
SQL\_NO\_CACHE的作用是禁止缓存查询结果。

**主键索引： 唯一、非空**  
走主键索引的查询效率是最高的，我们尽量每个表有一个主键，并且将来查询的时候计量以主键为条件查询

![1338158-20190619161945391-1158969490.png][]

**建表时 指定一个非空并且唯一的列为主键**

CREATE TABLE \`test\` (  
 \`id\` int(4) NOT NULL AUTO\_INCREMENT,  
 \`name\` char(20) NOT NULL,  
 PRIMARY KEY (\`id\`)  
) ENGINE=InnoDB DEFAULT CHARSET=UTF8;

![1338158-20190619162159136-877413463.png][]

**建表后**

CREATE TABLE \`test1\` (  
 \`id\` int(4) NOT NULL,  
 \`name\` char(20) NOT NULL  
) ENGINE=InnoDB DEFAULT CHARSET=UTF8;  
**增加自增主键**  
　　alter table test1 change id id int(4) primary key not null auto\_increment;

**前缀索引**： 选列的前几个字符作为索引的查询条件 来简化索引  
　　create index index\_name on student(stu\_id(8));

查看索引为前八个字符作为条件

show index from student;

![1338158-20190619163455477-1449124530.png][]

**联合索引：**  
　　where a女生 and b身高165 and c身材好

index(a,b,c)

特点：前缀生效特性。

a,ab,abc，ac 可以走索引。  
　　b bc c 不走索引。

原则：把最常用来作为条件查询的列放在前面。

**走索引**：  
　　select \* from people where a='nv' and b>=165 and tizhong<=120;  
　　select \* from people where a='nv' and b>=165;  
　　select \* from people where a='nv';  
　　select \* from people where a='nv' and tizhong<=120;

以上查询符合建立联合索引

**alter table student add index minx(gender,age);**

**唯一性索引： 普通索引前面加上unique**  
　　create unique index index\_name on test(name);

\-------------------------------------------------

**explain 调取语句的执行计划。**

主要是判断语句是否走索引

explain select stu\_name,gender,age from student where gender='F' and age <20;

**type : 表示MySQL在表中找到所需行的方式，又称“访问类型”，**

常见类型如下:

ALL,index, range, ref, eq\_ref, const, system, NULL

从左到右，性能从最差到最好

**ALL：**  
　　Full Table Scan， MySQL将遍历全表以找到匹配的行

**如果显示ALL，说明**：**查询没有走索引：**

1、语句本身的问题  
　　2、索引的问题，没建立索引

**index：**Full Index Scan，index与ALL区别为index类型只遍历索引树  
　　例子：  
　　　　explain select count(\*) from stu ;

**range:**索引范围扫描，对索引的扫描开始于某一点，返回匹配值域的行。  
　　显而易见的索引范围扫描是带有between或者where子句里带有<,>查询。  
　　where 条件中有范围查询或模糊查询时  
　　> < >= <= between and in () or  
　　like 'xx%'

当mysql使用索引去查找一系列值时，例如IN()和OR列表，也会显示range（范围扫描）,当然性能上面是有差异的。

**ref：**使用非唯一索引扫描或者唯一索引的前缀扫描，返回匹配某个单独值的记录行

where stu\_name='xiaoming'

explain select \* from stu where stu\_name='aa';

**eq\_ref：**类似ref，区别就在使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配，简单来说，  
　　就是多表连接中使用primary key或者 unique key作为关联条件

join条件使用的是primary key或者 unique key

**const、system：**当MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型访问。  
　　如将主键置于where列表中，MySQL就能将该查询转换为一个常量

explain select \* from city where id=1;

**NULL：**MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，  
 　　例如从一个索引列里选取最小值可以通过单独索引查找完成。

**Extra:**

Using temporary  
　　Using filesort  
　　Using join buffer

排序 order by ,group by ,distinct,排序条件上没有索引  
explain select \* from city where countrycode='CHN' order by population;

在join 的条件列上没有建立索引

\-------------------------------------------------  
**一、数据库索引的设计原则：**

为了使索引的使用效率更高，在创建索引时，必须考虑在哪些字段上创建索引和创建什么类型的索引。  
那么索引设计原则又是怎样的?

**1．选择唯一性索引**  
 　　唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。  
　　例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。  
　　如果使用姓名的话，可能存在同名现象，从而降低查询速度。

主键索引和唯一键索引，在查询中使用是效率最高的。

**2．为经常需要排序、分组和联合操作的字段建立索引**  
　　经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段，排序操作会浪费很多时间。  
　　如果为其建立索引，可以有效地避免排序操作。

**3．为常作为查询条件的字段建立索引**  
　　如果某个字段经常用来做查询条件，那么该字段的查询速度会影响整个表的查询速度。因此，  
　　为这样的字段建立索引，可以提高整个表的查询速度。

select count(DISTINCT population ) from city; 看population不重复的 有多少行  
　　select count(\*) from city; 看总行数 看到不重复的行更多那就可以吧这个列建立索引

**4．尽量使用前缀来索引**  
　　如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检索  
　　会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。

\------------------------以上的是重点关注的，以下是能保证则保证的--------------------

**5．限制索引的数目**  
　　索引的数目不是越多越好。每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。  
　　修改表时，对索引的重构和更新很麻烦。越多的索引，会使更新表变得很浪费时间。

**6．尽量使用数据量少的索引**  
　　如果索引的值很长，那么查询的速度会受到影响。例如，对一个CHAR（100）类型的字段进行全文  
　　检索需要的时间肯定要比对CHAR（10）类型的字段需要的时间要多。

**7．删除不再使用或者很少使用的索引**  
　　表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理  
　　员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。  
  
\---------------------------------------------二、开发规范---------------------------------------------------------------

不走索引的情况：  
**重点关注：**  
**1) 没有查询条件，或者查询条件没有建立索引**

select \* from tab; 全表扫描。  
　　select \* from tab where 1=1;

在业务数据库中，特别是数据量比较大的表。  
是没有全表扫描这种需求。

1、对用户查看是非常痛苦的。  
2、对服务器来讲毁灭性的。

（1）select \* from tab;

SQL改写成以下语句：  
selec \* from tab order by price limit 10 需要在price列上建立索引

（2）  
select \* from tab where name='zhangsan' name列没有索引

改：  
 1、换成有索引的列作为查询条件  
 2、将name列建立索引

**2) 查询结果集是原表中的大部分数据，应该是30％以上。**

查询的结果集，超过了总数行数30%，优化器觉得就没有必要走索引了。

假如：tab表 id，name id:1-100w ，id列有索引

select \* from tab where id>500000;

如果业务允许，可以使用limit控制。

怎么改写 ？  
结合业务判断，有没有更好的方式。如果没有更好的改写方案  
尽量不要在mysql存放这个数据了。放到redis里面。

**3) 索引本身失效，统计数据不真实**

索引有自我维护的能力。  
对于表内容变化比较频繁的情况下，有可能会出现索引失效。

**4) 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+，-，\*，/，! 等)**  
例子：   
错误的例子：select \* from test where id-1=9;   
正确的例子：select \* from test where id=10;

**5)隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误.**  
由于表的字段tu\_mdn定义为varchar2(20),但在查询时把该字段作为number类型以where条件传给数据库,  
这样会导致索引失效. 错误的例子：select \* from test where tu\_mdn=13333333333;   
正确的例子：select \* from test where tu\_mdn='13333333333';   
\------------------------  
mysql> alter table tab add index inx\_tel(telnum);  
Query OK, 0 rows affected (0.03 sec)  
Records: 0 Duplicates: 0 Warnings: 0

mysql> select \* from tab where telnum='1333333';  
\+------+------+---------+  
| id | name | telnum |  
\+------+------+---------+  
| 1 | a | 1333333 |  
\+------+------+---------+  
1 row in set (0.00 sec)

mysql> select \* from tab where telnum=1333333;  
\+------+------+---------+  
| id | name | telnum |  
\+------+------+---------+  
| 1 | a | 1333333 |  
\+------+------+---------+  
1 row in set (0.00 sec)

mysql>

\------------------------

**6)**   
**<> ，not in 不走索引**

EXPLAIN SELECT \* FROM teltab WHERE telnum <> '110';  
EXPLAIN SELECT \* FROM teltab WHERE telnum NOT IN ('110','119');  
\------------  
mysql> select \* from tab where telnum <> '1555555';  
\+------+------+---------+  
| id | name | telnum |  
\+------+------+---------+  
| 1 | a | 1333333 |  
\+------+------+---------+  
1 row in set (0.00 sec)

mysql> explain select \* from tab where telnum <> '1555555';  
\-----  
单独的>,<,in 有可能走，也有可能不走，和结果集有关，尽量结合业务添加limit  
or或in 尽量改成union

EXPLAIN SELECT \* FROM teltab WHERE telnum IN ('110','119');  
改写成：

EXPLAIN SELECT \* FROM teltab WHERE telnum='110'  
UNION ALL  
SELECT \* FROM teltab WHERE telnum='119'

\-----------------------------------  
**7) like "%\_" 百分号在最前面不走**

EXPLAIN SELECT \* FROM teltab WHERE telnum LIKE '31%' 走range索引扫描

EXPLAIN SELECT \* FROM teltab WHERE telnum LIKE '%110' 不走索引

%linux%类的搜索需求，可以使用elasticsearch

%linux培训%

**8) 单独引用复合索引里非第一位置的索引列.**  
列子：  
复合索引：

DROP TABLE t1  
CREATE TABLE t1 (id INT,NAME VARCHAR(20),age INT ,sex ENUM('m','f'),money INT);

ALTER TABLE t1 ADD INDEX t1\_idx(money,age,sex);  
DESC t1  
SHOW INDEX FROM t1  
走索引的情况测试：  
EXPLAIN SELECT NAME,age,sex,money FROM t1 WHERE money=30 AND age=30 AND sex='m';  
EXPLAIN SELECT NAME,age,sex,money FROM t1 WHERE money=30 AND age=30 ;  
EXPLAIN SELECT NAME,age,sex,money FROM t1 WHERE money=30 AND sex='m'; ----->部分走索引  
不走索引的：  
EXPLAIN SELECT NAME,age,sex,money FROM t1 WHERE age=20  
EXPLAIN SELECT NAME,age,sex,money FROM t1 WHERE age=30 AND sex='m';  
EXPLAIN SELECT NAME,age,sex,money FROM t1 WHERE sex='m';

**存储引擎查询**

**![1338158-20190620154046846-526056114.png][]**

![1338158-20190620154157954-1180328776.png][]

![1338158-20190620154218653-13137230.png][]

![1338158-20190620154242034-1857904036.png][]

\-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

show engines;　　　　查看支持的存储引擎  
show create table city; 查看表的存储引擎  
show table status like 'city'\\G 同上  
 select table\_schema,table\_name,engine from information\_schema.tables where table\_schema='world'; 查询world库的所有表的存储引擎  
select table\_schema,table\_name,engine from information\_schema.tables where table\_schema='mysql'; 同上  
select table\_schema,table\_name,engine from information\_schema.tables where engine='csv'; 查询整个数据库中 使用CSV引擎的表

**设置存储引擎**

**![1338158-20190620155917401-416065905.png][]**

**1、在启动配置文件中设置服务器存储引擎：**  
 　　\[mysqld\]  
 　　default-storage-engine=<Storage Engine>  
**2、使用 SET 命令为当前客户机会话设置：**  
 　　SET @@storage\_engine=<Storage Engine>;  
**3、在 CREATE TABLE 语句指定：**  
 　　CREATE TABLE t (i INT) ENGINE = <Storage Engine>;

![1338158-20190620154405731-1175728556.png][]

![1338158-20190620154545004-1608108859.png][]

![1338158-20190620154532776-485422247.png][]

![1338158-20190620154558051-1236970869.png][]

表空间：

共享表空间：主要存放系统元数据等  
独立表空间：主要存放用户数据

共享表空间设置：

innodb\_data\_file\_path=ibdata1:50M;ibdata2:50M:autoextend

innodb\_data\_file\_path=ibdata1:12M;ibdata2:50M:autoextend ----错误的配置XXX

innodb\_data\_file\_path=ibdata1:76M;ibdata2:50M:autoextend -----正确的配置

![1338158-20190621104930671-1041290963.png][]

![1338158-20190621104946622-1116342370.png][]

![1338158-20190621105018675-1729112242.png][]

![1338158-20190621105036285-539168739.png][]

![1338158-20190621105055236-88973683.png][]

![1338158-20190621105110558-985252007.png][]

![1338158-20190621105122347-1339903615.png][]

![1338158-20190621105134817-586870604.png][]

![1338158-20190621105146488-612562278.png][]

![1338158-20190621105158130-503853012.png][]

![1338158-20190621105205459-12020261.png][]

**----------------------------------------------------------------------------------------------**

**MySQL日志管理**

![1338158-20190621145449297-66121396.png][]

![1338158-20190621145509876-659516828.png][]

**MySQL日志——（2）错误日志**

配置方法:  
　　\[mysqld\]  
　　log-error=/data/mysql/mysql.log  
查看配置方式：  
　　mysql> show variables like '%log%error%';  
作用：  
记录mysql数据库的一般状态信息及报错信息，是我们对于数据库常规报错处理的常用日志。

**MySQL日志——（3）一般查询日志**  
配置方法:  
　　\[mysqld\]  
　　general\_log=on  
　　general\_log\_file=/data/mysql/server2.log  
查看配置方式：  
　　show variables like '%gen%';  
作用：  
记录mysql所有执行成功的SQL语句信息，可以做审计用，但是我们很少开启

![1338158-20190621145705391-603567129.png][]

**MySQL日志——二进制日志（2）**  
1、二进制日志都记录了什么？  
 　　已提交的数据记录，以event的形式记录到二进制文件中  
2、二进制记录格式有哪些？  
 　　row：行模式，即数据行的变化过程，上图中Age=19修改成 Age=20的过程事件。  
 　　statement：语句模式，上图中将update语句进行记录。  
 　　mixed：以上两者的混合模式。  
3、三总模式有什么优缺点？  
4、binlog的作用  
 　　备份恢复、复制

**二进制日志的管理（1）**  
1、开启二进制日志  
　　set sql\_log\_bin=0 在会话级别修改为临时关闭  
　　vi /etc/my.cnf  
　　log-bin=/data/mysql/mysql-bin 在全局打开binlog

binlog\_format=row

2、设置二进制日志记录格式（建议是ROW）：  
配置文件中修改：  
　　binlog-format=ROW  
命令行修改  
　　mysql> SET GLOBAL binlog\_format = 'STATEMENT';  
　　mysql> SET GLOBAL binlog\_format = 'ROW';  
　　mysql> SET GLOBAL binlog\_format = 'MIXED';   
3、查看binlog设置  
　　show variables like '%binlog%';

4、binlog的刷新策略或叫同步策略

sync\_binlig=1 每次的事物提交都写入磁盘

**二进制日志管理（2）**  
查询二进制日志文件  
ls -l /data/mysql/mysql-bin\*

**二进制日志管理（3）**  
　　获取二进制日志的内容及事件

**二进制日志管理（4）**  
　　刷新二进制日志  
 　　flush logs  
　　截取二进制日志  
 　　mysqlbinlog --start-position= --stop-position= >a.sql   
问题：  
　　1、什么是事件？  
　　2、什么是position ?

![1338158-20190621150150737-2128071686.png][]

**二进制日志 实际操作**

新建一个二进制日志的路径和文件并授权

mkdir /data/binlog -p  
chown -R mysql.mysql /data/binlog

vim /etc/my.cnf

log-bin=/data/binlog  
binlog\_format=row  
sync\_binlog=1

show binary logs; 查看当前所有可用的二进制日志信息  
show binlog events in 'my-bin.000002' 看二进制文件的 信息  
show master status; 看当前正在使用的二进制日志

mysqlbinlog --base64-output=decode-rows -v my-bin.000002

转码以decode-rows 打印二进制的内容

mysqlbinlog --start-position=120 --stop-position=721 my-bin.000002

截取二进制内容

mysqbinlog --start-position=340 --stop-position=721 my-bin.000002 >/tmp/binlog.sql

截取内容导入到文件

使用二进制日志恢复数据

use lufei;

set sql\_log\_bin=0; 临时关闭二进制日志的记录 然后进行恢复

source /mysql/data/mysql-bin.000017 指定文件恢复

**也可以截取部分二进制文件内容进行恢复，跳过或避免恢复错误的操作**

**set sql\_log\_bin=0;**

**source /tmp/binlog.sql 选择保存的截取部分 实时点恢复**

flush logs; 刷新日志/重新增加一个二进制文件

删除二进制：  
　　默认情况下，不会删除旧的日志文件。  
　　根据存在时间删除日志：  
　　SET GLOBAL expire\_logs\_days = 90;  
　　…或者…  
　　PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day; 删除三天以前的  
　　根据文件名删除日志：  
　　PURGE BINARY LOGS TO 'mysql-bin.000010';

reset master; 清理所有的日志  
**-------------------**  
**MySQL的慢查询日志**

功能：  
　　slow-log，记录所有条件内的慢的SQL语句  
　　优化的一种工具日志。帮我们定位问题。  
　　是将mysql服务器中影响数据库性能的相关SQL语句记录到日志文件  
　　通过对这些特殊的SQL语句分析，改进以达到提高数据库性能的目的。

慢日志设置：  
　　long\_query\_time ： 设定慢查询的阀值，超出次设定值的SQL即被记录到慢查询日志，缺省为10s  
　　slow\_query\_log ： 指定是否开启慢查询日志  
　　slow\_query\_log\_file ： 指定慢日志文件存放位置，可以为空，系统会给一个缺省的文件host\_name-slow.log  
　　min\_examined\_row\_limit：查询检查返回少于该参数指定行的SQL不被记录到慢查询日志  
　　log\_queries\_not\_using\_indexes: 不使用索引的慢查询日志是否记录到索引

配置例子:  
　　slow\_query\_log=1   
　　slow\_query\_log\_file=/data/slow/slow.log  
　　long\_query\_time=0.5  
　　log\_queries\_not\_using\_indexes

![1338158-20190624160908183-406080385.png][]

测试

处理慢日志：  
　　mysqldumpslow命令 排序日志内容

mysqldumpslow -s c -t 10 /data/slow/slow.log  
　　mysqldumpslow -s at -t 10 /data/slow/slow.log

这会输出记录次数最多的10条SQL语句，  
其中：  
\-s  
是表示按照何种方式排序  
c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序。  
ac、at、al、ar，表示相应的倒叙。  
\-t  
是top n的意思，即为返回前面多少条的数据；

\----------自己扩展  
pt-query-diagest percona-toolkit工具箱里的  
mysqlsla

转载于:https://www.cnblogs.com/cqzhou/p/11057922.html

[1338158-20190619105204415-1436182356.png]: /images/20211205/acfcf7d2d9404a6f81e4c2e4f404637f.png
[1338158-20190619110420615-1784354783.png]: /images/20211205/0017a2fddbd948b9b94383c447de1467.png
[1338158-20190619110439136-1386185578.png]: /images/20211205/1d3aa2726b124c4389bcc12a64ee8ace.png
[1338158-20190619110451615-1914168966.png]: /images/20211205/4737039c19334cbc837a5c0c3b01cf0c.png
[1338158-20190619161945391-1158969490.png]: /images/20211205/41f47f676e134927baf113d9062b10f4.png
[1338158-20190619162159136-877413463.png]: /images/20211205/5f3d333541044457a941a6a5f777299d.png
[1338158-20190619163455477-1449124530.png]: /images/20211205/45add1e524154bf09dfb76f1971985ff.png
[1338158-20190620154046846-526056114.png]: /images/20211205/70fdf93ad1f04ed5b75f2bedfe60fac0.png
[1338158-20190620154157954-1180328776.png]: /images/20211205/b8b3ef6b002a4a66ba963608b9685a7c.png
[1338158-20190620154218653-13137230.png]: /images/20211205/78e8eba4a7e64832a399127411c44560.png
[1338158-20190620154242034-1857904036.png]: /images/20211205/36629d75a2384f94985ca305db45f5e3.png
[1338158-20190620155917401-416065905.png]: /images/20211205/e1f09e37593f462a8ae227c5e02a4d4a.png
[1338158-20190620154405731-1175728556.png]: /images/20211205/7217dffd55544ce985facb4f37b80a90.png
[1338158-20190620154545004-1608108859.png]: /images/20211205/cbab486bc8e0457a9b8839a1a7f62022.png
[1338158-20190620154532776-485422247.png]: /images/20211205/92f0d2c99aac47349841a0a937dcc487.png
[1338158-20190620154558051-1236970869.png]: /images/20211205/84e697b7adb94901a8877972ccc4da6c.png
[1338158-20190621104930671-1041290963.png]: /images/20211205/a2cb5b8619bf499088420fd3fc6ed8c4.png
[1338158-20190621104946622-1116342370.png]: /images/20211205/254125327c0f4d5e84c10ce3594ebf62.png
[1338158-20190621105018675-1729112242.png]: /images/20211205/82006afae85f45cdbfd28e64650c8f6a.png
[1338158-20190621105036285-539168739.png]: /images/20211205/81122a0319ae455f89c5b94868f22a5d.png
[1338158-20190621105055236-88973683.png]: /images/20211205/8de1eb61de354d3d95a0429c5969f554.png
[1338158-20190621105110558-985252007.png]: /images/20211205/886906d0812b460ebc7a0b8b486a5c7c.png
[1338158-20190621105122347-1339903615.png]: /images/20211205/dc1c7d4c3cb843b6a1f0755489306d3e.png
[1338158-20190621105134817-586870604.png]: /images/20211205/b18a5c2539494ea698fac2aa326118a7.png
[1338158-20190621105146488-612562278.png]: /images/20211205/ec4593c239074fd58f7527c92da71361.png
[1338158-20190621105158130-503853012.png]: /images/20211205/65816abcd7e74bd1961c22a6c24211c2.png
[1338158-20190621105205459-12020261.png]: /images/20211205/ed19f7e92ab24edd86c5c7e661810bee.png
[1338158-20190621145449297-66121396.png]: /images/20211205/73bed7ebd7124910a64821ac0430cc1a.png
[1338158-20190621145509876-659516828.png]: /images/20211205/53edd76148cf4689867f55f251703f39.png
[1338158-20190621145705391-603567129.png]: /images/20211205/87e49dee653d439c8523643390772dcd.png
[1338158-20190621150150737-2128071686.png]: /images/20211205/3a41488bb1af45f68134768b83aef553.png
[1338158-20190624160908183-406080385.png]: /images/20211205/1afa95d5cb7e4a7db160cdc35f13beb1.png